Hello Fellow Learners,

In continuation to my hustle around retrying messages with a configurable wait time and max iteration for http calls.

I am quite aware of Retry patterns detailed in the official guidelines SAP Help : Apply the Retry Pattern, further the new inbuilt feature to retry http calls SAP Integration Suite – Inbuilt Retry option for HTTP Receiver Adapter fulfils the purpose completely but still I am willing to lay down this approach for the general usability, if the above approaches are not achievable due any reasons.

In December 2020 I raised this Question : Possibility to retry an SAP CPI Iflow request-reply step in case of http error in the community and received valuable suggestions to use JMS queues/datastore and as of current day we have SAP Event Mesh and SAP Advanced Event Mesh(with advanced features you can find here).

But somehow I felt sticking to the Iflow approach and strived to find logical design specific solution only.

Last year I implemented a simple solution, looking genuine and felt worth sharing. The intention of this solution is to retry the http trigger in case of 5XX http errors (temporary server related glitches like 500 etc.). However please note in the below example I have tried to achieve the result through another deployed iflow’s http endpoint, hence worked with 404 for demonstration purpose.

Problem Statement:

Resend the message through HTTP Receiver for a fixed number of retries after receiving Response code as 500 with a pause, say after 20 secs.

Design Solution:

Design Solution

Explanation: 

1. Separate the http request reply call from the Main process [2] in a new local sub-process [3]
2. Save http request payload in property as initialPayload and the configured waitTimeInSec before calling the looping sub process
3. Run this local process[3] in loop until the http response code is different than 404 till maximum 5 iteration, post that the loop ends (suitable option can be chosen in Action when Max iteration is reached).
   
4. The max Number of Iteration is fixed here as 5 (can be any positive integer as this field entry do not support externalisation/variable)
5. Add a router to validate the exceeding condition and route to error end in case it exceeds the max iteration count
   
6. Any error in the main process through error end/any other exception will in turn run the Exception sub process and attach MPL through Groovy
7. The local integration process [3] has 2 routers routing by conditional check for 1st call, if not then conditional check for 404 to follow the reset,sleep and retry lane. In case of any other error the local integration process [3] ends, loop breaks and next steps of the main process [2] is executed
   —————————————————————————————————————————–
   
8. In the HTTP receiver adapter configuration. The Throw Exception on Failure option should be unchecked to achieve this retry approach.
   
9. In the main process [2] the router does a conditional check of the httpresponsecode, here we have the possibility to handle each error separately and apply right error handling mechanism as per SAP Help : Handle Errors Gracefully. It is also possible that the flow is extended to push the payload to retry queues for later retries.

The implementation of this approach is likely to vary as per your individual use case.

Hence I would love to hear back from the community on this approach.