Exception Handling Using Configure Run-After Settings
- Updated on 27 Dec 2018
- 1 minute to read
In a world of connected services running across data centers and public clouds world-wide, errors are bound to happen. These errors can be related to underlying technical infrastructure issues or related to missing or unexpected data.
Regardless of the reasons, Logic Apps developers need to plan and react when these exception events occur.
Java and .NET developers are very comfortable using try-catch-finally semantics when it comes to error handling. However, in Azure Logic Apps, developers use a different approach, to achieve similar behaviors.
Let’s take a simple scenario and demonstrate how we can perform exception handling in Logic Apps. In our scenario, we want to run a logic app on a recurring schedule. Within this logic app we call a custom connector and for each record returned from the connector, we insert it into a database.
The design of this logic app is pretty simple and takes only minutes to build. However, we soon discover we have an error calling our custom connector.
By default, subsequent actions will only run when the previous action was successful.
As a result, we don’t add any records to our database as the insert row action has been skipped. If we have dependent business processes on records being added to SQL Server, these business processes are now broken.
When errors occur, we need to detect this situation and provide some actions such as sending an email notification, or other compensating actions. To achieve detecting an error event and then providing logic to handle the error, we will configure a parallel action below our custom connector call. Within each stream of the parallel action we then specify our Configure run after settings.
When our custom connector call succeeds, we navigate down the left-most path and perform our database inserts. When our custom connector fails, we navigate down our right-most path and send an email notification.
This example is an introduction to Configure run after settings to achieve simple exception handling. For more complex scenarios, we can take advantage of scopes to logically group related actions and then track whether the group of actions has succeeded or failed.