BizTalk Demo: Sequential Convoys & Singleton Orchestration
A sequential convoy enables multiple single messages to join together to achieve a required result. A sequential convoy is a set of related messages that have a predefined order. Although the messages do not have to be exactly the same, BizTalk Server must receive them in a sequential order.
Few usages of them could be an aggregator orchestration or to introduce throttling. We will be covering those in later blogs.
In our example below all the messages arriving at one ReceivePort will trigger our orchestration and all of them will be consumed within a SINGLE INSTANCE of the orchestration. In other words, each incoming message is not triggering a new orchestration instance. We have tried to keep the orchestration simple but hopefully by the time you will finish reading this you will know what how the sequential convoys operate.
Using correlated Receive ports are key to sequential convoys. Here are the steps.
1>Create a new BizTalk solution and define your incoming and outgoing message schemas
2>Add a new orchestration to your solution and design it similar to the Picture below.
https://psrathoud.files.wordpress.com/2013/11/scorchestration1.png?w=300&h=144
3>Define correlation set and types and in the correlation properties we will use the “BTS.ReceivePortName” property since we want to have the convoy configured on all the messages arriving on a particular receive port.
https://psrathoud.files.wordpress.com/2013/11/correlation1.png?w=300&h=132
Note: We can use a lot of other properties to define the “correlation ” for the sake of simplicity we have picked ReceivePortName. Let me know if you want to use some other properties and discuss it here.
4>On the first receive shape we will initialize this correlation set.
https://psrathoud.files.wordpress.com/2013/11/intializecorr1.png?w=300&h=158
5>The second receive shape will follow this correlation set.
https://psrathoud.files.wordpress.com/2013/11/followcorr1.png?w=300&h=136
6>Create a physical receive port and send port. Bind orchestration and start all the ports, orchestration
When the first message arrives in the message box the orchestration picks that up and starts while initializing the correlation, when the 2nd message arrives instead of being subscribed for a new orchestration instance it rather goes to the 2nd receive shape which is following the correlation initialized by the first receive shape hence this message gets consumed by the existing orchestration instance. This loop goes on unless we write a logic for when to break it.
Try dropping XML files to your receive location, the admin console will show you all the artifacts triggered notice there is only on orchestration instance triggered. During the time when there are no messages coming into the receive location or orchestration will be in dehydrated state and will rehydrate in event of a new message arriving into the port. Also, this orchestration is not designed to complete, you may want to add a branch with delay shape to exit the infinite loop in the code, anyways that's a simple thing to do and we may handle this in a multiple way. Hope the example comes handy.
https://psrathoud.files.wordpress.com/2013/11/seqadminconsole.png?w=300&h=108
