views:

217

answers:

2

We have a BizTalk application where the order of messages being inputted is very important and has to be kept, meaning they have to be outputted in the same order. Normally ordered delivery would do the trick here.

However I read that ordered delivery is only guaranteed when you connect a receive location directly to a send port. The moment you use orchestrations the order delivery isn't guaranteed anymore. Is there a way to work around or fix this? Because this kind of ruins our whole application and we've been working on this for months.

I read a work around from Microsoft where they use an extra field which has a counter and where they use an end orchestration which checks the counters. But this is way too much work for us to do now. So this work around is a no go. Plus not all messages are translated which creates holes in our flow and not all messages are coming from the same source either which makes this work around useless anyway.

Any other ideas?

+1  A: 

Check out this page. It explains that if you have an orchestration that follows the singleton pattern to ensure only one instance of the orchestration exists, and you make sure you set the orchestration's receive port to ordered delivery, than you should get a valid end-to-end ordered delivery scenario

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.

Yossi Dahan
We use MQSeries adapter, ordered delivery is obviously on. The problem is, setting the ordered delivery of orchestrations won't do the job, because we use different orchestrations. I'm guessing it's just impossible like this, because not every orchestration will go equally fast, that's why I need a work arround.
WtFudgE
The different orchestrations bit certainly makes it more challenging, especially if you need ordered delivery across them, but - and its hard to be certain without knowing the details and spending some time on the design - it may still be possible if you have one orchestration picking up all requests and then coordinating the work carefully *(by starting other processes and correlating responses, before processing further requests).As with any ordered delivery implementation, you will seriously hurt throughput and latency, of course, but I'm sure you've taking this into account.
Yossi Dahan
The main challenge, if you can design such a process, is maintenance.
Yossi Dahan
We've used the singleton pattern in orchestrations to achieve this very successfully using HTTP sneds and receives. A word of caution. There is a check box on the send port to fail if an ordered message can't be delivered. This will stop the whole train and will do even worse things if you don't have good error handling in the orchestration. Just think about if you want the whole train to stop on a failure or if you want the bad car kicked to the ditch.
ChrisLoris
+1 I belive that Yossi's answer is the best solution for the problem. Ordered delivery with sequential convoy is the classic solution here, and if you must have multiple orchestrations than you will need some sort of 'Master' orchestration that manages things. It will be extra work, but there is no out of the box pattern to do what you want.
David Hall
A: 

Im currently working on the exact same problem, would like to know how you ended up solving it..

Wessam Zeidan