SAP Cloud Integration version 7.18.**, one of the capabilities of SAP Integration Suite, comes with an enhancement to choose inbuilt retry for HTTP receiver adapter. This short blog describes how to use this feature.
The retry option in HTTP receiver adapter (with adapter version number 1.15) provides you an option to select retrying of failed HTTP requests. This features comes handy for the backend HTTP server facing some challenges to serve the requests, especially intermittent issues at backed.
By default, this option is not selected. Once you select this option, you will need to provide HTTP error response codes for which you want the HTTP receiver adapter to trigger the retry.
Also, you can choose the number of iterations and the time between the each iterations. Sample screenshot provided below.
Retry option with checkbox control
Configuring HTTP retry with required information
This retry is non-persistent, i.e., the failed requests will be retried in in-memory. When a message is processing, and backed server returns the provided HTTP error code, message will be put under the in-progress status till the retry attempts are complete. In case server sends a Retry-After header with longer duration of the wait, the priority will be given to it. If Retry-After header contains value as date format, i.e. <http-date>, after which retry needs to be executed, this will not be considered. Retry-After header with value in format <delay-seconds> is considered.
The trace view in the Cloud Integration message processing log in monitor would showcase the retries triggered for the message as per the configured number of retries.
Note:
In case if you have an existing Exception Subprocess, you need to add newer version of Exception Process step and remodel the logic in exception subprocess to redirect the message flow control to exception subprocess after HTTP inbuilt retries are exhausted.
SAP Integration Suite – Cloud Integration, with inbuilt retry support for HTTP receiver adapter, enhances handling of your message processing for the failures – especially intermittent – of the connected HTTP backed server.