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:
- #1 Logic App Naming Convention
- #2 Actions Naming Convention
- #3 Add comments
- #19 Protect your Logic Apps (Part I) – Using API Management to expose the Logic App and Implement IP Addressing Restriction
- #19 Protect your Logic Apps (Part II) – Secure data in the run history by using obfuscation
And some tips and tricks:
- #4 Using Scopes
- #5 Delete comments
- #6 Error handling configure run after settings
- #7 Learn from failures
- #8 Expressions nightmare
- #9 Control your connectors (API connections)
- #10 Fix connectors (or API connections)
- #11 Connectors naming convention
- #12 Choose your developer tools properly
- #13 Logic App (Standard) vs (Consumption)
- #14 Implement good governance policies
- #15 Get the error message
- #16 Roll back to a previous version of an Azure Logic App Consumption
- #17 Using other HTTP Methods then POST
- #18 Foreach Parallelism
- #20 Accessing Runtime Settings (Part I) – Logic App Consumption
- #20 Accessing Runtime Settings (Part II) – Logic App Standard
- #21 Moving or organizing shapes inside Visual Studio Logic App designer
- #22 The if() expression function
- #23 Debatching Messages
- #24 Configure correctly your Retry Policies
- #25 How to send a well-formatted custom HTML Email
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.
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.
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.
- 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.
- 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.
- And in the Settings for the ‘Response’ panel, set the Asynchronous Response option to true (On). Then click Done.
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.
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.