Dehydrating and Rehydrating XLANG SchedulesSo far, you've seen many features of XLANG Schedules. You've looked at the Action shapes and implementation shapes and what they can do for schedules, but there is another less obvious, yet very important feature of XLANG Schedules. In this section, you'll learn about the dehydration and rehydration of XLANG Schedules.When an XLANG Schedule is dehydrated, all the schedule's instance-related state information is persisted to the database, and that schedule's instance is erased from memory, freeing system resources. The rehydration of an XLANG Schedule reverses the dehydration process; it restores the dehydrated instance back to memory so that it can continue its processes. Figure 10-18 outlines the dehydration and rehydration processes.Figure 10-18. The dehydration and rehydration processesIn many B2B scenarios, a process in a workflow can be blocked for long periods of time before the workflow can continue. If a worker sent an order to the manager for approval and didn't expect to have the order approved for a couple of days, it would certainly be unacceptable for the worker not to do any other work while waiting for the approval. The same issue exists in XLANG Schedules-when a schedule instance is stopped and is waiting for a message to arrive before it can continue its process, BizTalk Server will consider dehydrating this particular instance so that the freed system resources can be used by other applications.When a schedule is waiting on a port, for instance, one of the actions in the schedule will receive the document from aMessage Queuing shape. If there is no message in the queue, the schedule will be blocked at that port until a message arrives at the message queue. In addition to the blockage, the following conditions must also be met before BizTalk Server will actually dehydrate this schedule instance to the database:The schedule instance must be in a quiescent state. All the actions in the schedule must remain inactive when a port is being blocked. If some components connected to the ports haven't yet completed, BizTalk Server won't dehydrate that schedule instance.
The rehydration process is much simpler. When a message arrives at the port that has been blocked, the XLANG engine will instantiate the schedule and return the state information and persisted components of that dehydrated schedule instance back to system memory, where the schedule can continue from where it left off.Using Orchestration CorrelationIn Chapter 5, you saw that BizTalk Orchestration can send data to BizTalk Messaging and to message queues by using BizTalk Messaging implementation shapes and setting the data flow on the port to Send. Similarly, BizTalk Orchestration can receive data from BizTalk Messaging and message queues by setting the data flow on the port to Receive. However, there is a problem that I haven't directed your attention to.Consider the scenario in Figure 10-20. The schedule is simple. It receives a document from BizTalk Messaging and sends the document to a NewOrder message queue, where the document is picked up by another application for processing. The schedule then waits for a confirmation message. When the order isfulfilled, a confirmation message is sent to the Confirmation message queue, and the schedule will retrieve it from the queue and process the rest of the actions.Figure 10-20. A schedule that sends and receives documents using message queuesIf you have one schedule instance running on the system, you won't have any problem retrieving the document from the Confirmation queue, because the confirmation document in the queue must have originated from the order document the schedule was processing. However, when multiple instances of this schedule are running on the system, and each instance is processing an order document from a different client, you'll have a problem. How do you determine which schedule instance will pick up the document that just arrived at the Confirmation queue? How do you know which schedule instance was processing the order document that this confirmation matches ?To this point, you've been thinking about XLANG Schedules in a singleinstance scenario, but in the real B2B world, it's common to have multiple instances of the same schedule running on a system at once. You must find a way to ensure that the messages a schedule instance receives are indeed intended for that particular instance. This means that whenever a schedule instance receives a document, either from BizTalk Messaging or a message queue, it won't simply assume that the arriving document is associated with the document it has been processing. Instead, BizTalk Server has a technique called orchestration correlation to handle this problem.