1. Problem
You are implementing a data
aggregation integration point, which requires data to be retrieved from
multiple systems. Each source system publishes messages, and a message
from each system must be received before further processing can take
place.
2. Solution
A parallel convoy
is a business process (orchestration) that receives multiple messages
in parallel (at the same time) that relate to each other. Parallel
convoys handle the race condition that occurs as BizTalk attempts to process subscriptions for messages received at the same time.
A common scenario
requiring parallel convoys is where multiple messages for a specific
event must be received before a business process can start. As an
example, suppose your company's policy allows an order to be shipped
only once payment has been approved and stock level has been verified.
Payment approval comes from a financial system, and stock-level
information comes from an inventory system. Once both systems publish
their respective messages for a specific order, that order can be
delivered to the customer.
Parallel convoys are
implemented by message correlation and Parallel Action shapes in BizTalk
Server, as shown in the following steps.
Open
the project that contains the schemas. (We assume that XSD schemas used
to define payment approval and stock-level verification messages are
already created.)
Add a new orchestration to the project, and give it a descriptive name. In our example, the orchestration is named ParallelConvoyOrchestration.
Create two new messages, and specify the name and type of each. In our example, we create messages named PaymentApprovalMessage and StockLevelConfirmationMessage, which are defined by the PaymentApprovalSchema and StockLevelConfirmationSchema schemas, respectively.
In the Orchestration View window, expand the Types node of the tree view so that the Correlation Types folder is visible.
Right-click the Correlation Types folder, and select New Correlation Type, which creates a correlation type and launches the Correlation Properties dialog box.
In
the Correlation Properties dialog box, select the properties that the
correlation will be based on. In our scenario, we select the OrderID property, which has been promoted from the PaymentApprovalSchema and StockLevelConfirmationSchema schemas.
Click
the new correlation type, and give it a descriptive name in the
Properties window. In our example, the correlation type is named OrderIDCorrelationType.
In the Orchestration View window, right-click the Correlation Set folder, select New Correlation Set, and specify a name and correlation type. In our example, we create a correlation set named OrderIDCorrelationSet and select OrderIDCorrelationType.
From the toolbox, drag the following onto the design surface in top-down order; the parallel convoy configuration is shown in Figure 1:
Parallel Actions shape to receive the response from the financial and inventory systems.
Receive
shape to receive messages from the financial system. Place this shape
on the left-hand branch of the Parallel Actions shape. Configure this
shape to use the PaymentApprovalMessage, to initialize the OrderIDCorrelationSet, to activate the orchestration, and to use an orchestration receive port.
Receive
shape to receive messages from the inventory system. Place this shape
on the right-hand branch of the Parallel Actions shape. Configure this
shape to use the StockLevelConfirmationMessage, to initialize the OrderIDCorrelationSet, to activate the orchestration, and to use an orchestration receive port.
Expression
shape to deliver the ship the order. Configure this shape to send the
order to the appropriate recipient. In our solution, we simply write a
message to the trace log via the following code:
System.Diagnostics.Trace.Write("Shipping Order with ID = " +
PaymentApprovalMessage
(ParallelConvoyOrchestration.PropertySchema.OrderID));
3. How It Works
In this solution, we show how a
convoy can be used to concurrently handle messages within an
orchestration. The parallel convoy, also referred to as a concurrent convoy, consists of the OrderIDCorrelationSet
and the Parallel Actions shape. Each Receive shape in the Parallel
Actions shape initializes the correlation set, which is based on the
order ID. Initializing a correlation set instructs BizTalk Server to
associate the correlation type data with the orchestration instance.
This allows BizTalk to route all messages that have identical
correlation type criteria (in our case, all messages with a specific
order ID) to the same instance.
Each of the Receive shapes has its Activate property set to True and its Initializing Correlation
configured to the same correlation set. The Receive shape that receives
the first message will handle the activation of the orchestration
instance and the initializing of the correlation set. The second Receive
shape will not activate a new orchestration instance (even though its Activate property is set to True) and will actually follow the correlation set that the other Receive shape initialized.
Based on this example, messages for two order IDs would be handled in the following manner:
A payment approval message for order ID 1 is received, which instantiates orchestration instance 1.
A stock-level confirmation message for order ID 2 is received, which instantiates orchestration instance 2.
A
payment approval message for order ID 2 is received, which is
correlated and delivered to orchestration 2. The orchestration continues
processing, ships order ID 2, and terminates successfully.
A
stock-level confirmation message for order ID 1 is received, which is
correlated and delivered to orchestration 1. The orchestration continues
processing, ships order ID 1, and terminates successfully.
