Posted January 31, 20231 yr 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: Action failure due to non-default codes for retry policy being returned; for more details about retry policies, check the following link: Handle errors and exceptions in workflows - Azure Logic Apps | Microsoft Learn Delay in data ingestion, for example, sentinel ingestion delay; for more details about this issue, check the following link: Handle ingestion delay in Microsoft Sentinel | Microsoft Learn Service is intermittently unavailable. In this article, we will show how to implement this custom retry strategy as part of your workflow. Steps Execute the required action. Check if success code or required data are returned: If yes, go to step 3. If no, execute the following steps inside until loop: Delay for X minutes; X delay time can be set as required depending on the failure cause. Execute the required action again (same as step 1). Check if success code or required data are returned: If yes, exit until loop and go to step 3. If no, go back to step I and execute same steps again. [*]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: Continue reading...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.