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.

Using Orchestration Transactions (Short, Long, and
Timed)

In Chapter 5, you created an orchestration that processes the FundInvestors document.You used a Decision shape to determine whether your COM+ component completed successfully, but because the orchestration didn't have any transactional support, the actions that were performed couldn't be rolled back in the event of failure. Bob wants Mike to build a trading workflow that can process the buy and sell orders for the mutual fund companies, but he wants the trading XLANG Schedule to support transactions so that when an error occurs, any changes that have been made will automatically be rolled back to maintain the integrity of the data in the system. Let's take a quick look at transactions before tackling this assignment.

A transaction is a group of operations that are processed as a single unit. In the computer world, transactions follow these four rules, collectively known as the ACID rules:

• Atomicity: A transaction represents an atomic unit of work. Either all modifications within a transaction are performed, or none of the modifications are performed. In other words, if one job in the transaction fails, the work performed by the previous jobs in that transaction should be reversed as if nothing happened.
  
  
• Consistency: When a transaction is finished, whether committed or aborted, all the data must be in the proper state, with all the internal rules and relationships between data being correct.
  
  
• Isolation: Modifications made by one transaction must be isolated from the modifications made by other concurrent transactions. Isolated transactions that run concurrently will perform modifications that preserve internal database consistency exactly as they would if the transactions were run serially. In other words, all the data related to an ongoing transaction should be locked to prevent other transactions from interfering with this transaction.
  
  
• Durability: After a transaction has been committed, all modifications are permanently in place in the system. The modifications persist even if a system failure occurs. In other words, after the data in the transaction has been committed, any system failure shouldn't change the committed data in any way.

Types of Transactions

In BizTalk Orchestration, you can make your Action-shape implementations participate in a transaction in one of two ways: Run your XLANG Schedule as a traditional transactional COM+ component or as an XLANG Schedule transaction that is specific to BizTalk Orchestration.

When making an XLANG Schedule run as a COM+ component, external COM+ components can start such a XLANG Schedule as if it were a COM+ component.The transactional behavior of this type of XLANG Schedule is the same as a COM+ component.

To configure an XLANG Schedule to run as a COM+ component, open the properties page of the Start shape at the top of the workflow, and for the Transaction model field, select "Treat the XLANG Schedule as a COM+ Component"(see Figure 10-1).



Figure 10-1. Configuring the transaction model for the orchestration

There are four transaction activation options available for this type of XLANG Schedule (which are the same as for COM+ components):

• Not supported: The schedule won't participate in the transaction. When the creator of the schedule aborts the transaction, the change made by the schedule won't be rolled back.
  
  
• Supported: The schedule will participate in the transaction of its creator, but it won't create one if its creator doesn't participate in a transaction. If its creator participates in a transaction, an abort in its creator will roll back all the actions performed inside the schedule.
  
  
• Required: The schedule will participate in its creator's transaction. If its creator doesn't participate in a transaction, the schedule will create a new transaction and make all the actions within the schedule participate in this transaction. An abort in its creator will roll back all the actions performed inside the schedule.
  
  
• Required new: The schedule will create a new transaction regardless of whether its creator already has a transaction. All the actions inside the schedule will participate in this new transaction created by the schedule. An abort in its creator won't roll back all the actions performed inside the schedule.

The other transaction model for the schedule is "Include transaction within the XLANG Schedule". When selecting this transaction model, the actions within the schedule can participate in a transaction by locating them inside a Transaction shape. The four transaction activation types are also available for this transaction model.

When it comes time to choose which transaction model to use for your schedule, there are a number of factors to consider. In terms of performance, running the schedule as a COM+ component is much faster than using the other model. However, when running as an XLANG-style transaction, your schedule will be able to support Distributed Transaction Coordinator (DTC) style transactions, long-term transactions, timed transactions, and nested transactions. I'll discuss these transaction types later in this chapter. The COM+ transaction model only supports DTC-style transactions.

In fact, the Transaction shapes aren't even allowed in an orchestration unless the orchestration's transaction model setting is "Include Transaction within the XLANG Schedule" on the Begin shape. If the orchestration isn't configured this way and contains transactions, it will cause a compile error when you try to compile it into an .skx file.

