The Trade Schedule The Business Process page for Bob's trade schedule using transactions is shown in Figure 10-5. There are still five Action shapes in this schedule, but four of them are inside two short-term transactions. The Pre-Trade Database Update and Execute Trade actions are in the Trade Proc transaction. The Post-Trade Database Update and Sending Trade Status Back actions are in the Post-Trade Proc transaction.Short-term transactions are also known as DTC-style transactions. These follow the same rules as DTC transactions in COM+. For instance, if the Execute Trade process aborts the transaction, any changes made by the Pre-Trade Database Update action will be automatically rolled back. After the transaction is committed, the changes made by both actions will be committed. Figure 10-5. Business Process page of an orchestration with short-term transactionsBefore you set up the properties for the Transaction shapes and specify what they should do in the event of failure, you must first define what you want the schedule to do. When a trade document enters the Trade Proc transaction and arrives at the Pre-Trade Database Update action, the TradeInformation COM+ component will be kicked off, and will update Bob's database with the order information in the document. The component will set the status in the database to In Process for each trade listed in the document. This means that if the client goes to the Web site, he or she will see the updated status for his or her outstanding buy and sell orders. If the TradeInformation COM+ component fails for whatever reason, the first thing you want to do is send an e-mail to the administrator to inform that person of this failure. The next action is Execute Trade. This is the step that actually processes the document using Bob's trading component. The trading component is a COM+ component that will examine each individual trade in the document to verify whether the transaction is compliant with SEC rules and whether there are suffi-cient funds to make the transactions happen. If all the information in the document is correct, the component processes the orders, fills the status fields for the individual transactions along with the TotalTransactionAmount field, and returns the trade document. If a problem exists with the information in the document, the trading component will abort the transaction and end the current schedule, since there is no reason to continue. In this case, the database update will be rolled back, and you need to make another call to the TradeInformation component to mark the client's submission with the message "Contains errors, unable to process", and you must send an e-mail to the administrator and store the client document in the error queue for later examination. After all this work is completed, the schedule will end. Unfortunately, there is no automatic way to terminate a whole schedule when a transaction aborts. When this happens, the schedule simply starts the process on its On Failure page and returns to the main business process after the actions on the On Failure page are performed. In some situations you'll want to terminate the schedule altogether if an important transaction fails, such as if the trading component fails-in that case, you want to perform the actions on the On Failure page and then terminate the schedule. To achieve this goal, you can use a Decision shape to check whether or not the transaction has aborted by evaluating the value of ProcessTrade_out.[__Exists__]. ProcessTrade_out is the message that contains the output of the trading component. If the transaction succeeds, ProcessTrade_out.[__Exists__] will return true. If the transaction aborts, ProcessTrade_out.[__Exists__] will return false. Based on this test in the Decision shape, you can either continue the process flow or end it. If the process flow enters the Post-Trade Proc transaction, the Trade Proc transaction has been successful and committed. It's now time to update the database with the new trade status information of each individual trade-the In Process status will be changed to whatever is in the status field of the document. If a client goes to Bob's Web site, they will find the status information for each individual trade he or she has sent. If this Post-Trade Database Update fails for whatever reason, you want to first send an e-mail to the administrator and then terminate the schedule. However, all the transactions have been committed at this point, so the administrator will need to inform the client that his or her transactions have been committed. If the Post-Trade Database Update transaction is processed successfully, you want to send the document that is returned by the trading component to the client so that he or she will have a digital copy of this document. You can do this by sending the response document to a message queue to be picked up and forwarded later by BizTalk Messaging. If the schedule is unable to write the document to the message queue, it will roll back the database update that the Post-Trade Database Update transaction made, and it will send out an e-mail to the administrator to inform him or her of the situation.