BizTalk Ordered Delivery – One way HTTP receive and SQL Send port

Posted: November 26, 2008  |  Categories: BizTalk Uncategorized

I’ve done some experimentation around this as a proof of concept a while ago. With all the hundreds of posts on Dublin and Oslo and .NET 4.0 there’s nothing better than to relax with a bit of BizTalk 🙂

To ensure ordered delivery between a one way http receive location and a SQL send port I had to set ordered delivery on the receive port in the orchestration and create a singleton orchestration with correlation.

As I expected, just setting ordered delivery to true on the orchestration port and on the final destination send port does not work. You need a correlation in there so that the same orchestration processes the messages that need to be processed in order. I created a correlation on the receive port’s name (BTS.ReceivePortName) so the orchestration is always running and looks like this:


This is the ordered delivery set to “True” when you select the receive port on the orchestration surface:


With this I had my test app create 80 http requests alternating between a large file (Anne Lotsachildren) then a small file (Julie Fewchildren) and the results were always correct:


If I didn’t use a correlation and a singleton orchestration it did not ensure the order, even when setting the orchestration port to ordered delivery and the final send port to ordered delivery without the correlation. BizTalk just initializes a new orchestration instance and processes the message.

To quote from the BizTalk help:

Conditions for End-to-End Ordered Message Processing

To provide end-to-end ordered delivery the following conditions must be met:

  • Messages must be received with an adapter that preserves the order of the messages when submitting them to BizTalk Server. In BizTalk Server 2006, examples of such adapters are MSMQ, MQSeries, and MSMQT. In addition, HTTP or SOAP adapters can be used to submit messages in order, but in that case the HTTP or SOAP client needs to enforce the order by submitting messages one at a time.
  • You must subscribe to these messages with a send port that has the Ordered Delivery option set to True.
  • If an orchestration is used to process the messages, only a single instance of the orchestration should be used, the orchestration should be configured to use a sequential convoy, and the Ordered Delivery property of the orchestration’s receive port should be set to True.

As you might expect this performs a lot worse than if you don’t have ordered delivery and a singleton – but it is very useful if ordered delivery is your priority.


Download the sample code here



Thiago Almeida

7 thoughts on “BizTalk Ordered Delivery – One way HTTP receive and SQL Send port”

  1. Thanks for the post, I was just starting to look at this and (as a beginner) not getting the result I expected

  2. Thanks a lot. This saved my time too. See my articles at
    Google Keywords: Karamchetti + BizTalk

    1. Hi Edwin,

      I’ve uploaded the sample code to the post – it will some configuring to get it going (need to create the HTTP virtual dir in IIS, create the database from the SQL file in the sample, etc).


  3. Hi Thiago,
    Nice post. I’ve a question for you: as you highlighted above, the documentation asserts “In addition, HTTP or SOAP adapters can be used to submit messages in order, but in that case the HTTP or SOAP client needs to enforce the order by submitting messages one at a time”. What about if the HTTP Receive Location concurrently receives messages from multiple clients at the same time and your BizTalk app runs on a multi-core/multi-CPU server? In this case, even running the BizTalk app on a single machine, the HTTP Receive Location could not guarantee that messages are published in the proper ordered fashion to the MessageBox. Did you try this scenario? I suspect that in this case you should also set the following registry settings (see 1 to control force the HTTP Adapter Receive Handler to receive and post messages one at the time:
    – RequestQueueSize
    – HttpReceiveThreadsPerCpu
    I didn’t try out so I cannot confirm my assertion. 😉 Thanks!

    1. Hi Paolo, you are correct – I think the note on the documentation is only for when there is only one HTTP client pushing messages to BizTalk. I haven’t implemented any ordered delivery for HTTP receive before (other than proving it can be done for this post), but the HttpReceiveThreadsPerCpu setting is pretty interesting though, supposedly the one thread would put the messages in order into BizTalk. But it doesn’t really matter as there is usually no way of ordering the multiple senders so a different approach needs to be taken like a singleton orchestration with correlation on a specific value in the messages that allow them to be ordered.

Comments are closed.

BizTalk Server

Over 500+ customers across
30+ countries depend on BizTalk360

Learn More

Manage and monitor serverless
components effortlessly

Learn More
Business Users

Monitor your Business Activity in iPaaS
or Hybrid integration solutions

Learn More

Back to Top