http://geekswithblogs.net/ErwinAI/articles/58590.aspx
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“).Labels: correlations in biztalk, example for correlation in biztalk, Example for correlations in biztalk, what is correlation
