Exception Management in any Solution will Play a Critical Role in Designing Solutions. In Dotnet, you Probably do it with Try-Catch Blocks. In BizTalk you group the Actions in Scope and add the Exceptions. Similarly, In Logic Apps, we can do the Exception Handling using different Techniques. I will try cover by Describing a Few Scenarios.
Different Components of Logic Apps:
Below are the Different Components which can help you to Perform Exception Handling in Logic Apps.
- Custom Retries
- Run After
Retry Policies are based on Execution Code (429 |5XX). It can be Configured from the Designer itself. By default, it will be 4 Retries for 20 Sec. You can Change the Mode of it in the Settings Like Below.
We can keep it to Fixed to Interval to Execute it on Schedule. For Example, if you Keep the Count to 2 and Interval to PT 10S this will Execute for every 10 Seconds only for 2 Times.
Consider a Logic App Like below, where we are receiving the Request and calling the Function and returning the Response of it.
I have made the Function deliberately Return 500 Status Code, when I ran it, I got the Error. I have configured the Retry Settings to execute 2 times in 10 Seconds span.
If I go Run History and Check the Runs you will find it Like below
You can go into each of the retries and Check the Start Time and End time as well.
In the above way, we can use the retries to help us with Exceptions. we can also use the do Until Control to give us more control on it.
For Example Do Until Status Code=200.
Run After helps you to Define Execution Order. Based on the Status of Previous Action, you can Define the Success and Failure Paths. It can be configured from the Designer.
For Example: I have used the above Example which I had for Retry and Modified it like below
I have used the Parallel Action Shape and added Terminate in the Other Branch. For that Terminate Shape I have Configured the Run After like below
I have Configured the Terminate shape t Show as Cancelled Like below
When I Run this Logic App, in the Run History I will see my Status as Cancelled.
In this way We can use the Run After to determine the Success and Failure Paths.
Scopes helps you to group a Series of Actions. if any Action Inside the Scope Gets Failed you can Catch it and Process it accordingly. Scope can take any action or flow control. You can use Multiple Scopes if needed. It can simplify the Exception Management.
Example: if we can take the above one and group the Actions Like below
I have Grouped the HTTP Trigger2 and Response in try Scope and if it fails Scope-Catch will execute. That is done using the Run-After as I have shown in the above Section.
Inside the Compose Shape, I have used @result('Scope-Try') which gives you an array of all actions Details inside Scope whether they all are Successful or failed with the Exception Message.
Then, I have used Filter array to find out Which is the one got Failed Like below
After that I have used the For Each Shape so that I can assign the Exception Message to my Variable.( I have Declared the Variable at the Top).
Then I have Used the Response to just send it back Like below
Once I hit the Request now, I just get the Exception Message.
In this way, we can group the Actions inside Scopes to Perform Efficient Exception Handling.
These are the ways we can do our Exception handling. Below are the Few Takeaways from the above
- Plan Exception Handling from the Start
- Use Scopes from the Start. If required, you can use multiple Scopes as Required.
- Set up the Right Retry Policy