Correlations form a fundamental concept of BizTalk 2004. They specify how individual messages are related, and are used to tell BizTalk how to process them.
An advise from the heart: take your time to understand the basics of correlations in BizTalk. You will encounter many aspects of correlations when your developments are becoming more complex. With some basic knowledge, you will be able to design a solution that can indeed be realized in BizTalk. When you fail to see the intricacies of correlations, all of your attempts might result in serious error, forcing you into a new attempt for a solution.
First, a short explanation on how the “messaging engine“ of BizTalk works. When you deploy a project, the orchestrations will become available in the runtime environment. When the deployed orchestration is started, it subscribes to messages of a designated type (message type) delivered at a designated location (port). That means that, apart from taking the subscription, nothing really happens until a message arrives. The messaging engine receives the message, and determines the type. Based on this, it fires up an instance of the orchestration that subscribed to it.
So, the subscription information is essential for locating an orchestration that matches the message type when a message comes in. This information is contained in the receive shape and the connected port in an orchestration. The receive shape provides the message type the orchestration expects, the port tells (after binding) where and how messages of this type are expected.
Now, what happens when I require more than one receive shape in my orchestration? Can I receive messages of different types in a single orchestration? What about multiple instances of the same message type? How do we specify a sequence of actions?
For all questions, there is a proper solution in BizTalk. Not all answers will be discussed here. When you plan to use more than one receive shapes in an orchestration, you will have to specify the behavior of your orchestration for incoming messages on each receive shape. In other words: when a message comes in and it can be related to a specific orchestration, the messaging engine should be able to tell whether it should fire up a new instance of the orchestration for this message or it should pass this message as input to an already running orchestration instance (and: which one of the running orchestration instances). This is done using correlations and related settings of the receive shapes.
[example]
Invoice data is sent from system A to system B. The invoice data is sent as soon as it is created in system A. Another user of system A has to check the invoice and approve it. After approval, system A sends approval data to system B. In between systems A and B sits BizTalk. The idea is that BizTalk collects both pieces of information on a single invoice before sending it to system B. We can assume that the invoice data is always sent before the approval. All invoices (invoice data and invoice approval data) are uniquely identified by an invoice number.
The orchestration to do this contains two receive shapes. The first one receives the invoice message. The second one receives the invoice approval message. Only after both have been received, a message is sent out to system B. The receive shape for the invoice message has the “Activate“ property set to true. This means that any invoice message received will cause a new instance of the orchestration to be started. The receive shape for the invoice approval message has the “Activate“ property set to false. This means that the invoice approval message will only be accepted by already running instances of the orchestration. This looks great, but still something is missing. What if invoices 1234 and 1235 are created (and sent to BizTalk), and only approved of later? Two instances of the orchestration are running (one for 1234 and one for 1235) when the approval for 1235 comes in. BizTalk knows (from the “Activate“ property of the receive shape) that the approval should go into an already running orchestration instance. Which one? That is determined by a correlation set, relating the two receive shapes.
The receive shape for the invoice message is set to “initialize“ a correlation set for the invoice number. The receive shape for the invoice approval message is set to “follow“ a correlation set for the invoice number. How does this work? When a new invoice message comes in, a new orchestration is started, the invoice message is read, and the invoice number is taken out and associated with the orchestration instance. The orchestration instance is parked, waiting for the approval message (this is called “ dehydration“). When an invoice approval message comes in, it is also read. With the invoice number form the apprval message, the correct orchestration instance is looked up. This orchestration will proceed (after “rehydration“).
[end of example]
An overview of settings and components required to set up an orchestration using multiple receive shapes:
- Promoted properties. In the schemas that define the message types you will be receiving, you can promote properties. This is done to make data (tag values) out of a message instance available in the message context, i.e. accessible to the environment for control. To set up a correlation, you need to promote properties from all schemas involved into a single property schema. The names of the promoted properties don't need to be equal, but ensure that there is exactly one entry in the property schema for each promoted property, no matter how different message types call this property.
- Create a correlation type using the promoted property. See the “types“ section of the “orchestration view“ of the orchestration.
- Create a correlation set using the correlation type.
- For a simple correlation (like the example): determine which receive shape will be activating the orchestration. This will also be the receive shape initializing the correlation set (usually). The other receive shape(s) will be non-activating and will be “following“ the same correlation set.
- After you have completed setting up the orchestration, check what BizTalk thinks about this by building the containing project. When you get error messages that point in he direction of multiple receive shapes, correlation sets and property schemas, you have probably created something that conflicts with the basic rule for using multiple receive shapes: BizTalk should always exactly know what to do when an instance of a message type is received. When it can not determine this (at compile time), it will not compile the project.
Please note: the example and the explanation of terms below describe a very simple correlation scenario, in which two messages are received in a fixed sequence. There are numerous other possibilities to combine multiple messages in a single orchestration. Please refer to documentation and other resources on the topic of “convoys“, as this is the way to solve the more complex problems.