BizTalk Server 2009 : What the Maestro Needs to Know: Advanced Orchestration Concepts - Correlation

1. What Is Correlation?

Correlation is the process of matching an incoming message with the appropriate instance of an orchestration. You can create any number of instances of a given orchestration, and while each of them will perform the same actions, they will do so on different data. To have the same orchestration instance perform a set of actions on different incoming messages to complete a complex transaction, you will need to leverage correlation sets and correlate those incoming messages. If, for example, an orchestration developed to automate a purchase from a partner is designed to issue a purchase order, receive an invoice, and send payment, you need to be sure that the invoice is received by the same orchestration instance that the corresponding purchase order was sent from. Imagine ordering a single item and getting back an invoice for 1,000 items, or vice versa, and you will understand the value of correlation.

This sort of correlation of messages with orchestration instances may be achieved by defining correlation sets. A correlation set is a set of properties with specific values. If an incoming message does not have all of these properties, with matching values for each, correlation will fail, and the message will not be received by the orchestration instance. Correlation sets are initialized in a receive action or a send action.

Each correlation set is based on a correlation type, which is simply a list of properties. These properties might be data properties, which are found in the message itself, or context properties, which describe details of the system or messages that are unrelated to the data being conveyed in the message.

A correlation type may be used in more than one correlation set. If you need to correlate on different values for the properties in a correlation type, you must create a new correlation set—each correlation set can be initialized only once.^[]

^[] Correlation sets may be passed as in parameters to other orchestrations.

The properties of a message sent from an orchestration may be validated by the engine to ensure that it reflects the properties in its correlation set. By default, this validation is disabled.^[]

2. Convoys: Serial vs. Parallel

Convoys are groups of related messages that are intended by a partner business process to be handled in a specific order within an orchestration. For example, an orchestration might need to receive five different messages before any processing can begin.

When a group of correlated messages could potentially be received at the same time, a race condition could occur in that a correlation set in a particular orchestration instance must be initialized by one of the messages before the other messages can be correlated to that orchestration instance. To ensure that all of the correlated messages will be received by the same orchestration instance, BizTalk detects the potential for such a race condition and treats these messages as a convoy.

There are two main types of convoys: concurrent correlated receives and sequential correlated receives. A convoy set is a group of correlation sets that are used in a convoy.

Note the following general restrictions on convoys:

• A convoy set can contain no more than three properties.

• Concurrent and sequential convoys can coexist in an orchestration, but they cannot use any shared correlation sets.

• Correlation sets passed into started orchestrations do not receive convoy processing in the started orchestration.

• You cannot initialize two or more correlation sets with one receive to be used in separate convoys. For example, if receive r1 initializes correlation sets c1 and c2, receive r2 follows c1, and receive r3 follows c2, then the orchestration engine will not treat these as convoys. It is a valid convoy scenario if both r2 and r3 follow both c1 and c2, both follow c1 only, or both follow c2 only.

Concurrent correlated receives are correlated receive statements in two or more branches of a Parallel Actions shape. If a correlation is initialized in more than one parallel task, each correlated receive must initialize exactly the same set of correlations. The first such task that receives a correlated message will do the actual initialization, and validation will be done on the others.

Sequential correlated receives are receives that are correlated to previous receives. Convoy processing takes place for cases in which the correlation sets for a receive are initialized by another receive.

For receives that require convoy processing, the following restrictions apply:

• The correlation sets that constitute a sequential convoy set for a particular receive must be initialized by one preceding receive.

• The port for a receive that requires sequential convoy processing must be the same as the port for the receive initializing the convoy set. Cross-port convoys are not supported.

• Message types for a particular receive that require convoy processing must match the message type for the receive initializing the convoy set, unless the receive statement is operating on an ordered delivery port.

• All receives participating in a sequential convoy must follow all the correlation sets that are initialized (or followed) by the initializing receive, unless operating on an ordered delivery port.

• If a sequential convoy is initialized by an Activating Receive statement, then the Activating Receive cannot have a filter expression unless operating on an ordered delivery port.

• If a sequential convoy is initialized by an Activating Receive, the following receives cannot be inside a nested orchestration. Otherwise the preceding rules apply for nested orchestrations.