Welcome again to another Logic Apps Best Practices, Tips, and Tricks. In my previous blog posts, I talked about some of the essential best practices you should have while working with Azure Logic Apps. Check out these Logic App tips and tricks!
Today I will speak about another important Best practice, Tips, and Tricks that you must consider while designing your business processes (Logic Apps): Retry Policies. And how you should be aware of and configure it properly.
Configure your Retry Policies correctly
Retry policies or mechanism is one of the basic mechanism of Enterprise Integration. In most cases, when we communicate with a system, especially in scenarios where we need to guarantee delivery, if a failure happens to communicate with that system – maybe because a downtime of that system, we don’t want to raise an error immediately.
Instead, we want to be able to retry that communication a certain number of times until we raise the error back. For handling retry policy, Azure Logic App offers an incredible first-class experience that can help us create robust and resilient integrations that gracefully handle problems and failures.
Since Azure Logic Apps is a service that is built upon the HTTP protocol, the mechanics behind how a retry will be initiated is dependent upon the HTTP status codes being returned, including 408, 429, and 5xx Server Errors. This means for Logic Apps to retry an action, the underlying service call must return one of these HTTP status codes for the Logic Apps runtime to issue the retry.
You can only use the retry policy when supported by a trigger or action. A good example is the HTTP action. But before we describe how to set this feature, let’s see what type of retry policies I have available.
Connector operations that support retry policies use the Default policy unless you select a different retry policy. The options available are:
- Default: For most operations, the Default retry policy is an exponential interval policy that sends up to 4 retries at exponentially increasing intervals. These intervals scale by 7.5 seconds but are capped between 5 and 45 seconds. Several operations use a different Default retry policy, such as a fixed interval policy.
- None: Don’t resend the request.
- In this case, we are disabling the retry policy, meaning that the action or trigger will not retry failed requests.
- Exponential Interval: This policy waits for a random interval, which is selected from an exponentially growing range, before sending the next request.
- This random interval is selected from an exponentially growing range. Optionally, you can override the default minimum and maximum intervals by specifying your own minimum and maximum intervals.
- By using the settings in the picture below:
- We will retry a maximum of 5 times.
- With a default interval of 20 seconds.
- We are also providing two additional optional parameters, which will dictate a random interval retry value that is between 5 seconds and 30 minutes. Logic App will then use a general algorithm to generate a uniform random variable in the specified range for each retry.
- Fixed Interval: This policy waits for the specified interval before sending the next request.
- By using the settings in the picture below:
- We will retry a maximum of 5 times.
- With an interval of 20 seconds.
- By using the settings in the picture below:
If you are wondering: what format are we using in that Interval parameters?
That is a Specify interval in ISO 8601 format. ISO-8601 standard was created with the objective of elaborating crystal clear language to talk about dates and periods and avoid misinterpretation. Where Duration (“how long“) is represented with the format P[n]Y[n]M[n]DT[n]H[n]M[n]S, where n is a number. The letters mean the representation of date and time:
- P express that this is a period format and should be the first character;
- Y for years; M for months; D for days;
- T is the delimiter for the time;
- H for hours; M for minutes; S for seconds;
Therefore PT means Period of Time.
- PT20S: parses as “20 seconds”
- PT15M: parses as “15 minutes” (where a minute is 60 seconds)
- PT10H: parses as “10 hours” (where an hour is 3600 seconds)
- P2D: parses as “2 days” (where a day is 24 hours or 86400 seconds)
- P2DT3H4M: parses as “2 days, 3 hours, and 4 minutes”
How to set up retry policies?
To set up a retry policy on an action, we need to:
- Click on the … (3 dots), present in the right corner of the action, and then click on Settings.
- And on the Setting for <action-name> panel, you will find the Retry Policy property.
It is not all triggers that support retry policies, but you probably find these features in triggers that poll data from a certain system. And to configure them is equal to the actions. To set up a Logic Apps retry policy on a App trigger, we need to:
- Click on the … (3 dots), present in the right corner of the action, and then click on Settings.
- And on the Setting for <trigger-name> panel, you will find the Retry Policy property.
I hope you enjoy this developer tip and stay tuned for the following Logic App Best practices, Tips, and Tricks.
