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.

Implementing the Transactions

To implement the transactions described in the previous section, you must set the transaction model of this schedule to "Include Transaction with XLANG Schedule" on the Start shape's properties page (refer back to Figure 10-1). Next, double-click the Trade Proc transaction to open its Transaction Properties page (see Figure 10-6).



Figure 10-6. Transaction Properties page for the Trade Proc transaction

In the Type section of the Transaction Properties page, select Short-lived, DTC-style. Under the Transaction options section are three properties:

• Timeout (seconds): This specifies how long the transaction may run before it's aborted or retried. This option is available for timed and short-lived, DTC-style transactions.
  
  
• Retry count: This specifies how many times the transaction can be retried if it can't be completed before the timeout.
  
  
• Backoff time (seconds): This specifies how long the schedule will wait before continuing with the next retry. The actual wait time depends on the backoff time and the retry number: The formula is wait time = B^R (B to the Rth power, where B equals the backoff time in seconds and R equals the number of retries). This option is available only for short-lived, DTCstyle transactions.

The time it takes the trading component to complete depends on many factors, such as the size of the transaction and the activity on the stock market. You'll set the timeout time to 10 minutes (600 seconds) for this transaction. Set the retry count to zero, since you don't want to execute the transaction again if it times out. The backoff time is irrelevant when you set the retry count to zero. The Isolation level setting allows you to configure how this transaction will lock the resources it uses when it's running. There are four isolation levels:

• Uncommitted read: A transaction set with this isolation level will be able to read data regardless of whether the data is committed. For example, if a first transaction is updating a record but hasn't yet committed the change, a second transaction (with a setting of Uncommitted read) won't care about whether the first transaction will commit the change or abort. It simply reads what it sees in that record at that moment. This type of transaction is very fast, since it always gets the data it wants right away, but the data it reads may not be consistent, since it could read data that is rolled back later.
  
  
• Committed read: A transaction set with this isolation level will only read data that has been committed by other transactions. If data has been changed by another transaction but not yet committed, this transaction will wait until the data it wants to read has been committed. This type of transaction won't lock the data it reads, so other transactions could change the data before this transaction ends. This may cause inconsistencies if the transaction updates the data and assumes that the data is the same, because another transaction may have changed it. This type of transaction is slower than the uncommitted read, since it has to wait for all the uncommitted data to clear.
  
  
• Repeatable read: A transaction set with this isolation level locks all the data reads so that it can't be changed by other transactions until the repeatable read transaction is finished. This solves the problem with committed reads, but it's slower than a committed read because it has to lock all the data it reads, not just the data it updates. Repeatable reads are also slow in the sense that other transactions won't able to update the data locked by the repeatable read transaction until the repeatable read transaction finishes.
  
  
• Serializable: A transaction set with this isolation level will lock the table to prevent inserts, updates, and deletes. This means that everything this transaction sees and doesn't see at the beginning of the transaction will remain exactly the same at the end of the transaction, except for changes made by the transaction itself. One problem with repeatable reads is that they don't prevent another transaction from inserting new data, which may cause some inconsistency in calculations that rely on information such as the total number of records-the Serializable isolation level solves this problem. Because this isolation level forces each transaction to be carried out and committed one at a time, it's the most restrictive of the four isolation levels, and it's the only isolation level that meets the ACID criteria.

For this example, choose the Serializable isolation level, which is the default setting, for the Trade Proc transaction. In the On failure section, check the Enabled checkbox, and then click the Add Code button to add a Business Process page that will be triggered when the transaction fails.

When you click the Add Code button, Orchestration Designer will add a new tab at the bottom of the window called On Failure of Trade Proc, to indicate that a new Business Process page exists for the transaction Trade Proc (see Figure 10-7).



Figure 10-7. A new On Failure page for the Trade Proc transaction

This On Failure page is similar to the regular Business Process page-here you can define Action shapes and implementation shapes. The process on the On Failure page starts right after the transaction it's associated with aborts. You have some idea of what you want to do in the case of the transaction aborting, so let's define those actions on the On Failure of Trade Proc page (see Figure 10-8).



Figure 10-8. The On Failure of Trade Proc schedule

On the On Failure page, all the implementations on the Business Process page will still be available and can be linked with the Action shapes defined on this page. It's perfectly all right to create new transactions by dropping Transaction shapes on the On Failure page, and creating another On Failure page for this On Failure page. As far as the orchestration is concerned, the On Failure page is just another Business Process page.

In this case, you first want to send an e-mail to the administrator, so you need to implement a BizTalk Messaging shape on the page and link it with the Send Email to Administrator implementation. Next, you want to send the original document to a message queue so that the administrator can examine it later. (All the messages created on the Business Process page are still available in the BizTalk Messaging Binding Wizard.)

You've now completed the On Failure of Trade Proc page. The actions on this page will be processed when the transaction aborts. But what makes a transaction abort?

Many conditions can make a transaction abort, such as the following:

• The Abort shape is encountered within the process flow.
  
  
• A COM+ component or Scripting component returns a failure HRESULT (these components need to be configured to abort a transaction if a failure HRESULT is returned during the port binding).
  
  
• An abort transaction is called inside a COM+ or scripting component.
  
  
• A failure is introduced by a binding technology at a system level (for example, Message Queuing might fail to put a message on a queue).
  
  
• The XLANG Scheduler Engine (the COM+ application that executes instances of schedules) encounters an error (such as a DTC error) that causes it to abort a transaction within a given instance.
  
  
• A schedule is paused (this might require all transactions within that schedule to abort).
  
  
• A transaction time-out within the transaction properties.

To configure a component to abort the transaction when it causes a failure HRESULT, open the component's Binding Wizard (see Figure 10-9). Under the Error handling section, select the sole checkbox option so that the transaction this component is in will automatically abort when a bad HRESULT is returned from this component. Under the Transaction support section, you must select Supported to make this component participate in the existing transaction.



Figure 10-9. COM Component Binding Wizard

You also need to configure these properties for the TradeInformation and Trade components inside the Trade Proc transaction.

Next, you need to create an On Failure page for the Post-Trade Proc transaction (see Figure 10-10).



Figure 10-10. On Failure page for the Post-Trade Proc transaction

To test whether the On Failure page really works, let's raise an error in the trading component. Because the trading component is configured to abort the transaction when it encounters a bad HRESULT, you can watch what action will be taken in such a case in the XLANG Event Monitor (see Figure 10-11).



Figure 10-11. Actions taken for the trade schedule with an aborted transaction

Because you've raised an error in the trading component (for example, with the Err.Raise method in VB), and the trading component is configured to abort the transaction when encountering a bad HRESULT, the first transaction, Trade Proc, is aborted at the ContextAbort event. The process flow then continues with the On Failure of Trade Proc page where an e-mail is sent to the administrator and the document is sent to the message queue.

After the schedule finishes the process on the On Failure page, it enters the Decision shape, where it identifies that an error has occurred in the previous transaction, and it terminates the current schedule.