Hi All! Today I just wanted to take a break from the Blazor Gamedev series and talk a bit about Azure. Specifically about Logic Apps and how to handle failures gracefully.

For those of you who don’t know what a Logic App is, I would strongly recommend to take a look at this video first:

Nice isn’t it? In a nutshell, an Azure Logic App allows the visual creation of fairly complex workflows and integration between different systems. It all starts with a trigger, which might be a message in a queue or an HTTP call or whatever. Then we have the possibility to drag’n’drop’n’configure all the different Action blocks that will build up our nice workflow.

And in case we need something more complex, we can always write a Function and include it.

Let’s do an example. Imagine you want to react to an HTTP call, fetch some data from a DB, manipulate it, and give back a 200 response. The workflow would look more or less like this:

But wait! Something bad happened when we were trying to get the entity from the DB. Now our callers won’t get a 200 back! How can we handle this?

The first step is to simply split the execution in two branches after the DB node:

And then configure the left branch to execute only when an error occurs. This can be done very easily by expanding the node, clicking on the 3 dots and clicking on “Configure run after”:

</figure>

Now all we have to do is select under which the conditions we want our branch to execute:

That’s it, nothing else. The Terminate node will allow us to select what return value we want to give the users and how the App execution will appear in the execution history (for example as “failed” or “successful”).

In case you also want some details about _why **_the DB block failed, there’s a bit more work to do. Let’s take a look at the blocks:

We can’t redirect the error result straight away to our Queue block, but we have to extract from the response payload of the DB block. One way to do this is to surround it with a Scope **block and then Compose the output before redirecting to the Queue. For more details about how the Compose Action works, there’s an awesome page in the official docs. Simply stated, it allows us to aggregate and compose (aehm…) the result from various blocks into whatever form we need.

In our case all we need is something like this:

You might also have noticed that I changed the original flow to return a 202 immediately after the Trigger. This will allow the App to execute any long-running operation we need without keeping the caller waiting for us.

Did you like this post? Then