Logic App Best Practices: #26 Call Asynchronous child Logic Apps

Welcome again to another Logic Apps Best practices, Tips, and Tricks. In my previous blog posts, I talked about some of the most essential best practices you should have while working with the Azure Logic App:

And some tips and tricks:

Today I will speak about another important Best practice, Tips, and Tricks that you must consider while designing your business processes (Logic Apps): How to call asynchronous child Logic Apps.

Logic Apps Asynchronous Patterns

Call Asynchronous child Logic Apps

By design, Logic App will always have a synchronous communication pattern, meaning you call it, and you will have to wait for it to finish processing, but… that doesn’t mean that we can implement an Asynchronous processing pattern. We can say that we can implement an Asynchronous processing pattern over a synchronous communication pattern. Are you confused? So, let’s go deep and explore this functionality.

If you come from a BizTalk Server background, we know that we can use two shapes inside our business processes, aka orchestrations:

Call Orchestration
Start Orchestration

In BizTalk Server, that means that Calling an Orchestration will use the same thread to run another orchestration, while using Start Orchestration will create a new thread to run the started orchestration. A Call Orchestration returns the control back to the caller. A Start Orchestration shape starts the orchestration in a non-deterministic way.

In conclusion, Calling an Orchestration will be a synchronous operation where the caller waits for a response (that also means that we can pass inputs and receive outputs parameters), while Start Orchestration is an asynchronous operation (that means we can only pass input parameters).

The question here is: How can we have these same capabilities in Logic Apps?

Because the call of a child Logic Apps is basically calling a service endpoint over HTTP that means that by default it will expect a response back. That’s why I said before that usually, a Logic App would have a Synchronous pattern, meaning you call it and you will have to wait for it to finish processing.

Nesting Logic Apps

But with a simple configuration and design pattern in our child Logic Apps, we can indeed implement an Asynchronous Request-Reply pattern.

The way to achieve this is:

To add a Response action right after the When an HTTP request is received trigger action
- Note that to call a child Logic App using for example the Logic App connector, we need to use the When an HTTP request is received trigger in our child Logic App.

HTTP response workflow

On the Response action:
- On the Status Code property, set the value to 200.
- And we can define the Content-Type to application/JSON in the Header properties, but this is optional since we are not going to provide any response body.

Asynchronous Request-Reply pattern

Now the main trick is to, on the Response action, click on the … (3 dots) in the upper right corner of the shape and select the Settings option.

HTTP response workflow

And in the Settings for the ‘Response’ panel, set the Asynchronous Response option to true (On). Then click Done.

Asynchronous Request-Reply pattern

You can now continue implementing the business logic inside your child Logic App, which will be processed kind of side-by-side with the main process.

Logic Apps Asynchronous Patterns

Probably it’s not the most beautiful solution, but it will set the path for the async pattern we’re looking for. The ideal solution was to have a flag properly that we could define on the caller action to automate this and keep processing the main process if it has received the HHTP 202 Accepted. But so far, this feature is not available.

I hope you enjoy this developer tip and stay tuned for the following Logic App Best practices, Tips, and Tricks.