Using webhooks in Logic Apps
It’s election season here in the US and that means polling. Polling is fine for voting but is usually not a great idea for services.
If I’ve got a long-running process (e.g. waiting for a use to login and approve a document) I don’t want to implement polling to periodically check if that process has completed.
Polling is like going on a long drive with a kid in the back seat constantly asking “are we there yet? are we there yet?”.
Adopting an event-driven approach is much more natural and loosely coupled — the long-running process can simply tell us when it’s complete instead of periodically polling. Being event-driven with RESTful services can be accomplished in many ways but one of the easiest is with webhooks. A webhook is a user-defined HTTP callback. I register my callback with the long-running service and wait for it to be invoked by a POST. No polling needed.
Webhooks are now supported by Logic Apps. You can think of an Azure Logic App as a workflow that you build and run in the cloud. With webhooks your workflow can wait for an event from a long-running process.
Here is a simple Logic App that consists of two steps. The first step POSTs a simple message to a RequestBin URL. Request Bin is a great, free service you can use to test and inspect HTTP messaging. The second step is another HTTP action but it has a strange icon on it — it also doesn’t render properly in the designer. This is because webhooks aren’t yet supported in the Logic Apps Designer (this is coming soon). Webhooks are supported in the code view so let’s look at some code.
Here is (most of) the code view of our simple Logic App (Logic Apps use JSON under the covers). Note the second step of the workflow surrounded by the red box. Looking at this code we can see some interesting things…
If you look at the inputs you’ll see it contains a subscribe construct. The @listCallbackUrl() enables us to retrieve the URL for firing the webhook (where the long running process can “publish” its event to). The type has been changed from Http to HttpWebhook. The URL being used here came from RequestBin. These changes had to be made manually in code view because the designer doesn’t yet support webhooks. This “Http_2” step originally looked like the “Http” step right above it.
What happens when we run the workflow? It stops and waits for the webhook we subscribed to:
If we go over to RequestBin we can we copy the webhook URL and use it to POST back using a tool like Postman or Fiddler (click to enlarge):
Now that the webhook fires (POSTed back) the workflow will wake up and continue running:
