It is one more description of the Ordered Delivery (OD) in BizTalk.
The main article about it is in MSDN. There is also a blog article Improved performance for ordered send ports in BizTalk
Here I am discussing the BizTalk Ordered Delivery “implementation details”.
To force Send Ports work in order we flag the “Ordered Delivery” in Send Ports, then the BizTalk MessageBox takes care of implementing OD.
To force Receive Locations work in order we flag the “Ordered Delivery” option in the Receive Location Transports, whenever is possible. Not all Transports have such option. With this flag set up, the BizTalk Transport Adapter takes care of implementing OD.
Note: 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.
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.
Imagine four Orchestrations which implement four approaches to the sequencing.
The first is the AllInParallel Orchestration. It processes all messages without any order. One AllInParallel Orchestration instance will be created for each inbound message.
The AllInOrder Orchestration processes all messages in one sequence. Only one AllInOrder Orchestration instance will be created.
The OrderByCompanyAndDate Orchestration processes messages in sequences correlated by the Company value (A, B, C, D, etc.) and by date. The separate queue is created for each new value of the Company for each new day. Messages inside queues are processed in order. Queues for different Companies+day are independent. A separate OrderByCompanyAndDate Orchestration instance will be created for each new Company value for each new day.
The OrderByProductAndDate Orchestration works exactly as the OrderByCompanyAndDate Orchestration but correlated by the Product value (xx, yy, etc.) instead of Company. The number of companies is bigger than the number of products, so the number of orchestration instances for the OrderByCompanyAndDate orchestrations potentially bigger than number of instances of OrderByProductAndDate and OrderByCompanyAndDate would be more performant. In way by choosing the right parameters to create an order, we could control the OD performance in orchestrations.
By default, all Orchestration and Messaging Service instances work 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 instances.
Send Port OD could be in two states, on and off:
Orchestration OD could be in two states also, on and off. It is not just change in the orchestration run-time parameters (as it is in Ports), but a deep redesign of the Orchestration workflow.
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 of 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.
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.
It is possible the BizTalk Server version Next will implement the automatic Ordered Delivery for Orchestrations, with a 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.
It would be great if those parameters are accessible at the run-time. 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:
We discussed the Ordered Delivery implemented in the BizTalk Server and ways to improve it.
Another important place to find a huge amount of BizTalk related articles is the TechNet Wiki itself. The best entry point is BizTalk Server Resources on the TechNet Wiki.