Eventing
Eventing is how the fulfillmenttools platform allows external systems to be notified about business events such as "Order has been routed" or "Pickjob has been completed". Please note that Events are always phrased in the past tense because they describe events that have already happened.
The fulfillmenttools platform's architecture follows the MACH principles. Business features are implemented using independent microservices that send and consume events.
Eventing is available for an callback-url and the Microsoft Azure Service Bus.
Timing
Events are the mechanism of choice for decoupling services within a distributed system. From the publication to the message bus to the publication to the subscriptions, it usually takes milliseconds to a few seconds. In the worst case, when our backend services are scaling up, this can take up to 30 seconds.
The following diagram shows the typical timing of events originating from the fulfillmenttools platform to an external system:
Avoid delays in event sending due to subscriptions in error
In a distributed system, it is expected that parts of the system will fail every now and then. However, when running a service on your own that serves as an endpoint to subscriptions, it is important that you properly monitor the availability and return codes it returns to prevent events from being delivered in time.
Services returning a 200 OK response are considered error-free.
Receiving events preparations
A step-wise approach is needed before receiving your first event from fulfillmenttools. Only fulfillmenttools users with the role ADMINISTRATOR can create new subscriptions.
To create a subscription, take a look into the integration guide Subscribe to events.
Attempts to resend messages that were not delivered successfully
The time between the retries will progressively increase with every retry from 20 seconds until it reaches 600 seconds. This is executed for 1 hour. After 1 hour fulfillmenttools still tries to deliver events for 7 days. Nevertheless, fulfillmenttools cannot give any guarantees on how many times and the interval between retries.
If fulfillmenttools can't deliver an event for 7 days, the message will be dropped and it is lost forever.
fulfillmenttools does not monitor the endpoints to which the events should be delivered.
When a configured subscription is not reachable or answers with another response code than HTTP 200 OK the fulfillmenttools platform will automatically initiate a retry of the message. The pattern followed is described as exponential backoff, which basically means that the time that goes by between the actual retry attempts progressively increases. Please see the following diagram that visualizes the approach:
As you can see above, when a message cannot be delivered for the first time, there is currently a first retry after 20 seconds. Retries are being performed after every failed attempt. The time between the retries will progressively increase with every retry until it reaches 600 seconds (10 minutes). It will stay at that rate until either
the subscription is reachable & acknowledges the message by replying with HTTP
200 OKormessage retention is reached (currently: 7 days). It will be dropped then.
Last updated