Chapter 10: Advanced BizTalk Orchestration Features

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.

Orchestration Correlation Through Message Queues

Mike has discovered some performance problems in the trade schedule.The problem lies with the trading component. Currently, the trade schedule makes a synchronous call to the trading component, which sometimes can take a long time to process the order, and many smaller orders have to wait on the queue even though they could be processed very quickly. Mike wants to change the current schedule to remove the direct synchronous calls to the trading component.

Mike decides to make the schedule send the trade order to a remote message queue instead of calling the trading component. The trading components will be moved to the server that hosts the remote message queue and will process the documents as soon as they arrive from the trade schedule. Multiple instances of the trading component will be activated to process the trade orders as quickly as possible. After an order is executed, the response document (which contains the execution status information) is sent to another message queue that is watched by the running trade schedule instances. As soon as a response document arrives, the correct schedule instance will pick up the response document and will process the Post-Trade Database Update transaction and forward the response documents back to the original clients.

To ensure that the running schedules will pick up the correct response documents from the message queue, the orchestration correlation technique will be used in this new trade schedule. The new trade schedule replaces the Execute Trade action with two new Action shapes that are connecting to message queuing shapes (see Figure 10-21).

Figure 10-21. Revised trade schedule

The SendTradeOrderToQueue action will send the trade order to the message queue called NewTradeOrder, where it will be picked up to be processed by the  trading component. After the trading component completes the trade order, it will generate a response document that contains the transaction status information, and  will send the response document to a separate message queue called ProcessedTradeOrder. The ReceiveTradeOrderFromQueue action will then receive the correct response document from the queue and go on to the subsequent actions.

Now, let's add two Message Queuing implementation shapes to supportorchestration correlation. Drag and drop the first Message Queuing shape onto the Business Process page. In the Message Queuing Binding Wizard, specify the port name as SendOrderToQueue and the static message queue path as .\private$\NewTradeOrder.

Next, connect the SendTradeOrderToQueue action with the appropriate port, and an XML Communication Wizard will open. You need to create a new message to represent the document that will be sent to the queue.

The next window will ask for the message label information (see Figure 10-22). Check the "Use Instance Id as Message Label" checkbox. The Message type field will then contain an uneditable value, __Instance_Id__. The instance ID is a GUID that uniquely identifies a schedule instance. This ID is critical in identifying which document is associated with a specific schedule instance. Click Next until you finish the wizard.



Figure 10-22. Using the instance ID as the message label

Now you can drag and drop the second Message Queuing shape onto the Business Process page, and specify ReceiveOrderFromQueue as the port name and .\private$\ProcessedTradeOrder as the message queue path. Connect the ReceiveTradeOrderFromQueue Action shape with this Message Queuing shape.

In the XML Communication Wizard that opens, specify that this port is to receive messages. If you expect that the trade order will take a long time to process, you may want to set the wait time to a number greater than 180 seconds,which will  allow the XLANG engine to dehydrate the schedule instance while it waits for messages to arrive. For this example, set it to 200 seconds.

In the next window, create a new message called TradeOrderFromQueue to represent the response document that arrives at the message queue. Click Next to proceed to the window shown in Figure 10-23. Check the Use Instance ID as Message Label checkbox. This setting is important because a schedule instance will only accept amessage from a queue whose message label is equal to its instance ID. You also must provide aMessage type name, but this  value is irrelevant if you are using the instance ID as the message label, so just type  in anything and click Next until you finish the wizard.



Figure 10-23. Specifying the message type information for the port

The central idea of using the instance ID as the message label for orchestration correlation is that all the running schedules will check the message label of the messages as they arrive at the queue. If the message label of amessage in the queue has the same value as the instance ID of one of the running schedules,that particular running schedule will pick up the message and process it. Other running schedules won't pick up that document since none of them has thematching instance ID.

To make the whole correlation process work, the trade component must make sure the message label (which contains the instance ID) of the message it picked up from the queue has the same message label when the message is sent out after processing. Throughout the whole process, the message label must remain the same, or the  correlation won't work. BizTalk Server wouldn't be able to match the messages with the correct running schedules otherwise.

NOTE You can read and assign message labels for messages in the queue programmatically though the use of the MSMQ object model. In this example, the trade component will need to call these MSMQ methods to read and assign the message labels to ensure they stay the same.For more information about the MSMQ object model, refer to Appendix A.

You also need to modify the data page to make sure all the messages are inked correctly.

After you compile the schedule, you are ready to test it. However, you must set up some Receive Functions, channels and ports for this schedule before you can test it. Figure 10-24  shows the CorrelationTrade schedule in the XLANG Event Monitor. Notice the snowflake icon  beside CorrelationTrade-it indicates that the schedule instance has been dehydrated. Open the detailed events for the schedule instance (shown in the Events for CorrelationTrade window in Figure 10-24) to reveal that schedule is indeed dehydrated and is waiting on the ReceiveTradeOrderFromQueue action.



Figure 10-24. Dehydrated schedule instance is waiting for a message to arrive.

The next step is to send a message to the .\private$\ProcessedTradeOrder queue so that the schedule instance can continue. To test it, handcraft multiple  response documents and give one of them the same label name as the GUID shown in the XLANG Event Monitor, in this case {72964115-172A-4C59-981C- 4F9857821F87}. Shortly after you send these messages to the ProcessedTradeOrder queue, that dehydrated  CorrelationTrade instance will be rehydrated and will start processing the message. When it's completed, youshould find that there are still some messages in the queue, and only the  matching message is removed.

With orchestration correlation, you can convert the many synchronous tasks into asynchronous ones by implementing this "send-receive" pair in the schedule.This  asynchronous approach removes the binding between the schedule and the business components, and when combined with the XLANG Schedule's ability to be dehydrated, will greatly improve the resource management and scalability of the XLANG Schedules under a heavy load.