Chapter 10: Advanced BizTalk Orchestration Features

Posted by Apress Free Book | BizTalk Server December 22, 2008
In this chapter, I'll show you the many advanced features of BizTalk Orchestration: orchestration transactions, XLANG Schedule throttling, orchestration correlation, Web services in BizTalk Orchestration, orchestration dehydration, and so on. You'll continue to update Bob's ASP as you explore these features, because Bob always wants to add to his application.

Dehydrating and Rehydrating XLANG Schedules

So 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 processes

In 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 schedule instance must not contain any running DTC-style transactions. The XLANG engine won't dehydrate a schedule instance if it's running a short-lived transaction that hasn't yet aborted or committed.

  • The implementation for the port must support persistence if it holds the state. For example, if the COM component connecting to the port holds the state but doesn't support the IPersist interface, then the XLANG engine can't dehydrate the schedule instance, because it will be unable to persist the state held by the component to the XLANG database.
  • The latency setting for the port must be greater than 180. The latency setting assigned in the XML Communication Wizard should be greater than 180 seconds (see Figure 10-19). BizTalk Server will never dehydrate a schedule instance if the latency value for the blocked port is less than or equal to 180 seconds.

    Figure 10-19. Configuring the latency value for the port in the XML
    Communication Wizard

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 Correlation

In 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 queues

If 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.

Total Pages : 12 56789