BizTalk: Ordered Delivery


It is one more description of the Ordered Delivery (OD) in BizTalk.

The main article about it is in MSDN.

Here I am discussing the BizTalk Ordered Delivery “implementation details”.

OD Considerations

  • Ordered Delivery (sequential) mode is opposite of the “Parallel Delivery” mode. Parallel Delivery is the most productive mode; the Ordered Delivery is less productive mode.
  • Transports such MSMQ and protocols, supporting the WS-ReliableMessaging, are the protocols supporting OD. Other protocols as FTP, File, SQL, SMTP etc. do not have notion of the “order”.
  • BizTalk application usually is a part of the whole message workflow.
  • There are two approaches in the OD implementation:
    • All steps of the message workflow independently support OD.
    • A Destination System implements the re-sequencing and manages lost and duplicate messages.
  • Order is relative. Sequences can be ordered regards one or several parameters. For example, OD for the Company or for the Company + Department.

OD and the BizTalk Architecture

  • MessageBox is an implementation of the Message Queue. OD is an intrinsic feature of the MessageBox.
  • The BizTalk Server works in the Parallel Delivery mode by default.
  • There are three parts in the BizTalk message exchange outside of the MessageBox in relation to OD: Receive Locations; Orchestrations; Send ports.
    • Receive Locations support OD on the Transport level (say, MSMQ and some WCF adapters).
    • OD in Orchestrations is implemented by the sequential convoy pattern.
    • Send ports support OD for all static adapters.
  • The BizTalk Pipelines (part of Receive and Send Ports) always process messages in order using streams.

OD and Ports

To force Send Ports work in order we set up a flag the “Ordered Delivery” in Send Ports, then the BizTalk MessageBox takes care of implementing OD.

To force Receive Locations work in order we set up flag the “Ordered Delivery” option in the Receive Location Transports, whenever is possible. Then the BizTalk Transport Adapter takes care of implementing OD.

Ordered Delivery Send Port instance works as a singleton service. Since start it stays in Running state. It will not recycle if we restart its Host Instance. We could manually terminate it, if we want.


OD and Orchestrations

MessageBox implements the convoy message exchange pattern [See Using Correlations in Orchestrations]. See the detail convoy description in the BizTalk Server 2004 Convoy Deep Dive article.
It is not just a design pattern that developer should follow. There are special mechanisms inside MessageBox responsible for implementing OD.

OD and Orchestration: Sample


Imagine four Orchestrations which implement four approaches to the sequencing.

The first is the ProcessNoOrder Orchestration. It processes all messages without any order. One ProcessNoOrder Orchestration instance will be created for each inbound message.

The ProcessInOrder Orchestration processes all messages in one sequence. Only one ProcessInOrder Orchestration instance will be created.

The ProcessInOrderByCompany Orchestration processes messages in sequences correlated by the Company value (A, B, C, D, etc.). The separate queue is created for each new value of the Company. Messages inside queues are processed in order. Queues for different Companies are independent. A separate ProcessInOrderByCompany Orchestration instance will be created for each new Company value.

The ProcessInOrderByProduct Orchestration works exactly as the ProcessInOrderByCompany Orchestration but correlated by the Product value (xx, yy, etc.).



By default all Orchestration and Messaging Service instances works in the Parallel Delivery mode with maximum performance.

If we check up the Ordered Delivery option in Send Port, BizTalk will initiate the Send Port instance as a singleton service. It is always a single instance. We don’t have the flexibility of the Orchestration where we could tune up “the proportion of the sequencing” and could control the recycling of the service instance.

Send Port OD could be in two states, on and off:

  • OD is off: a service instance per message, one message per queue, maximum performance.
  • OD is on: one infinite service instance, all messages in one queue, minimum performance.

Orchestration OD could be in two states also, on and off:

  • OD is off: a service instance per one activating message, one activating message per queue, maximum performance.
  • OD is on: one or several service instances, one per new correlation set value; all correlated messages per queue; performance is from min to max, depends ot the correlation set..

Carefully designing the correlation sets we could tune up the performance of the Orchestration. For example, if we only care of the document order for each separate Company, we include the Company to the Correlation set. If we had thousand documents related to hundreds companies, the performance will be near maximum. If there are only two companies, the performance will be near minimum, and we should consider improving the correlation with one more parameter.

Orchestrations and Zombies

Zombies are big problem of Convoy Orchestrations. See BizTalk: Instance Subscription and Convoys: Details article with description of this problem. This problem could be mitigated but could not be completely removed. We are waiting a new version of the BizTalk Server where this issue will be targeted.

BizTalk Server version Next, Ordered Delivery and Zombies

It is possible the BizTalk Server version Next will implement the automatic Ordered Delivery for Orchestrations, with pattern similar to the Ordered Delivery in Send Ports.

Three new Orchestration parameters are shown up there: Ordered Delivery, Stop on Exception, and Recycle Interval (in seconds).


Ordered Delivery parameter works in the same way as the Ordered Delivery parameter of the Send Port. Now we don’t have to build the Convoy Orchestration manually. No more Loop inside Orchestration.

