Group Actions Logically Using Scopes
Configure Run After settings allow you to decide what a subsequent action should do in the event of a previous action succeeding or failing.
But, what happens when you have a more complex logic app and you have logically related actions that must succeed or fail as a group?
Within Azure Logic Apps, we don’t have the luxury of using distributed transaction coordinators, but we do have other capabilities that manage this type of scenario.
We can also chain subsequent Scope shapes that will allow us to implement the Try-Catch-Finally pattern as illustrated below.
Our business scenario includes the need to track our position in a specific entity. But in order to track this, we want all steps to succeed in our Try scope. If one of our steps fail, we want to log a failure in our Catch scope.
To create this solution in Logic Apps, we can perform the following steps:
- Create a trigger that will start our logic app
- Create a variable to store our equity symbol
- Create a scope from the Add an action menu
- Rename our scope to indicate it is our Try scope
- Perform our actions based upon business process
With our Try scope set, we now need to create our Catch scope. The Catch scope will only be invoked when one or more of our actions from our Try scope fails. To configure this, we will perform the following steps:
- From the Add an action menu, add a Scope action
- Rename it to reflect it in our Catch scope
- Add any compensating actions required to log the failure and/or roll back previous
- actions that may have succeeded
Since we only want the catch scope to execute when there was a failure, we need to configure our Run after settings and ensure that has failed and has timed out are selected.
Lastly, we need to configure our Finally scope that will execute regardless of whether our previous scopes have failed or succeeded.
Since we want the Finally scope to run under all circumstances, we need to enable the following Configure Run After settings.
Let’s now run a test where we encounter an error to validate that our exception handling process runs as expected. As you can see, we had an error calling our SQL stored procedure. Our Catch scope was correctly called where we were able to log our error. Our Finally scope was also correctly called.