In the past, I have tended to focus on sequential convoys. Now, I decided to take a look at Concurrent Convoys. First off, I was sure in older versions of the documentation they were called Parallel Convoys? Maybe I’m mistaken or maybe the name changed over the past few months…. In any case, I will get with the times and call them Concurrent Convoys. No matter what you call them, the power and usefulness of this type of convoy is the same.
Why use Concurrent Convoys? Concurrent convoys allow you to receive multiple items in any order that all need to be processed by the same Orchestration before the next step in the process can happen.
Setting up and using a Concurrent Convoy is rather straight forward. All you have to do is drop a Parallel Shape inside your Orchestration. Then, drop in your multiple Receive Shapes. If this is the first shape in your Orchestration then each Received must be set with Activate = True and all must initialize the same Correlation Set. Otherwise, they must all follow the same Correlation Set that was initialized by a Send Shape. That is all your need to do!
I have included a sample with two different Orchestrations. One Orchestration shows a Concurrent Convoy with Active Receives and one without Active Receives.
The Orchestration with Activate Receives has two sets of sample files. The set with ID 100 will produce 8 total records in the output file. The set with ID 500 produces 6 records. Note that since all three messages arrive on different ports, Receive Port mapping is possible to get all inbound documents into a common format (not shown in my sample).
The Orchestration without Activate Receives uses the same set of sample files but it requires a Start Message to be received and a message to be sent out to initialize the correlation. This will produce the same output of 8 and 6 records. In this Orchestration, all the Receives uses the same Receive Port.
For information on how to run the samples, please see the Read Me file.
Make sure you keep an eye on the BTSSubscriptionViewer tool (located in the SDK). Note the differences between the two Orchestrations.
DOWLOAD: Sample Concurrent Receive Convoys
Bonus: I also show a simple say to merge all three messages together into a single output. This uses a map inside the Orchestration.
Hey Stephen thanks for the well explained and thorough intro to this subject but as is so frequent in the BizTalk world it only got me part of the way there, and was hoping you have come across the issue I am experiencing and may be able to help me out.
I have an BizTalk solution where two files can be received in any order from two separate file locations. I have implemented a parallel convoy and got both my ports set to activate receive port and this works.(standard stuff right?).
Sooooo, the thing is I do not want my orchestration to run forever waiting for a file that may not be received. Simple you may think, implement this in a scope and set a timeout! and of course you are right and this works.
The bad butt is that I do not want to loose the message that has arrived and I can not seem to get access to it through the exception or compensation blocks.
I am aware that this may be due to the fact that there is no guarantee that the message exists, but surely there must be a way to get at this, surely!
Anyway sorry to hassle you, I know this article is old news, but help would be appreciated
Thanks
Dino Fassis
It%u2019s been a long time since I%u2019ve done a Parallel Convoy. Have you looked at / tried using a Listen Shape? Not sure if that would work though.
Other than that, I%u2019ve not tried what you are trying%u2026 but if you can get the Orchestration suspended you should be able to find the message inside tracking someplace. Associated with the Orchestration.
Hope this helps.
Stephen W. Thomas
See blog article here: http://geekswithblogs.net/kapilc/archive/2009/04/30/concurrent-convoys-with-time-outs.aspx. On our project, this is how we handled the requirements to have a timeout for a parallel convoy and be able to access received messages in an exception handler.
Thanks for the help