BizTalk Server: End-to-End Ordered Message Processing Options

Article
1/17/2024

In some industries, such as healthcare and financial services, ordered message processing is a common requirement. Messages are processed in the order they are received. BizTalk Server supports this sequential first-in first-out (FIFO) message processing pattern.

Implementations

1. Messaging-only implementation

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.

2. Singleton orchestration implementation

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:

The receive adapter performs ordered receiving.
Orchestration is a singleton with sequential convoy, and has the Ordered Receive option enabled.
The send port is enabled with Ordered Delivery

3. Multiple orchestration implementation

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.

Things to keep in mind

Ordered delivery artificially constrains BizTalk Server to process messages in a single-threaded manner per unique subscription versus its normal multi-threaded, scale-out multi-server default configuration. By constraining the processing of a certain subset of messages to one-by-one on a single server or a smaller subset of servers, the latency, overall throughput, load balancing and floodgate performance of BizTalk Server is reduced. Planning and testing are crucial to ensure that your system is adequate for your load.
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.
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.
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.
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.

Share via