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
Enjoy!
Thiago Almeida
Thanks for the post, I was just starting to look at this and (as a beginner) not getting the result I expected
Thanks a lot. This saved my time too. See my articles at CodeProject.com
Google Keywords: Karamchetti + BizTalk
Hi Thiago
Is it possible to have a sampel of this project
Regards..
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).
Regards,
Thiago
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 http://msdn.microsoft.com/en-us/library/aa547969(BTS.20).aspx)to 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!
Ciao,
Paolo
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.
Thanks Thiago, I basically thought the same thing. 😉