BizTalk Sequential Convoy

This blog is to explain about BizTalk Sequential Convoy.

What is Sequential Convoy?

Sequential Convoy is one type of BizTalk design pattern to achieve particular type of requirements. This can be defined as “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.”

Sequential Convoy also called as singleton pattern convoy.

Sample Scenario for Sequential Convoy:

My Orchestration has to receive the messages from source location and create a batch for first three messages and send to destination system.

In order to achieve this requirement, we need to make our orchestration as singleton, that means my orchestration has to receive all 3 messages using single instance (By default, Orchestration creates dedicated instance for each message)

Once my orchestration receives 3 messages, instance will be completed and new instance will be created for next 3 messages. Likewise, my orchestration has to run for ever.

Note: In order to correlate all 3 messages, we need to have common element in all messages (Example: CustomerId/OrderId..)

In real time, usually this type of scenario comes for internet banking transactions or retail orders process.

Sample Input message:

This message has to be dropped 3 times in receive location with different data.

<ns0:Billing xmlns:ns0=”http://BTSamples1.BillingAddress”&gt;

<CustId>123</CustId>

<Address1>ABC Apt</Address1>

<Address2>XXX</Address2>

<ZipCode>XXXX</ZipCode>

</ns0:Billing>

Sample Output message:

This message is a batch of 3 input messages.

<BillingDetails>

<ns0:Billing xmlns:ns0=”http://BTSamples1.BillingAddress”&gt;

<CustId>123</CustId>

<Address1>ABC Apt</Address1>

<Address2>XXX</Address2>

<ZipCode>XXXX</ZipCode>

</ns0:Billing>

<ns0:Billing xmlns:ns0=”http://BTSamples1.BillingAddress”&gt;

<CustId>123</CustId>

<Address1>BAC Apt</Address1>

<Address2>XXX</Address2>

<ZipCode>XXXX</ZipCode>

</ns0:Billing>

<ns0:Billing xmlns:ns0=”http://BTSamples1.BillingAddress”&gt;

<CustId>123</CustId>

<Address1>CDE Apt</Address1>

<Address2>XXX</Address2>

</ns0:Billing>

</BillingDetails>

Note: In all messages we need to have a common element “CustId”.

Implementation:

1. Need to create a schema for incoming message and promote the common element as property promotion. Also create correlation type and correlation set on CustId.

1.png

2. Design the orchestration like below.

2.png

“Receive_1” shape receives very first message and initialize the correlation set.

“Receive_2 shape follow the correlation and receives remaining messages using the same instance created while receiving first message.

“Loop_2” shape make sure the orchestrations run for ever.

“Loop_1” shape make sure to receive maximum 3 messages for each instance and batch it.

Once max messages (3) are received, “Loop_1” will break and batched message will be sent to Destination system using “Send_1” shape.

3. Create below orchestration variables.

//Count is a variable of type “System.Int32

//Continue is a variable of type “System.Boolean”

//XmlDocVar is a variable of type “System.Xml.XmlDocument”

//StrFinal is a variable of type “System.String”

//BillingStrVar is a variable of type “System.String”

4. Create below Orchestration Messages

//XmlDocMsg is a message of type “System.Xml.XmlDocument

//BillingAddress is a message of type BillingAddress Schema

5. Keep below code in all orchestration shapes.

  • Receive_1

3.png

  • Expression_1

4.png

  • Loop_2

5.png

  • Loop_1

6.png

  • Receive_2: 

 7.png 

  • Expression_2

8.png

  • Expression_3

9.png

  • ConstructMessage_1

10.png

  • Send_1

11.png

  • Expression_3

12.png

6. Build and deploy the application

7. Configure the ports and start the application

8. Unit Testing: Drop couple of sample message copies in input folder with same customer id then for every 3 messages one batch file will be batched and dropped in a destination system. For example, if you drop 6 input messages, you will see 2 output messages in destination folder.

 

 

Advertisements

BizTalk Parallel Convoy

This blog is to explain about BizTalk Parallel Convoy.

What is Parallel Convoy?

Parallel Convoy is one type of BizTalk design pattern to achieve particular type of requirements. This can be defined as “A parallel convoy enables multiple single messages to join together to achieve a required result. The set of related messages can arrive in any order, but BizTalk Server must receive all of them before starting the process”

Sample Scenario for Parallel Convoy:

My Orchestration has to produce a customer address which is having Billing and Shipping details.

My Orchestration has to receive the Billing address details from Source A and Shipping Address details from Source B. Once both messages are received, then only my orchestration has to proceed further to produce full customer address. If any one of the addresses are not received, my orchestration has to wait till other message received.

This scenario can be achieved through parallel convoy design pattern in BizTalk.

  1. We need to create 3 schemas, Correlation type and correlation set.
  • Schema1 is for Billing Address

1.png

  • Schemas 2 is for Shipping Address

2.png

  • Schema 3 is for Full Customer Address

3.png

 

2. Insert “ParallelActions” shape into the BizTalk orchestration editor.

3. Drag and drop two receive shapes inside the parallel convoy shape like below

4.png

4. Create a message for Billing Address and assign to the shape “Receive_1”

5. Create a message for Shipping Address and assign to the shape “Receive_2”

6. Set “Initializing Correlation Sets” property for both receive shapes with the correlation set created in above steps.

Please note that both receive shapes are having “Initializing Correlation Sets”.

If Receive_1 shape receives the message first, then other receive shape will act as follow correlation on CustId.

If Receive_2 shape receives the message first, then other receive shape will act as follow correlation on CustId.

Once both messages are received then only It will proceed further to apply a map to produce full customer address.

7. Create a map to produce full customer address

Input messages: Billing and Shipping Addresses

5.png

Output Messages: Customer Address

6.png

 

Click on “OK”

7.png

8. Send the final message (Full Customer Address) to the destination system based on your requirement.

Here is the sample Orchestration view for Parallel Convoy demo.

8.png

We will talk about sequential convoy in upcoming blogs.