Without any business orchestration involved, it is very simple to implement end-to-end ordered delivery in BizTalk Server. Send Ports have the Ordered Delivery option but Receive Ports do not have it. Several transports into Receive Locations have an Ordered Delivery option. So if receive transport supports ordered delivery then we could implement ordered delivery for this Receive Port. Order-preserving receive adapters, like MSMQ, MQSeries, and WCF-NetMSMQ, are used with the Ordered Delivery option enabled on the send port. Other two-way transports, such as HTTP and SOAP, can also support ordered receiving. For example, the sender maintains control by only sending the next sequential message after receiving a valid response for the last message sent.
If your business logic requires an orchestration, confine the business logic within a singleton orchestration. End-to-end ordered delivery can be achieved with following three requirements:
If your business logic is quite complex and involves multiple orchestrations, usually a custom solution is required to implement end-to-end ordered message processing. The Improving Ordered Message Delivery in BizTalk Server 2006 R2 During Concurrent Processing white paper provides an example. This example uses a custom pipeline component in the receive pipeline to stamp a sequence number as a context property in each message. After the business orchestrations process the messages, a singleton orchestration (helper orchestration) picks up the messages and re-sequences them. The helper orchestration accumulates the messages in an internal queue and releases them one-by-one based on the sequence number stamp. Then, the send port with Ordered Delivery enabled picks up and delivers the messages sequentially.
2. When the Ordered Delivery option is enabled, there is an option to Stop sending subsequent messages on current message failure. This option determines, under a failure condition, whether one single message is suspended or the send port instance will be suspended.
3. Ordered delivery is not supported with dynamic send ports. When you create a dynamic send port, the Ordered Delivery option is unavailable. Also, a send port with Ordered Delivery option enabled cannot have a backup transport. See details at http://support.microsoft.com/kb/952559.
4. If you are creating a custom receive adapter to be used in ordered message processing, the adapter needs to follow some guidelines. After submitting a batch of messages, your custom receive adapter should wait for the BatchComplete callback from BizTalk Server before submitting the next batch. If a message fails in the pipeline, it should be suspended, preferably as non-resumable.
5. It is not required for the receive port, orchestrations, and send port of an ordered message processing implementation to use the same BizTalk host. It is common that they be separated into different hosts for performance and isolation.
Another important place to find a huge amount of BizTalk related articles is the TechNet Wiki itself. The best entry point isBizTalk Server Resources on the TechNet Wiki
Maheshkumar S Tiwari edited Revision 3. Comment: Added See Also section and tags
Fernando Lugão Veltem edited Original. Comment: added toc