Why We Need Exception Handling In Logic Apps
Everyone who has worked with Logic Apps is familiar with the error An action failed. No dependent actions succeeded. This is a very generic error that offers no clear information on what went wrong. Typically this error occurs when a nested action fails, for example an action within a scope or a foreach.
What we actually want is a way to retrieve the actual error from the action and use that in our logging. To achieve this we need to implement several best practices in our Logic Apps.
Try Catch Setup
Our first best practice is to implement a basic try catch setup in our Logic Apps. By implementing this we make sure that every error that occurs ends up in our catch scope where we can implement functionality to retrieve the actual error we want to log. This basic setup looks like this, note that we use the runafter to determinate that the exception handling scope only runs if the scope fails.
Common Exception Handler
Next we want to create a common exception handling Logic App which we can call through a webhook. This way we have a common component that is responsible for handling all our errors and retrieving the actual error information, to do this we need the following setup in our environment.
As you can see in the diagram all of our Logic Apps will call the Generic Exception Handler Logic App through the use of the exception handler scope, the generic exception handler Logic App will receive the webhook, call an Azure Function and return a response asynchronously that contains the actual error information. The Azure Function is where the magic happens with regard to retrieving the actual error from the Logic App instead of An action failed. No dependent actions succeeded, but we while dive a little deeper into this later on.
Here is an example of how to call the generic exception handler Logic App and how to process it’s response.
The code for the exception handling scope is as follows:
Basically it comes down to supplying our common exception handler the necessary information, and if it returns a Failed status we terminate the Logic App accordingly using the correct error code and description.
This common exception handler can not only be used to retrieve the actual error information, but also for example to send out an email or create an issue in a helpdesk system. Having this functionality in one place makes it very easy to change your exception handling flow!
Retrieving The Actual Error From The Logic App
As described earlier we are using an Azure Function to retrieve the actual error from the Logic App, to do this we are using this API from Microsoft.
As stated in the documentation we call the following endpoint http://GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Logic/workflows/{workflowName}/runs/{runName}/actions?api-version=2016-06-01 which will return a list of actions from the Logic App run.
In our code we now need to loop over the returned actions, if one the actions has repetitions (for example a foreach action) we need to call this API.
Now that we have an entire list of actions and its results we can parse the data and check if an action failed and if so what the error code and descriptions are. We return this information back to the common exception handler Logic App which in turn will send this as an asychronous response back to original Logic App.
This completes our exception handling process and makes sure that in our logging we get to see the actual error instead of the dreaded An action failed. No dependent actions succeeded!
This logic does contain some complexity and you need to make sure that this works correctly and retrieves the right data. Fortunately for Codit’s customers this Azure Function (where we support both Logic App Consumption and Logic App Standard) is included in our Invictus Integration Platform so we can easily implement our best practices around Logic App exception handling.
An Example
Let’s finish up with a small example.
In one of our Logic Apps we send out data through the HTTP action, this is however from inside a condition action. When the HTTP action would fail it would previously show the An action failed. No dependent actions succeeded.
However, since implementing the above best practices are logging now looks like this:
A big improvement which gave us quick insight in our logging as to what caused the failed Logic App run!
Subscribe to our RSS feed