Correlating to a Running Orchestration
In the previous section, you learned how BizTalk Server instantiates a new instance of a business process by delivering a message to the orchestration schedule. Our example showed that after the message was received it displayed the message in a message box. Although this established that the schedule was started, in a real-world scenario, this is the beginning of a business process and not the end. In general, most B2B or EAI business processes involve a minimum of two messages being exchanged:
An outgoing message with a request
An incoming message with a response
Returning to our AcctMngSys EAI application in Figure 16.1, we will look at the third and fourth block of the business process. The business process requires an update of the back-end ERP system. The schedule sends an update request to the ERP system and waits for a response. When the ERP system response finally arrives, the waiting schedule continues processing the remainder of the business process. The thing to note here is that the response from the ERP system may take hours, days, or weeks, especially if the ERP system is outsourced and lives in another organization.
This means that at any given time, hundreds of instances of a business process could be running on a single BizTalk Server. A new message arrives, a new instance of the schedule is created, and the schedule sends out a request to the ERP system and waits for a response before continuing to completion. This could turn into a resource management nightmare. Fortunately, BizTalk utilizes an XLANG persistence database and automatically dehydrates an orchestration schedule into this database, whenever the following sync action occurs:
The schedule needs to wait for a response.
The beginning of a transaction boundary occurs in the schedule.
By dehydrating the schedule in the database, the system ensures that it will survive a server shutdown. It also guarantees that the current state of the schedule is preserved even if long passages of time occur prior to the receipt of a response message. BizTalk Server automatically handles the hydration and rehydration of a schedule; however, one problem remains. We need to be able to match a response message to the instance of the schedule that originally sent the request. To achieve this, each instance of the orchestration schedule is persisted with its own GUID and is thus uniquely identifiable. This process of returning a message to a specific instance of a schedule is called correlation.
We will demonstrate three different ways of correlating a response message back to its appropriate running schedule instance. In Example 2 and 3, we will demonstrate HTTP-based correlation, and in Example 4 we will show non-HTTP-based correlation. The cases are
Example 2, HHTP-based, with BizTalk Servers on both ends
Example 3, HTTP-based, with BizTalk Server on one end and any external business process on the other end
Example 4, Non-HTTP-based, with BizTalk Server on both ends
We will extend our AcctMngSys EAI example to illustrate each type of correlation. The two business processes involved are the AcctMngSys and the ERP system. The ERP system business process consists of a BizTalk Orchestration schedule and a COM component that inserts new hire information into a SQL Server database. Based on the success or failure, the COM component formats a response message. The message is then correlated to the running AcctMngSys schedule that originally requested the update. Figure 16.18 shows the scenario.
Figure 16.18. Overview of the AcctMngSys and ERPSystem integration scenario.
The following describes the steps used to accomplish this:
1. |
A new hire message, UserAcctInfo, is dropped into a private MSMQ queue. |
2. | |
3. |
The AcctMngSys orchestration schedule displays a message to indicate that the schedule has been activated. The next step in the orchestration sends out the message to BizTalk Messaging to deliver it to the ERP system business process. The message, UserAcctInfo, is then transferred using BizTalk Messaging to the ERP system business process. At this point, the AcctMngSys orchestration schedule instance waits for a response message. |
4. |
BizTalk Messaging transfers the message, UserAcctInfo, to the ERP system business process. |
5. |
The ERP system business process receives the message. The next step in the ERP system displays a message to indicate that the ERP system schedule has been activated. The third action calls a COM component to update the ERP system. Based on this update operation, the component formats a response. The response message is then sent out via BizTalk Messaging. The ERP system business process ends at this point. |
6. |
BizTalk Messaging transfers the response message between organization or application boundaries. |
7. |
The AcctMngSys business process receives the response message and correlates the message back to the same instance of the schedule that sent out the UserAcctInfo message to the ERP system process. Finally, the AcctMngSys business process displays the response message indicating that the response, for which the schedule was waiting, has arrived, and the schedule runs to completion. |
You have already done the first two steps of this example in the earlier scenario, dropping a file onto a message queue, picking up the message from the queue, and delivering the message to a new instance of a schedule. In this section, we will focus on the process of sending a message out and then correlating a response message back to an instance of the schedule that originally sent the message. We will start with the HHTP-based correlation example, where we have BizTalk servers on both endpoints.