Hi All,
One of the powerful feature in BizTalk is correlating a message to the correct instance of an orchestration. This is done through two ways : Sequential and Parallel convoy correlation.
Sequential convoy means correlating the incoming messages from different or same source to an instance of orchestration serially i.e. in a sequential manner but one major difference from parallel is that the process will finish execution after an interval regardless of arrival/non arrival of other messages in a convoy.
Below sample sequential convoy process is an example of how sequential convoy works.
In the above example I have taken two schemas - customer order and customer bill, I will explain the scenario for both sequential and parallel convoys using the order-bill relationship. The above scenario is for sequential convoy where a customer places an order and then pays for the order he/she has placed. Here the relation between order and bill is an unique number which is an element present in both the schemas and both the messages will be correlated based on value present in that field.
Here, first the order is placed and is subscribed by the orchestration which picks the order xml and initializes the correlation , it is then the orchestration which waits for 10 seconds for bill to be received. The bill xml if dropped within time interval of 10 seconds is picked by the orch and then rest of the process happens and if it is not dropped within 10 seconds after the order is dropped then the instance is execution ends. Sequential convoy gives birth to 'zombies' which means lost message, in the above scenario if bill is dropped after an interval of 10 seconds when order is dropped then it will be suspended with no subscriber found error message because the instance to which the bill message was assigned has ended. Although there is no proper way to avoid this problem but it can be reduced to some extent by increasing the timespan in delay shape. So from the above example we see that sequential convoy follows "OR" logic and can be implemented in scenarios where dependency on other message is a primary constraint.Here both bills and orders consume same instance of orchestration in which the correlation set is initialized by order receive shape and bill receive shape follows the correlation set initialized by order shape.So in this scenario order receive shape will be ACTIVE.
Below process design is an example of parallel correlation which is following the same order-bill relationship scenario.
In the above example the scenario is same but it follows "AND" logic where both the receive shape are ACTIVE and both of them have same 'INITIALIZING' correlation set which means that the process will begin execution unless both order and bill messages have been received with same unique number.One important thing is to note that though the sequential convoy is using the correlation on unique number but we cannot use the same correlation set for parallel convoy, we will have to create a new correlation set.
Hope you guys enjoyed reading the article.
Regards,
Saurav
Software Engineer @ Agility
One of the powerful feature in BizTalk is correlating a message to the correct instance of an orchestration. This is done through two ways : Sequential and Parallel convoy correlation.
Sequential convoy means correlating the incoming messages from different or same source to an instance of orchestration serially i.e. in a sequential manner but one major difference from parallel is that the process will finish execution after an interval regardless of arrival/non arrival of other messages in a convoy.
Below sample sequential convoy process is an example of how sequential convoy works.
In the above example I have taken two schemas - customer order and customer bill, I will explain the scenario for both sequential and parallel convoys using the order-bill relationship. The above scenario is for sequential convoy where a customer places an order and then pays for the order he/she has placed. Here the relation between order and bill is an unique number which is an element present in both the schemas and both the messages will be correlated based on value present in that field.
Here, first the order is placed and is subscribed by the orchestration which picks the order xml and initializes the correlation , it is then the orchestration which waits for 10 seconds for bill to be received. The bill xml if dropped within time interval of 10 seconds is picked by the orch and then rest of the process happens and if it is not dropped within 10 seconds after the order is dropped then the instance is execution ends. Sequential convoy gives birth to 'zombies' which means lost message, in the above scenario if bill is dropped after an interval of 10 seconds when order is dropped then it will be suspended with no subscriber found error message because the instance to which the bill message was assigned has ended. Although there is no proper way to avoid this problem but it can be reduced to some extent by increasing the timespan in delay shape. So from the above example we see that sequential convoy follows "OR" logic and can be implemented in scenarios where dependency on other message is a primary constraint.Here both bills and orders consume same instance of orchestration in which the correlation set is initialized by order receive shape and bill receive shape follows the correlation set initialized by order shape.So in this scenario order receive shape will be ACTIVE.
 |
| Correlation set initialized by ORDER receive shape. |
 |
| Correlation set initialized by BILL receive shape. |
Below process design is an example of parallel correlation which is following the same order-bill relationship scenario.
In the above example the scenario is same but it follows "AND" logic where both the receive shape are ACTIVE and both of them have same 'INITIALIZING' correlation set which means that the process will begin execution unless both order and bill messages have been received with same unique number.One important thing is to note that though the sequential convoy is using the correlation on unique number but we cannot use the same correlation set for parallel convoy, we will have to create a new correlation set.
Hope you guys enjoyed reading the article.
Regards,
Saurav
Software Engineer @ Agility
