Error handling within Azure logic Apps

Oguzhan YIGIT
Published by Oguzhan YIGIT
Category : Azure / Logic Apps

Introduction to error handling with Azure Logic App

As development way is, error handling with Azure Logic apps is slightly different than what I was used to. Exactly, this post is about an overview of the components, options an behaviors offered by Azure Logic Apps.

Before going ahead, I would like to talk about the kind of exception I’am facing and handling. I always made a difference between known and unknown issues (handled and unhandled exceptions). While using common languages such C#, JAVA… you are supposed to use similar concepts : a try bloc followed by a catch a bloc, building typed errors… forget all with logic apps because it brings its own concepts to handle errors.

Exception handling with Azure Logic apps

Global exception handling with Azure Logic apps

Error handling is a an important part of each of our process design. We are all worried to be warmed when errors occurs. As genius as you can be, there will always be some unhandled cases. Windows Forms, WCF services, ASP.Net applications… all gives a handler when an application error occurs. But no, logic apps don’t. So we have to handle our process exceptions in each of our flows.

Ok, let setup a new logic app :  a simple process triggered from an http request. When designing a logic app, I’m always starting by adding 2 scopes. First one is dedicated to business process while the second one is dedicated to error handling.

global error handling in logic apps

The error scope will do whatever is needed to handle the exceptions. It might be sending an email to end users or administrators. If you are using Azure service bus to manage application messaging, then you can send extracted messages to the queue or topic dead letter within the error scope. Check following article about reliable messaging with Azure logic apps and Azure service bus for more inputs on how to use Service to get reliable process’. In our case, we also need to reply with an http error code. Just add a “Response” shape in global error scope and reply with the error you want to (500 for server errors).

Now, to run error scope only when errors occurs, we need to set the scope “run after configuration”. Use the 3 dots on the top right of the scope and choose “configure run after” link.

Configure logic app run after

It’s easy to get a handler for exceptions. Just set the run after to “has failed and has timed out”. Now error scope within your logic app will only run if the business process scope failed or timed out.

Using Run after properties to handles specific exception

In case if you need to handle a specific error within your process, you will need to compose with the same behavior but Inside the business scope.

Let suppose our process should get an order detail by calling an azure functions and then store data into a database. See below, the process flow design on Azure portal :

logic app process sample

Well, I agree it’s a bit simple but the purpose is how to handle specific errors. So I will let you imagine that our flow has to do some more operations after inserting the row. In my side, I’m focusing on this first step where I want to do some extra stuff if an error occurs while calling my Azure function.
Specific error handling with azure logic app
So, I just added 3 new shapes between the call of the Azure function and between the insert row command :

  • first, sends an email to the end users
  • Second, replies to caller (our logic app is triggerd by an http request so we need to reply)
  • Third, terminates current flow (use “control” shape to do that)

Last configuration is about to execute :

  • error handling only if an error occurs
  • Insert row only if no error occurs

So let configure our flow as showed in following diagram :

Configure run after for specific errors in azure logic app

Keep in mind, by default, a shape is executed if previous shape is successfully executed. So, if we configure the “send error mail shape” to execute in case of an error, then, the reply and terminate shape will also execute. I just ensured that the “insert row shape” will execute only if there is no error by setting run after configuration to “is skipped”. Indeed, if terminate shape is skipped, that means there is no error in the process and that the row has to be inserted to the target database.

Working with error output

When you get an exception, you ll always want to get and show the error message. I’m used to get the result of the flow and look for  the error message inside. You can get the whole business scope result by using the “results” array from your logic app. For instance, just put Inside the body of your email the following code : “@results(‘Business_scope’)”. Well, of course, if you want to get only the result of the shape in error, you might have to parse “Business scope” result and find the shape in error.

Finally, you might want to display some error data in Azure portal. Using the ouptut data of your process will make it ! Check my friend post about how to display relevant information from logic apps. Have fun !