BizTalk 2010 Recipes : Orchestrations - Configuring Basic Correlations

4/12/2011 11:46:02 AM

1. Problem

You need to send a message out of an orchestration and receive a response back into the same orchestration instance.

2. Solution

You can use a correlation set to tell an orchestration to accept only messages that have the same information as a message sent by the orchestration. As an example, suppose you have a customer support website where customers can place support requests and expect a response to appear on the website within two days. When a customer places a request, the website sends a support request message containing a unique SupportID to BizTalk, which BizTalk forwards to a customer relationship management (CRM) system. Once support personnel monitoring the CRM system respond to the customer request, the response containing the same SupportID goes through BizTalk and posts to the customer support website for the customer to view.

Occasionally, the support personnel cannot respond within two days, either because the request is not clear or because it is an extraordinarily tough request. When support personnel cannot solve the customer's request in time, the business policy is to elevate the request to a special support team that will work one-on-one with the customer to help with the problem. Unfortunately, the CRM system does not have the functionality to escalate the support request after the standard time period. However, fortunately for your customers, BizTalk can implement the business process and coordinate these two messages easily using correlation sets.

The same orchestration instance that forwards the request to the CRM system must receive the correlating response. In this example, BizTalk will know to receive the response with the same SupportID as the message forwarded to the other system.

Create an orchestration that defines the basic flow of messages. Figure 1 illustrates a basic message flow where the orchestration receives a message, forwards the message on to another system, and waits for a response. If the orchestration does not receive a response within a specified amount of time, the orchestration sends the original message to another location for higher priority processing.

Figure 1. Defining the message flow
A correlation type defines the information that BizTalk uses to decide which orchestration instance gets the response. To create the correlation type, in the Orchestration View window, right-click Correlation Types, and select New Correlation Type, as shown in Figure 2 . The Correlation Properties dialog box appears.

Figure 2. Creating the correlation type
In the Correlation Properties dialog box, select the promoted property that defines the correlation information, and click the Add button. In this example, select the ServiceID promoted property of the ServiceRequest schema, as shown in Figure 3 . Select OK to complete the creation of the new correlation type, and rename it to ServiceIDType.

Figure 3. Defining the members of the correlation type

NOTE

While a correlation set type can contain any promoted property, it cannot contain distinguished fields.
To create the correlation set, right-click Correlation Sets in the Orchestration View window, and select New Correlation Set, as shown in Figure 4.

Figure 4. Creating the correlation set
In the Properties window, change the name of the new correlation set to ServiceIDCorrelation, and set the correlation type to the ServiceIDType created in steps 2 and 3, as shown in Figure 5.

Figure 5. Setting the correlation set properties
Right-click the Send to CRM shape in the orchestration, and select Properties. In the Properties window, set the Initializing Correlation Sets property to ServiceIDCorrelation, as shown in Figure 6.

Figure 6. Initializing the correlation set
Right-click the Get CRM Response shape, and select Properties. In the Properties window, set the Following Correlation Sets property to ServiceIDCorrelation, as shown in Figure 7 . This ensures that the orchestration will accept only messages with the same information at runtime, which is the specific support identifier in this example. While sending the outbound message, BizTalk creates an instance subscription with the properties of the correlation set to receive the correlated inbound message.

Figure 7. Following the initialized correlation set

3. How It Works

The orchestration in Figure 1 defines the basic flow of messages that BizTalk needs to coordinate. However, the time between when BizTalk sends the support message to the CRM system and receives a response could be as long as two days. You would expect that there could be any number of outstanding customer support requests during two days. Moreover, because many support requests are sent to the CRM system, many BizTalk orchestrations would be waiting concurrently for a response. Further, suppose one request has already taken over a day of research, when a new one arrives that will take only a few minutes to handle. BizTalk creates a new orchestration instance to forward each message to the CRM system, but how will BizTalk know which orchestration instance should receive the response message?

By using a correlation set, you can tell an orchestration to accept only messages that have the same information as a message sent by the orchestration. A correlation set is a container for holding information of a particular correlation type. A correlation type defines the correlation set, telling BizTalk the fields in a message that will create the correlation set. In this example, we have only one SupportID to keep track of, so we create only one correlation set. When BizTalk initially sends the support request to the CRM system, the orchestration instance initializes the correlation set containing the SupportID to keep track of the specific SupportID in the messages. The action receiving the response from the CRM system follows the same correlation set, meaning that the orchestration instance will accept only messages with the same SupportID as the message sent to the CRM system.