Blog Post

Azure Integration Services Blog
2 MIN READ

Custom Retry Strategy

talsaifi's avatar
talsaifi
Icon for Microsoft rankMicrosoft
Jan 31, 2023

Overview

Intermittent failures and delays are events that might happen on a cloud environment, to overcome the occurrence of these events and minimize disruption of your logic app runs, a powerful built-in feature is available “retry policy”, but there are special cases where this retry policy won’t come into action and a custom retry strategy need to be part of your workflow to overcome these kinds of events. Such events are:

 

 

In this article, we will show how to implement this custom retry strategy as part of your workflow.

 

Steps

  1. Execute the required action.
  2. Check if success code or required data are returned:
    1. If yes, go to step 3.
    2. If no, execute the following steps inside until loop:
      1. Delay for X minutes; X delay time can be set as required depending on the failure cause.
      2. Execute the required action again (same as step 1).
      3. Check if success code or required data are returned:
        1. If yes, exit until loop and go to step 3.
        2. If no, go back to step I and execute same steps again.
  3. Proceed with remaining actions execution normally.

 

Sample Scenario

Suppose you are using the HTTP action to call a REST API, in case of success the call returns an HTTP status code 200, the call intermittently fails and does not return the HTTP status codes identified by the retry policy, so the retry policy is not activated and the action fails. Here comes the custom retry strategy into action.

 

Implementation

Use the following steps:

1. Add the HTTP action to call the targeted REST API.

2. Add a Control – Condition action to check if REST API call failed by checking the HTTP status code returned by the previous action if it is not equal to 200.

3. Inside the True branch, add a Control – Until action.

4. Inside the Control – Until action:

a. Add Schedule – Delay action and set the count to 1 and Unit to Minute.

b. Add another HTTP action to call the same targeted REST API again.

c. Check if the HTTP status code returned from previous step is equal to 200 to exit the loop.

d. Set the until limits as required, count and timeout.

 

The final workflow will look as follows:

Updated Feb 01, 2023
Version 2.0

4 Comments

  • mikeholdorf You are totally right! 

    That upper limit is set in implementation step 4.d, where we set the Control - Until loop Count limit to the maximum number of retries.

    Thanks for highlighting this!

  • mikeholdorf's avatar
    mikeholdorf
    Brass Contributor

    Yes definitely useful. One thing, if the backend system is down for a long time, this will just keep looping and running every minute. We have done a similar approach, but have counter so we only loop x number of times before we stop trying. Probably a good idea to have an upper limit on the number of retries.

  • marka514's avatar
    marka514
    Copper Contributor

    This is a useful approach when you need to implement a retry for HTTP response codes that do not, by default, trigger an automatic retry in the action (408, 429, 5xx). But it would be really good if the HTTP action allowed you to configure additional HTTP response codes that trigger a retry. Then this workaround would not be needed and our workflows would be simpler.