The HTTP adapter is one of the most widely used adapters in SAP Integration Suite. Especially in cloud integration and REST API scenarios, the HTTP adapter is highly useful.

However, in the past, when consuming an API via the HTTP adapter, if the call failed, there were no built-in options to automatically retry the request. Instead, you had to rely on other techniques like asynchronous decoupling with JMS queues to retry failed messages in the HTTP receiver adapter.

That said, there are certain cases where an automatic retry from the adapter itself would be beneficial. For example, in a high-available system (HA), message failures can sometimes be temporary. In such cases, it would be advantageous for the adapter to automatically retry the request, improving reliability without additional manual intervention or overcomplicating the integration scenario. Additionally, you might be able to save some JMS resources in your tenant.

How the Retry Mechanism Works in HTTP Receiver Adapter

If an HTTP request fails with an unsuccessful status, such as 500, 404, or 420, and the retry option is not enabled, the message enters a failed status in SAP Integration Suite, and message processing ends there.

However, with the retry option enabled, if an HTTP request through the HTTP adapter fails, iFlow can automatically retrigger the message a certain number of times. When configuring the adapter, you can specify for which status codes you want the retry mechanism to activate.

The advantage is that for scenarios such as the receiver is temporarily unavailable, the business process will not be affected. The message can be automatically delivered with the next retry.

For example, HTTP status codes between 300 to 599 are considered error statuses. However, in the adapter settings, you can filter specific status codes for which the retry mechanism should be triggered.

The retry mechanism works as follows: If the initial message delivery fails, the message enters a “Processing” status, which you can see in the Message Monitor.

Then, based on the “Retry Interval (in seconds)” configured in the HTTP Receiver Adapter, the first retry attempt will be triggered after the specified interval. If that retry also fails, the mechanism will continue attempting to resend the message if you have configured “Retry Iterations” as more than 1.

The maximum number of retries can also be configured in the adapter. Currently, the maximum number of automatic retries is 3.

For example, if you set the “Retry Interval (in seconds)” to 10 seconds and “Retry Iterations” to 2, the message will be automatically retried every 10 seconds, for up to 2 times, after the initial failure.

Configuring the Retry Option in HTTP Receiver Adapter

One of the prerequisites for the Retry option is that you must have “Throw Exception On Failure” enabled in the adapter. This setting ensures that the message status in SAP Integration Suite goes into a failure state when the remote receiver (server) returns a failed response. Generally, this option allows you to receive all HTTP response codes from the remote server, regardless of their status.

Retry Failed Requests

This option enables automatic retries for failed messages in the HTTP adapter. By default, this option is disabled. When you enable it, the corresponding adapter configuration options, such as “HTTP Error Response Codes,” “Retry Interval (in seconds),” and “Retry Iterations” are also enabled.

In this example, I want the messages to be automatically reprocessed only if the response contains HTTP status codes 500, 404, or 420.

HTTP Error Response Codes

Here, you can provide a comma-separated list of HTTP error codes that should trigger the retry mechanism in the integration flow. The retry will not start for any other error statuses not specified in the configuration.

Retry Interval (in seconds)

This setting defines how long the integration flow must wait after each failed message delivery before retrying. The maximum retry interval is 60 seconds.

Retry Iterations

This option allows you to set the maximum number of retries for message delivery. The highest number of retries you can configure is 3.

Testing HTTP Automatic Retry Mecanisum in Action

When the interface is start processing for the first time, If an error status is received from the receiver, the message processing status changes to ‘Processing’.

Then, based on the configuration of the HTTP adapter, automatic retry starts. The first retry occurs after 60 seconds. Thereafter, the processing will restart every 60 seconds.

Once the interface processing reaches the maximum number of retries, in this example, 3, the message goes into error if the error still persists in the last retry.

Other Considerations When Implementing the HTTP Retry Mechanism

What if you have an exception subprocess in your iFlow?

If you use an exception subprocess, it is invoked only after all retry iterations configured in “Retry Iterations” are exhausted and the error continues to persist.

What if the retry instruction comes from the response of the target system?

If the target system provides reprocessing instructions in the “Retry-After” header parameter, the retry configuration set in the HTTP adapter is overwritten with the values received from the target system.

Keep these factors in mind when designing your iFlow with HTTP automatic retry enabled.