ÃÛ¶¹ÊÓƵ

Transcript

Welcome to a new commerce integration static click video lesson. In today’s session, we are going to see how to leverage ÃÛ¶¹ÊÓƵ IEO Events built-in retry mechanism to build resilience into our app pitch. ÃÛ¶¹ÊÓƵ IEO Events has a built-in out-of-the-box retry mechanism. Events activations resulting in specific HTTP response status codes will be retired. The status codes that will cause an event to be retired are 429, too many requests, and any status code in the range of 500 to 599, except for 505 HTTP version not supported. ÃÛ¶¹ÊÓƵ IEO Events will keep retrying delivery for 24 hours, using exponential and fixed-backoff strategies for these HTTP status codes. How does it work? The first retry is attempted after one minute, and the period between attempts doubles after each attempt until it gets to 15 minutes. From this point on, retries will be attempted every 15 minutes. How do these retries appear in the developer console? To illustrate it, we will use this sample app builder project, where we can see runtime action activations resulting in the following status codes. 400, bad request. 401, unauthorized. 404, not found. 429, too many requests. 500, international error. And 505, version not supported. If you navigate to an event registration, open the Dev App Creation tab, and check the activations. You will notice that a failed event is marked with a warning icon and the HTTP response code shown next to it. A retried event is marked with a circular arrow icon and the response code is also shown next to it. In addition to these visual indicators, if you check the request headers for a retried event, you will be able to see an X-ÃÛ¶¹ÊÓƵ retry count header. If we compare a retried event with its original, we will notice that both have the same X-ÃÛ¶¹ÊÓƵ Event ID header, but this event X-ÃÛ¶¹ÊÓƵ Delivery ID. How does the Starter Key leverage this built-in retry mechanism? The consumer runtime actions are registered to events, and by returning the adequate response HTTP status code, they can determine whether an event gets retried. What does a successful response look like? As shown on screen, it includes a 200 status code target. What does an error response look like? As shown on screen, it includes an error object with a status code target. How does the consumer runtime actions determine the HTTP code to return? Since the consumer action, it just dispatching the receiver event to the appropriate event handling. The same is simply returns. Status code returned by the action downstream if there was an error processing the event. A 200 response if the action downstream was successful. And a 500 internal server error response if there was an expected issue. What HTTP response code returns an event holder on that action? If the incoming payload validation fails, it will return a 400 bad request response code. If there is an unexpected error, it will return 500 internal server errors. In any other case, it will propagate the response code received by the request to the API downstream. Suppose the call to the Commerce API to create customer receives a 429 domain request response code. In that case, the response code will be sent back to the consumer action that will return it as a result of the activation, which will cause the event to be retried and eventually end up in a successful response once the API can copy the requests. It is important to be aware of failing event activations and retry attempts. This is why we recommend getting visibility on them by logging failure and retries, alerting to the interesting parties via Slack or EME. This concludes this session. Thanks for watching and remember to check the ÃÛ¶¹ÊÓƵ Developer Docs website for code samples and tutorials.