I have read on MSDN:
"BizTalk Server 2004 does not support convoy processing when passing in an already initialized correlation set into a new orchestration using the start orchestration. This is because convoy sets handle at the database level, independent of already running orchestration instances."

Is it true for BizTalk 2010 also?

In this case, if BizTalk doesn't support convoy processing then why would someone want to pass a correlation set? What could be some scenarios in this case?

Thanks.

This is true in BizTalk 2010 also.

Passing the correlation set will happen in the scenario where the receive shape of the orchestration having activation false means it will be initiated with message type + correlation set i.e. orchestration depends on specific types of related messages which is been triggered by other orchestration and all the related messages need to be handled only by this orchestration instance.

• Edited by ChampBoss Sunday, January 12, 2014 4:50 AM

Because you might have a scenario where you're receiving a Correlated message that's not a Convoy.

Convoys are specifically provided for by the Messaging and Subscription engines and some scenarios are prevented as trade-offs to enable reliability in others, likely the Sequential Convoy in this case.

My best reasoning is the because Start Orchestration is async, there is definitely the possibility that a Following message will received and routed before the Start'ed Orchestration thus delivering unpredictable results.

• Edited by boatseller 13 hours 53 minutes ago typos

Sorry not very clear what the requirement is? Can you please explain what you are trying to do? Or was the question only to discuss a feature of BizTalk 2010 vs 2004

• Edited by Prabhdeep Gill Sunday, January 12, 2014 8:18 AM

Because you might have a scenario where you're receiving a Correlated message that's not a Convoy.

Convoys are specifically provided for by the Messaging and Subscription engines and some scenarios are prevented as trade-offs to enable reliability in others, likely the Sequential Convoy in this case.

My best reasoning is the because Start Orchestration is async, there is definitely the possibility that a Following message will received and routed before the Start'ed Orchestration thus delivering unpredictable results.

• Edited by boatseller Sunday, January 12, 2014 9:34 PM typos