This blog compares a BizTalk to an Azure solution for HTTP polling. This can be expensive because a service is called even when there is nothing to be processed.
Requirements
Food suppliers get orders from a restaurant by polling a web service. Furthermore the solution must pick any orders up within 15 minutes. A response with a HTTP status code of 200 contains as a JSON array of orders. Alternatively a HTTP status code of 202 and an empty JSON array means no orders. Additionally the restaurant API contains methods to post an order acknowledgement and an invoice.
Vishal Modi’s Scheduled Task Adapter BizTalk solution
Vishal Modi in this article lists some options as;
- A windows service which runs at scheduled time creating a message which BizTalk consumes. Subsequently a RESTful send port subscribes to that message and finally does the service call.
- A SQL task that runs on a schedule and does the same as above.
- A custom task invoking the RESTful Service from the Scheduled Task adapter.
The article goes on to describe the second option in detail. This is shown in the diagram below.
I had not seen Vishal’s elegant solution until I had completed my solution but I had rejected using the Scheduled Task adapter because I wanted to use out of the box BizTalk adapters. The interested reader should examine that solution themselves.
My BizTalk Solution
I am going describe an option in which a WCF-SQL polling receive adapter sends a message to the message box on a schedule and a WCF-WebHTTP adapter sends the request to the restaurant API to get the orders.
Firstly a WCF-SQL Adapter polls a database table every 15 minutes. The polling statement on the adapter is;
SELECT Task, Operation, Source, GETDATE() AS PollingTimestamp FROM [dbo].[ScheduledTask] WHERE Task = ‘Poll HTTP GET’ AND [isEnabled] = 1
This generates XML that contains a scheduled HTTP poll of many sources , one for each row in the table. The XML is shown below;
Using this XML in the Generate Schema for XML wizard yields a schema that represents the message. ( Added 11/02/2019)
In the next step a XML Receive pipeline on a WCF-SQL receive location de-batches the XML. This happens because the TypedPolling schemas is modified to be an envelope, with body XPath set to TypedPollingResultSet0 and Max occurs of 1. Additionally the pipeline promotes Task, Operation and Source for routing to the WCF-WebHTTP adapters that we want to trigger.
Finally configuring WCF-WebHTTP Solicit Response Send Adapter with filters on the promoted properties, the HTTP Polling solution is complete. The observant readers sees the custom pipelines that process outgoing and incoming requests. These pipelines are not required for this HTTP polling solution. I use these for posting form data and processing JSON as part of the broader solution. The Snd_MIME_BRE_SAB is not used by the GET request because the XML body is suppressed.
Recapping or story so far, I show how to poll a HTTP endpoint using BizTalk Server. My solution only uses standard out of the box components whereas the alternative by Vishal Modhi uses custom components.
We will now consider how the same solution might be achieved using Azure Logic Apps.
Logic App solution
A HTTP polling Logic App is simple, easy and quick to set up. It too me less than a minute to have it up and going, contrast this with the BizTalk solutions above which take hours. First you add a recurrence trigger to run every 15 minutes and then add a HTTP action to request the JSON order from my endpoint.
Conclusions
The Logic app solution wins hands down with respect to brevity, simplicity and time to deliver. Why would anyone bother doing this in BizTalk server anymore? The only reason might be because of expensive of polling and returning nor orders. Even so you would have to be doing a lot of polling to match the cost of a BizTalk server license plus ongoing server maintenance costs.
Postscript
Toon VanHoutte pointed out that a polling Logic App is even simpler.
Indeed an HTTP trigger is all that is required. Go Logic Apps.
