Message producer

The following is an interaction diagram of the message producer.

../_images/w2fm_mpro.svg

Interactions detailed

  1. When an event invocation request is sent from the webhook service to the API service, the validity of the request is verified using the information available in the database by the API service.

    1. If the validity is accepted, the following steps take place -

      1. The event invocation request is forwarded to the message producer where necessary templating is applied on the message topic and the message body.

      2. After the templating has been applied, the message is then shared with the Fedora Messaging bus and the response from the production bus is received.

      3. An entry containing the datetime information of the message creation, the digest signature of the message and associated service identifier is stored.

      4. A response containing the digest signature of the message and the message identifier is then extended to the API service to be sent to the requestor.

      5. The API service sends a HTTP 200 response with body containing the message identifier and the digest signature of the message to the webhook service.

    2. If the validity is rejected or if any error happens, the following steps take place -

      1. If the service associated with the service UUID requested is not found, an HTTP 400 response is shared by the API service with details of the failure.

      2. If the credentials of the user are provided incorrectly in the request header, an HTTP 401 response is shared by the API service with details of the failure.

      3. If the requesting user is not allowed to invoke an event from the service, an HTTP 403 response is shared by the API service with details of the failure.

      4. If the UUID associated with the conveyed message has been already been used, an HTTP 409 response is shared by the API service with details of the failure.

      5. If an unexpected server-side error happens that cannot be recovered from, an HTTP 500 response is shared by the API service with details of the failure.

  2. Depending on the response received by the webhook service, it can decide to either continue making event invocation requests or debug the reasons why the service is not working as intended.