NOTE When you choose to treat the schedule as a COM + component, you can't use the Transaction shape on the schedule, or an error will occur when compiling the schedule.The Transaction shape is exclusively used when choosing the other transaction model ("Include transaction in the XLANG Schedule").

NOTE DTC provides services to manage transactions that span different transactional sources. COM+ replies on DTC for its transactional support. For example, by using DTC, a COM+ component can write to a database and MSMQ, two separate transactional resources, in a single transaction.

With XLANG-style transactions, your schedule can also define actions to be taken in event of a transaction failure. This feature isn't available in COM+-style transactions. A schedule with XLANG-style transactions is shown in Figure 10-2.



Figure 10-2. A schedule with XLANG-style transaction

To create a transaction inside another transaction, you need to first drag and drop a Transaction shape from the flowchart panel onto the Business Process page (which creates a new transaction), and then drag another transaction into the boundary of the first Transaction shape. You must make sure that all four sides of the second (inner) Transaction shape fit inside the four sides of the first (outer) Transaction shape, or the inner transaction won't be considered nested inside the outer one. To verify whether the transaction is nested properly, you can drag the outer Transaction shape around a bit-if the inner Transaction shape moves with the outer one, the inner transaction is properly nested. You can resize the Transaction shapes so that one can fit inside another.

NOTE If you delete the outer Transaction shape, the inner transaction, along with the shapes inside it, is deleted as well. If you want to keep the inner Transaction shape, make sure you move the inner transaction outside of the boundary of the outer one, unnesting the inner one, before deleting the outer transaction.

Short-Lived Transactions

Let's come back to Bob's trading XLANG Schedule. He wants the schedule to perform the actions shown in Figure 10-3.



Figure 10-3. Actions involved in Bob's trading schedule

Five actions are involved in this trade schedule:

• Receive Doc: This action receives the document from the client.
  
  
  
• Pre-Trade Database Update: This action will update the database to indicate that the buy and sell transactions inside the client document are being processed. The information in this database will be exposed to the Internet so that each client can check the status of his or her trade orders.
  
  
  
• Execute Trade: This action will start Bob's existing trading component, which will execute the trade order and return a document that contains information on the transaction, such as fulfillment of the trade, final price per share, etc.
  
  
  
• Post-Trade Database Update: This action will take the document returned from the trading component and update the status information on the client's trade order in the database.
  
  
  
• Sending Trade Status Back: This action will send the document returned from the trading component back to the client.

Bob already has a document specification for this schedule, named Trade, defined in XML editor (see Figure 10-4).



Figure 10-4. Trade document specification

A sample trade from a client would look like this:

<Trade>
  <FundCompany>Henry Fonda Inc.</FundCompany>
  <TradeItems>
    <TradeItem>
      <Ticker>IBM</Ticker>
      <TransactionType>Buy</TransactionType>
      <Share>10000</Share>
      <Price/>
      <OrderType>Market Order</OrderType>
      <ExecutionStatus/>
    </TradeItem>
    <TradeItem>
      <Ticker>MSFT</Ticker>
      <TransactionType>Buy</TransactionType>
      <Share>15000</Share>
      <Price>65.50</Price>
      <OrderType>Limit Order</OrderType>
      <ExecutionStatus/>
    </TradeItem>
  </TradeItems>
  <TotalTransactionAmount/>
</Trade>

The <ExecutionStatus> field will contain the execution information for each individual stock transaction in the document. Its content will be filled by Bob's trading component, and it will contain information on whether a specific transaction completed or not. For example, if the limit price isn't reached, the transaction won't take place; in such a case, the trading component will insert "Limited price is not met" in the field to indicate that this particular order wasnot processed. The trading component will also fill the <TotalTransactionAmount> and <ExecutionStatus> fields under each TradeItem record. The TotalTransactionAmount is the total dollar amount for each individual trade that is completed in the document.

In this trade schedule, you want to use XLANG-style transactions. You'll use short-term transactions in this schedule. Later in this chapter, I'll show you how to work with long-term and timed transactions, but for now, let's find out what advantages can be gained by making actions transactional.