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.
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.
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:
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.
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.
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.
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.
