BizTalk: Parallel Processing with Correlation

In some scenarios business data can be spread across numerous systems and it is BizTalks responsibility to correlate the common data and detect when the various parts of this data are submitted for processing. To achieve this BizTalk developers can use parallel processing in conjunction with correlation sets inside an orchestration to manage the business logic needed to process the disparate messages.

BizTalk: Parallel Processing with Correlation

In some scenarios business data can be spread across numerous systems and it is BizTalks responsibility to correlate the common data and detect when the various parts of this data are submitted for processing.

To achieve this BizTalk developers can use parallel processing in conjunction with correlation sets inside an orchestration to manage the business logic needed to process the disparate messages.

This article will demonstrate how to use the above techniques to detect when two messages sharing common data are submitted for processing. A parallel processing branch in conjunction with a correlation set ensure that the same orchestration instance is used to process the two halves of the common data.

Pre-requisites:
It is assumed that you have a good working knowledge of BizTalk 2006. As such instructions for some steps are shortened.

Create the BizTalk project

Open a new BizTalk project and call it ParallelConvoy. The first thing to do is to add the schema files. Make sure the project has the same references defined as those in the following screenshot.



Add the following schema files with the structure as defined in each screenshot.

PropertySchema1.xsd


This is the property schema used to define the correlation set.


PurchaseMsg1.xsd


This message contains one half of the data.

PurchaseMsg2.xsd



This message contains the other half of the data.

Note that both PurchaseMsg1.xsd and PurchaseMsg2.xsd contain an ID node. This node shares the same data. This is used to initialize the correlation set (which we will create later on) and so will ensure that the same instance of the orchestration is used to process the two halves of the data.

To be recognized by the correlation set, the ProductID and ID nodes need to be promoted in each schema. To do this right click on the <Schema> node of each schema and select Promote -> Show promotions.



In the dialog that appears highlight the property Fields tab. Click the Folder icon for the Property Fileds list and navigate to the PropertSchema1.xsd. Next, highlight the ID node of the schema and click the ‘Add’ button.

PurchaseMsg1.xsd - ProductID Node promotion


Click OK to close the dialog. Repeat for PurchaseMsg2.xsd.


PurchaseMsg2.xsd - ID Node promotion


You have now promoted the property in each schema that will be used by the correlation set to correlate the two messages for processing by the same instance of the orchestration.


ProductResult.xsd

This is the resultant message schema which is sent out from the send shape and port.


Add the Orchestration

Add a new orchestration to the project. It will end up looking like this:


As you can see there are two Receive ports that map to two separate directories and two Receive shapes set in a ParallelActions shape. Each receive shape initializes the correlation set. This ensures that the ConstructMessage shape is not invoked until the two messages have been received. As they both initialize the correlation set this means that the messages can arrive in any order. The transform shape takes the data from both messages, pushes it through a map to aggregate the data and create the message that gets sent out.

To create the above orchestration do the following:

Add Message types.

Add the following messages to the Orch:


Purchase1Msg should be of type PurchaseMsg1
Purchase2Msg should be of type PurchaseMsg2 and
PurchaseOutMsg should be of type ProductResult.

Create the Correlation Set

In the Orchestration View pane, right click the Correlation Sets node and select ‘New correlation set’. Ensure it has the following properties:


The new correlation set should now appear in the Correlation Types node. Right click the new correlation set and select ‘Configure correlation properties…’


In the dialog that appears, expand the ParallelConvoy entry.


Highlight the ID node and Click the ‘Add’ button. This tells BizTalk that the property to match in each received message must be the ID node. Click OK to close the dialog.


Create ports

Add the following artefacts with the indicated properties:

PurchasePort_1


PurchasePort_2

Drop a ParallelActions branch onto the orchestration design surface. By default it will have 2 branches. Drop a Receive shape onto each branch and configure them as below.

Receive_1


Receive_2


Next drop the Construct Message shape on the orch and adjust the properties as follows.


Add a transform shape to the ConstructMessage shape and double click it to open the configure dialogue. Select New Map and configure the source and destination variables of the transform as follows:

Source


Destination


Check the ‘When I click OK, open the BizTalk Mapper’ checkbox and then click ‘OK’. A new map will open called ‘Transform_1’. It will contain the source and destination schemas you just defined. All you need do now is connect the source and destination nodes as shown below.




That’s the orchestration finished as well as the map. Now build and deploy the solution, not forgetting to give it a strong name.

Next we have to create some test files that contain the data we need.

PurchaseMsg1.xml – based on PurchaseMsg1.xsd

<ns0:Root xmlns:ns0="http://ParallelConvoy.PurchaseMsg1">
<ProductID>ID_0001</ProductID>
<ProductName>Widget 1</ProductName>
</ns0:Root>

PurchaseMsg2.xml - based on PurchaseMsg2.xsd

<ns0:Root xmlns:ns0="http://ParallelConvoy.PurchaseMsg2">
<ProductDescription>A really cool widget for widgety things</ProductDescription>
<ID>ID_0001</ID>
</ns0:Root>

Testing

Now we are ready to test. Drop the PurchaseMsg1.xml file into the target directory. Once it has been consumed, open the BizTalk Admin console and query for all service instances. You will see something similar to the screenshot below.
Notice the Status of the Orch is Dehydrated. This is because the orch knows it has to wait for the second message before continuing processing. Now drop PurchaseMsg2.xml into its target directory. Once it has been consumed, if you refresh the query you will see that the orchestration no longer appears. Goto the Out directory specified on the Send port and in it you will see the output file. If you open it up the contents will look something like this:

<?xml version="1.0" encoding="utf-8"?>
<ns0:Root xmlns:ns0="http://ParallelConvoy.ProductResult">
<ProductID>ID_0001</ProductID>
<ProductID>ID_0001</ProductID>
<ProductName>Widget 1</ProductName>
<ProductDescription>A really cool widget for widgety things</ProductDescription>
</ns0:Root>

You’ll notice that the ProductID node appears twice. This is because the map does not define a looping structure for repeated data, which would make this node appear only once. I leave this as an exercise for the reader.

This article has demonstrated how to use parallel processing in conjunction with correlation sets to process two seperate messages that share common data. The Business logic is not invoked until all messages are received and a promoted property schema is used to identify how multiple messages should be linked. This ensures that the same instance of the orchestration is used to process the linked data.

Happy Programming


By BiZTech Know   Popularity  (6282 Views)