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 :

callwebhookflow

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 :

longserviceflowwebhook

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:

longserviceflowwebhook2

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

serviceFlow3

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

serviceFlow4

And now when I check the client flow :

serviceFlow5

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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s