If the Ordered Delivery parameter set up to True, the Orchestration is working as a Singleton. The first Receive shape receives all correlated messages in sequence. Correlation set is created implicitly regards of the Activation Subscription expression.

There are several limitations for this kind of Orchestration. The most important is: only one Receive shape is permitted here.

There are two big advantages of this new feature:

  • Simplified Orchestration design for the Ordered Delivery.
  • No more Zombies. The Orchestration instance is recycled in controllable way, when no messages, matched the Orchestration Subscription, are placed in the MessageBox.


We discussed the Ordered Delivery implemented in the BizTalk Server and ways to improve it.


Print | posted on Wednesday, January 11, 2012 2:34 PM


# re: BizTalk: Ordered Delivery

left by rattan outdoor furniture at 1/11/2012 8:47 PM Gravatar
I have noticed the same behavior as in the list, one thing I might comment on though is that all of the servers I’ve seen this on are upgraded from 2006 R1 to R2, then the SP. Maybe that is the difference? I thought it odd that the SP didn’t have a different version.

# re: BizTalk: Ordered Delivery

left by Rohit Sharma at 1/11/2012 11:39 PM Gravatar
Keep up the good work Leonid. Good to know about automatic Ordered Delivery for Orchestrations in next version.

# re: BizTalk: Ordered Delivery

left by Edgar at 1/13/2012 8:01 AM Gravatar
How do you ensure that the orchestrations that do the sorting fire up after all the messages from all companies have successfully been processed?

# re: BizTalk: Ordered Delivery

left by Leonid Ganeline at 1/13/2012 9:01 AM Gravatar
Hi Edgar,
Thanks for your question.
Could you, please, elaborate it in more details. What do you mean as "do the sorting"?
Do you mean, how all four orchestrations from my sample are processing the same inbound messages?
That's the feature of the Pub/Sub model of the BizTalk. When inbound message is published to the MessageBox, all subscriptions are calculated for this message. If several subscribers are found, each gets a copy of this message. Those copies are pushed to the [virtual] queue, which created for each subscriber. If Orchestration works by default (in All In Parallel mode), one orchestration instance is created for each message in this personal queue. If Orchestration is implemented as a convoy, a single Orchestration instance is created which processes several messages from queue one by one, in order. Because it is a convoy, several correlated messages could get to a queue. Without convoy it is always one message per queue.

# re: BizTalk: Ordered Delivery

left by Naushad at 2/10/2012 1:13 PM Gravatar
Hi Leonid,
Really great article with useful information.
I have a question which is not related with this one , i am afraid,:)
Is there a way to control the ordering of the messages getting published to BizTalk message box,
there is a Mq Queue where all the messages are coming/stored in FIFO order, When i configure and start a BizTalk receive location, i have no control at recieve side to publish the messages in FIFO to message box?

Any ideas?


# re: BizTalk: Ordered Delivery

left by Leonid Ganeline at 2/10/2012 1:46 PM Gravatar
Hi Naushand,

This part of the BizTalk architecture is undocumented unfortunately. As I guess, the messages from Receive location are published to MessageBox in order. But then... then they are processed in Parallel Delivery mode. The details of this are hidden but, seems, it is the mode when the "faster" processing starts early. If BizTalk decides the message B12 can be processed faster then message B05, it processes B12 first. It can be the size of the message, which influences this decision, maybe something else.
As "process" I mean, for example, the orchestration instance activated by this message and then transforms/sends/... this message.
To force BizTalk to process messages from receive port in order we could use the Sequential Convoy Orchestration as a singleton service. Plus we have to do the Ordered Delivery parameter = True on the Receive Port shape. It is a mystic parameter. Nobody knows how it works.

Thanks for comment!

# re: BizTalk: Ordered Delivery

left by Zeeshan at 3/12/2012 5:33 PM Gravatar
Hi Leonid,
This is more of a comment than a question. BizTalk provides many features that can solve the problem at hand. I would tend to say that if your solution is looking into ordered messaging using BizTalk Corelation - the solution has already moved in the wrong direction!

Another problem besides the zombie factor, is the capability of retry/resubmit when one of the incoming messages fails within the orchestration. The whole batch within that condition gets suspendeded and further incoming messages would start on another instance. Bad performance coupled with a less resilient solution. I would recommend staying away from the FIFO approach.

# re: BizTalk: Ordered Delivery

left by Leonid Ganeline at 3/12/2012 7:44 PM Gravatar
2 Zeeshan:
I would rather copy from forum (
"The short answer: "We cannot prevent zombies completely in convoys". Sorry. Want to do 100% reliable messaging - forget convoys.

The long answers: " We could mitigate zomby situations" and "Sometimes we don't care about zombies".
IMO, Retry/resubmit feature has nothing to do with orchestration. "The whole batch ... gets suspended..." You don't have to store the whole batch and can process it in receive_1 - send_1 fashion. Actually I cannot see here the batch processing at all.
And FIFO is implemented because this is a requirement and we could not throw it away. We could stop using the BizTalk Correlation, but we must use some other correlation. I don't know, how to implement FIFO in asynchronous messaging without correlation.
Post A Comment