Pattern & implementation for making long Async Http calls in Microsoft Flow : (part 2: the HTTP Webhook action)

Last week I’ve illustrated how to invoke very long external calls from Microsoft Flow by using the Flow (actually the logic apps) HTTP action which timeouts after 2 minutes. The approach was polling on a specifi url provided by a http 202 response.

Now we can use the Flow (actually logic apps) HTTP Webhook action as long as the external call can store a callback url; this is the foundation of webhooks in general.

I couldn’t find any simple Flow example of what I really wanted to do, so here we are.

This is not always the case, but a decent & well written HTTP service is usually supposed to handle the HTTP 202 error and to manage callback urls.

One of the feature of the Flow HTTP Webhook action is that it can pass the callback url and wait for more than 2 minutes if necessary. The url can be any kind of service url (like an Azure function,…). But the url can also be the one of the running workflow instance as well 🙂 and that is what I would like to illustrate here because some of my customers don’t have a paid Azure tenant where they could write custom code; they just have an Office 365 E3 license (including Microsoft Flow). (We can also debate whether writing Azure functions or even javascript code is still part of “citizen development philosophy”, but anyway, let’s be pragmatic…).

Here is my caller workflow :

My caller workflow will invoke a long running service that I’ve implemented as a service Flow like last time; more on this later.

But the key thing is that here I can pass my current flow url by using the expression listCallbackUrl(). It looks like this expression can only by used in the HTTP WebHook action, not in HTTP action, nor in a variable (I guess the current flow endpoint is determined only in this webhook action).

Now let’s take a look at my service flow :

It starts with an Http Request trigger, but the thing is it will receive the callBackurl in the body; this callBackUrl will be stored in variable (Ive used the expression TriggerOutput()?[‘callBackUrl’] to find it)…The Delay simulates a duration of 3 minutes (far beyond the Max 2 minutes); I don’t use the Response object here but I call the CallBack Url via the classic HTTP action:

When I run the Caller Flow the call flow is invoked; after 3 minutes I get this :

And the callBack url is well invoked by the HTTP action from the service (so the server calls the client back) :

And now when I check the client flow :

So yes it works! The main benefit compared to the polling approach is it is cleaner, simpler and you don’t waste 1 polling delay cycle : when the response is available it is returned immediately. This works as long as the service can handle callback url. Power users can easily understand this.

So the 2 approaches (polling -see my previous post-and webhooks) make sense and it is pretty clear we should use webhooks in most scenarios when it is possible (not just for Flow).