New Retry Feature for HTTP Receiver Adapter

Introduction:

With the introduction of the ‘retry’ inbuilt feature to the HTTP receiver adapter in the recent release, we can explicitly set the flow to retry the network connection based on the received response code. This is being achieved by polling for the defined retry count at a defined time interval.

Benefit:

This feature targets to overcome the following:

• Operational load on a system, example any temporary server unavailability for short duration like server overload, will no longer cause the flow to go into an error state.
• No more hassle to restart the flow manually.

Customer Scenario:

Imagine a salesperson approaches a potential lead. On visit gets the details of the business or the organization from the merchant, who requested for point-of-sale equipment.

And then process’s the details into his mobile app and submits the contract.

Meanwhile, the salesperson now need not await the server confirmation and can proceed to the next lead visit.

Sample Flow Design Logic

Sample Design

Configuration:

At the HTTP Receiver Adapter end,

• The feature is only available when the checkbox is checked (by default)
• Check the checkbox
• And then one can specify, for what all different kind of response code the Inbuilt Retry should be done in the below field.

(One can mention code between 400-599, but any special character not supported like * or 5*)

• Retry Interval can be set within the defined range of 5-60 sec.

• Max Retry Iterations can only be defined 1-3, to avoid reaching retry rate limit.

Monitoring:

The Flow can be monitored in below following ways.

• The open text view log explicitly defines the number of retries tried.
• For every Retry triggered the header of request and response and the response body is captured as attachments for reference

• One can also monitor the retry tried in Debug /Trace Mode by HTTP Reattempt Counter

Conclusion:

This feature would be helpful to overcome intermittent network connection to server and would help to manage message processing failures.

Please do share your thoughts and feedback over comments.

Also, would love to know other use cases, where you feel this feature could be used.