Any data manipulation request (i.e.
DELETE) that will be send to our retailer API will be handled a-synchronously. When receiving your request, we store it internally into a queue. The retailer API is continuously working from the queue to handle all requests. All requests are stored in a specific sequence. Based on the amount of requests in the queue, it may vary how long it will take to execute your request. Once your request is lined up first, we will forward it to another internal service within our landscape. This works as follows:
When we receive your request, we assign a process status id with it. With this id, you can request the status later in time. The status of the message is at this moment in time
Consequently, we forward it to a downstream service. This results in an update of the process status to
SUCCESS(in case of a successful response) or
FAILURE(in case of a failure).
In case a downstream service is on temporarily unavailable or unable to process your request, we put it back to our internal queue for retry. The status remains in that case at
In case of an unexpected response, we retry your request 5 times every 5 minutes. In case it fails 5 times in a row, the status will transform to
When the process status is
SUCCESS, only then you will receive the entityId. Before that, the action was not yet executed (or continuously unsuccessful) and therefore, no entityId exists (in case of
In case of a
FAILURE, you can find the reason for failure by looking at the errorMessage field.
Whenever a request remains at pending state for a longer period of time, we set the status to
You can retry the request at a later time by repeating the original request.