HTTP Messaging in Azure Logic Apps | Serverless360 Blog
← Return To Home

Use Webhooks for Async HTTP Messaging in Azure Logic Apps

There are scenarios where we want to de-couple logic across multiple logic apps. Generally, this is a straight forward endeavor, unless the downstream logic app has a long-running process. When this does occur, the client (or publisher) will experience an HTTP timeout if the request takes more than 2 minutes. This scenario is captured within the Azure Logic Apps documentation.

Azure Logic App HTTP timeout

The specific error we can expect from the publisher is the following:

{ "error": { "code": "BadRequest", "message": "Http request failed: the timeout was reached." } }

On the consumer (server) side, we will experience the client connection has timed out.

HTTP-action-Logic-Apps-serverException

Probably, the worst part of this situation is that our publisher is going to retry the request multiple times depending upon the retry strategy employed. This can result in data duplication in downstream systems.

To address this scenario, we have a couple of options. A valid option includes using Service Bus for async messaging. But, there is another option that we have, that we can implement which doesn’t involve provisioning additional infrastructure and that is using Webhooks.

Using a logic app solution involves using an action in our publisher called Http Webhook where we will call our consumer logic app and pass a Callback URL. What this allows the consumer logic app to do is perform processing as required and then make a separate HTTP call back into our publisher logic app. At a high level, the process looks like the following:

Logic-App-webhook-action

From an implementation standpoint, our publisher is quite simple, we will add the HTTP Webhook action, include the Subscribe – Method of POST, provide the consumer’s HTTP Request URL as our Subscribe – URI and then include our message Body. As part of our Body, we will include a CallBackURL and include a built-in expression called listCallbackUrl() which will include the URL that our consumer can use to call this logic app back with a response.

publisher-logic-app

On the consumer side, our implementation is also quite simple. We have an HTTP request trigger and then, for demonstration purposes a 3 minute delay to demonstrate our long running process can last for more than 2 minutes. Finally, we will add an HTTP request action. As part of this action we will include a URI that has our CallBackURL value. In addition, we will include a message Body.

consumer-logic-app

Testing

If we test our publisher logic app, we will discover that it has successfully survived a long-running process that exceeds the standard 2-minute threshold.

consumer-logic-app-testing

Conclusion

In this blog post, we discussed the 2 minute HTTP timeout setting that prevents calling long-running, downstream logic apps. But, as we discovered, we can leverage Webhooks which allow us to create subscriptions that unlock this scenario for us and without requiring additional infrastructure from being provisioned.

Author: Kent Weare

Kent Weare is a Microsoft Azure MVP, he has worked on projects for the Canadian Federal Government, a multi-national bank in New York City and integrated Health Care projects throughout Canada. His role as a Senior Enterprise Architect and Integration allows him to get involved in a variety of technology projects for a large Energy company. Since 2004, Kent has been very active in the Integration space having worked with every version of BizTalk from 2004 onwards. He has also spent time using competitor tools including Intersystems, IBM and MuleSoft. He is very passionate about Architecture especially if it involves integrating different systems.