Module 10: Creating Transactional Business Processes by e51r8Xi

VIEWS: 0 PAGES: 33

									Module 10: Creating Transactional Business
Processes
Time estimated: 90 minutes




Module objective:
In this module, you will learn:

How to create atomic and long-running business transactions.

Overview
A Microsoft® BizTalk® Server orchestration provides a transactional programming model that
includes support for both atomic and long-running transactions, in addition to support for
nested orchestrations, exception handling, and methods for recovering from failed transactions.
Lesson 1: Introduction to Transactions




Lesson objective:

Explain how transactions work and how persistence points affect the performance of a BizTalk
orchestration.

Overview
BizTalk orchestration provides a transactional programming model that includes support for
exception handling and recovery from failed transactions. You can create atomic transactions
that automatically roll back their actions if an error occurs or long-running transactions that can
contain other transactions and custom exception handling. This means that if your business
process fails for any reason, you can choose what happens, whether it’s sending an error
notification to a person or system or updating a SQL database.
What Are Transactions?




Describe the types of transactions that BizTalk Server 2010 supports.

Overview
The BizTalk Server orchestration engine manages the state of running processes, applies
business logic, and supports the invocation of complex processes and transaction sets, as well as
the persistence of running and saved business processes. Business processes can be composed
as discrete pieces of work that can consist of:
        Atomic transactions that automatically roll back all changes in case of errors, much like
         database transactions.
        Long-running transactions that can span days, weeks, and longer time durations; they
         contain nested transactions and use custom exception handling to recover from error
         scenarios.

Scopes
These transactional mechanisms are managed through Scope shapes in the Orchestration
Designer. A scope contains one or more blocks. It has a body and can optionally have appended
to it any number of exception-handling blocks. It may have an optional compensation block as
well, depending on the nature of the scope. Each Scope shape that is added adds an additional
Context, which has its own Messages, Variables, Segments, and Class Types.
What Is Instance Persistence?




Describe what a persistence point is and how a persistence point affects performance of a BizTalk
orchestration.

Persistence
The orchestration engine saves the entire state of an orchestration instance at various points
during processing to the BizTalk MessageBox Database. This enables BizTalk to recover an
orchestration from a catastrophic failure or to conserve memory for a business process that may
be waiting hours, weeks, or days for input before processing can continue.
If the orchestration engine needs to rehydrate the orchestration instance, start up from a
controlled shutdown, or recover from an unexpected shutdown, it will run the orchestration
instance from the last persistence point as though nothing else had occurred. For example, if a
message is received, but there is an unexpected shutdown before state can be saved, the engine
will not record that it has received the message, and it will receive it again upon restarting.
Persistence Points in an Orchestration




Identify persistence points within an orchestration.

Persistence Points
The state of an orchestration includes any Microsoft .NET–based components that may be used
in the orchestration, in addition to all messages and variables. The engine stores state at the
following persistence points:
       End of a transactional scope (atomic or long running).
       Debugging breakpoints.
       The execution of other orchestrations through the Start Orchestration shape.
       A Send shape; except when contained by an atomic transaction, or immediately
        followed by the end of the orchestration.
       When an orchestration instance is suspended.
       When the system is shut down in a controlled manner.
       When the engine determines that it will dehydrate the orchestration instance.
       When an orchestration instance completes.
Steps for Setting Up a Transaction




Identify the steps involved in setting up a transaction.

Steps
The steps for setting up a transaction within an orchestration and configuring exception
handling are:
    1. Create a scope.
    2. Identify the type of transaction that is needed and configure the scope as transactional;
       also identify an appropriate value for the transaction timeout.
    3. Determine the level at which the transaction will be compensated, if at all.
    4. Identify the potential errors that will cause the need for compensation.
    5. Add the appropriate exception handlers to scopes.
    6. Define the code that will be used to compensate the completed transaction.
Lesson 2: Configuring Transactions




Lesson objective:

Create and configure long-running and atomic transactions.

Overview
An orchestration or scope can be treated as an atomic transaction, a long-running transaction,
or neither. In this lesson, you will learn how to configure long-running and atomic transactions,
how to create modular orchestrations, and how to add compensation code to your transactions.
Defining an Orchestration as Transactional




Modify the properties of an orchestration to enable transaction processing.

Overview
You can configure your orchestration as a transaction in much the same way that you can
configure a Scope shape as a transaction. An orchestration can be treated as an atomic
transaction, as a long-running transaction, or as neither. The transaction type is specified by
setting the Transaction Type property for the orchestration to Atomic, Long Running, or None.
You cannot nest a transactional scope within a scope or orchestration that is not transactional.
An enclosing scope or orchestration that is not transactional will not manage state as is
necessary to properly handle the state management of any scopes within it.
Creating a Long-Running Transaction




Configure an orchestration to enable a long-running transaction.

Overview
You use a long-running transaction when the transaction may need to run for an extended time
and you do not need full ACID (Atomicity, Consistency, Isolation, and Durability) properties—
that is, you do not need to guarantee isolation of data from other transactions. A long-running
transaction may include long periods of inactivity, often because it is waiting for external
messages to arrive.

Characteristics
Long-running transactions possess consistency and durability, but not atomicity and isolation.
The data in a long-running transaction is not locked; therefore, other processes or applications
can modify it. The isolation property for state updates is not maintained within the
orchestration because holding locks for a long duration is impractical. A long-running transaction
is considered committed when the last statement in it has been completed.
Long-running transactions can contain both atomic transactions and other long-running
transactions—in fact, they can be nested many levels deep. For example, your long-running
transaction may contain two other long-running transactions, each of which contains atomic
transactions. Nesting is particularly useful if one or more components of an overall transaction
must be atomic but the overall transaction itself must be long running.
Example
Consider the process of receiving and approving a loan application. The application can arrive at
any time, and the various steps in the process of fulfilling the application may take a
considerable time, but you may still want to treat the entire process as one transaction. In this
case, the overall transaction clearly needs to be long running, but any one individual step (such
as acknowledging a deposit) could be atomic.
Creating an Atomic Transaction




Configure an orchestration to enable an atomic transaction.

Overview
Atomic transactions guarantee that any partial updates will be rolled back automatically in the
event of a failure during the transactional update and that the effects of the transaction will be
erased. You can use atomic transactions when you require full ACID properties on the data, such
as when you must isolate the data from other transactions. However, the full ACID properties
are only achieved when making updates or communicating with a system that is transactional
aware. For example, if you are updating a Microsoft SharePoint® site or sending an e-mail
message, an automatic rollback may not be achieved.

Characteristics
An atomic transaction ensures that state changes within the transaction (such as modifications
to variables, messages, and objects) are visible outside the scope of the atomic transaction only
upon commitment of the transaction. The intermediate state changes are isolated from other
parts of an orchestration.
If an atomic transaction contains a Receive shape, a Send shape, or a Start Orchestration shape
(a shape that invokes another orchestration asynchronously), the corresponding actions will not
occur until the transaction has been committed.
Atomic Orchestrations
You can also define an entire orchestration as an atomic transaction when you need to provide
ACID properties for the data within an entire orchestration. See “Defining an Orchestration as
Transactional” earlier in this module.
Creating Modular Business Processes




Configure an orchestration to call or start another orchestration.

Overview
You can use either the Call Orchestration shape or the Start Orchestration shape to invoke one
orchestration from another. You can nest orchestrations many levels deep. For example, a called
orchestration can call a third orchestration, which can call a fourth, and so on.

Call Orchestration Shape
The Call Orchestration shape invokes another orchestration synchronously. In this case, the
calling orchestration waits for the nested orchestration to finish processing before it continues
its work.

Start Orchestration Shape
The Start Orchestration shape functions similarly to the Call Orchestration shape, but it invokes
another orchestration asynchronously—that is, the flow of control in the calling orchestration
proceeds beyond the invocation without waiting for the nested orchestration to finish
processing.

Parameters
In either case, you can specify parameters to be passed to the called orchestration. Parameters
can be messages, variables, or port references. Parameters supply information to the invoked
orchestration, which in turn sends information back to the enclosing orchestration. Parameters
can be specified as in, out, or to be passed by reference on an orchestration instance.
Demonstration: Creating Transactions




Learn to create transactional orchestrations and add transactional scopes to orchestrations.

        The following demonstration is not dependent upon completion of the previous
        demonstrations. This solution provides artifacts and file paths that differ from those
        used in the previous demonstrations.

Set an Orchestration as Transactional
    1. In Microsoft Windows Explorer, navigate to
       C:\AllFiles\DemoCode\Module10\AdvWorks, and open AdvWorks.sln.
    2. In Solution Explorer, in the Processes project, double-click ProcessOrder_Credit.odx to
       open the orchestration.
    3. Click any of the white space in the orchestration, and then in the ProcessOrder_Credit
       Properties window, change the Transaction Type to Atomic.
            Notice that several new properties have been added to the orchestration now that it
            is a transaction.
    4. In the Transaction Identifier box, type ProcessOrder_CreditTrans.

Add a Transactional Scope to an Orchestration
   1. In the ProcessOrder_Credit orchestration, right-click the downward-pointing arrow
      above the Determine Lender Decide shape, point to Insert Shape, and then click Scope.
   2. In the Scope shape Properties window, configure the properties as shown in the
      following table.
        Property                                Value

        Name                                    Send Loan to Lender

        Transaction Type                        Long Running



   3. In the Properties Window dialog box, click Details.
           Notice the error description, which reads as follows: “An Atomic Transaction cannot
           contain any other Transactions.”
   4. In the Properties Window dialog box, click OK.
   5. Click any of the white space in the orchestration, and then in the ProcessOrder_Credit
      Properties window, change the Transaction Type to Long Running.
   6. In the Transaction Identifier box, type ProcessOrder_CreditTrans.
   7. Click the Send Loan to Lender scope, and then, in the Properties window, change the
      Transaction Type to Long Running.
   8. In Orchestration Designer, drag the Determine Lender decide shape to a location inside
      the Send Loan to Lender scope shape.

Add an Exception Handling Block to a Scope
   1. On the left port surface, click the BankNotification send port, then in the
      BankNotification Port Properties window, in the Delivery Notification list, select
      Transmitted.
           The BankNotification send port is now configured to provide a delivery notification.
           The orchestration run-time will throw an exception if the physical send port fails to
           transmit the message.
   2. In Orchestration Designer, right-click the Send Loan to Lender scope shape, and then
      click New Exception Handler.
   3. In the Catch Exception Shape Properties window, in the Name box, type Catch
      DeliveryFailureException, then in the Exception Object Name box, enter Ex, and then in
      the Exception Object Type list, click <.NET Exception>.
   4. In the Select Artifact Type dialog box, in the left pane, click
      Microsoft.XLANGs.BaseTypes, then in the right pane, click DeliveryFailureException,
      and then click OK.
   5. Inside the Catch DeliveryFailureException block, right-click Drop a shape from the
      toolbox here, point to Insert Shape, and then click Message Assignment.
   6. Name the new Construct Message shape Construct Exception Message, and in the
      Messages Constructed list, click msgCancelOrder.
7. Double-click the Message Assignment shape, and in the BizTalk Expression Editor, enter
   the following lines of code.

   msgCancelOrder = msgSalesOrder;
   msgCancelOrder.Comment =
       System.String.Format(
          “Order canceled. Error: Delivery of loan document failed. [{0}]”,
             ex.Message);

8. Right-click beneath the Message Assignment shape, point to Insert Shape, and then click
   Send.
9. In the Send Shape Properties window, change the Name to Cancel Order, and then in
   the Message list, click msgCancelOrder.
10. Connect the Send shape to the CancelOrder port.
11. Right-click beneath the Message Assignment shape, point to Insert Shape, and then click
    Terminate.
12. Double-click the Terminate shape, and in the BizTalk Expression Editor window, enter
    the following line of code.

   System.String.Format(“Exception caught: {0}”, ex.Message);

       This exception block will create a new message to cancel the order, and then it will
       terminate the orchestration.
13. Pause the bt10d-demos virtual machine.
Adding Compensation Code




Add compensation handling to an orchestration.

Overview
You can add compensation code to your orchestration so that if an error occurs during a long-
running transaction, the effects of the transaction will be reversed. When necessary, the
compensation code is called after the transaction has completed its actions. At that point, the
state of the orchestration is known, and the appropriate compensation code can be applied.
You can also use compensations for atomic transactions. These compensations can be called
only after the atomic transaction commits. You must write code to undo or reverse the path of
the normal execution in the compensation.

Default Compensation
If you do not add your own compensation, the run-time engine performs a default
compensation that invokes the compensations of any nested transactions in the current
transaction. The run-time engine first invokes the compensation of the most recently completed
transaction, and then it works backward until it has compensated all nested transactions.
Demonstration: Adding Compensation Code




Learn to add exception handling and compensation blocks to a transactional scope.

Add a Compensation Block to a Transaction
    1. Resume the bt10d-demos virtual machine.
    2. Right-click the Send Loan to Lender scope shape, and then click New Compensation
       Block.
    3. In the Compensation Block Properties window, change the Name to Send Order
       Compensation
    4. Inside the Compensation Block, right-click Drop a shape from the toolbox here, point to
       Insert Shape, and then click Message Assignment.
    5. Right-click the new Construct Message shape, and name it Construct Exception
       Message, and in the Messages Constructed list, click msgCancelOrder.
    6. Double-click the Message Assignment shape, and in the BizTalk Expression Editor, enter
       the following lines of code.

        msgCancelOrder = msgSalesOrder;
        msgCancelOrder.Comment =
               “Customer cancelled order. Transaction Compensation executed”;
7. Right-click beneath the Message Assignment shape, point to Insert Shape, and then click
   Send.
8. In the Send Shape Properties window, change the Name to Cancel Order, and then in
   the Message list, click msgCancelOrder.
9. Connect the Send shape to the CancelOrder port.
       This scenario assumes that additional shapes will eventually be added to follow after
       the Send Loan to Lender scope shape.
       This compensation block would execute if any of those subsequent shapes threw an
       exception. The orchestration’s default exception handler would catch the exception,
       and execute the compensation blocks on any of its scope shapes.
       This compensation block would create and send a new message to cancel the order,
       and then it will return control to the orchestration run-time, allowing other
       compensation blocks to execute.
10. Close all open windows, and shut down the bt10d-demos virtual machine.
Lab: Creating Transactional Business Processes




Time estimated: 45 minutes

Scenario
Exception handling can be added to scope shapes within orchestrations to specify actions to be
executed in the event that an exception occurs. BizTalk orchestrations can include both long-
running and atomic transactions. Compensation, a feature of transactions, allows for the
reversal of previously completed processes. In this lab, you will configure exception handling
and compensation for the ProcessOrder_Credit orchestration.
Start the Virtual Machine
Procedure List
    1. If the Server Manager window is not already open, click on the Server Manager icon
       located in the task bar next to the Start button.
   2. Expand Roles, Hyper-V, Hyper-V Manager. The last node to appear displays the
      machine name. Click on it to see the list of virtual machines available.
   3. Double-click the virtual machine bt10d-10 to open a Virtual Machine Connection
      window.
   4. Click on the Action menu in the Virtual Machine Connection window and choose Start.
   5. Once the virtual machine starts, press CTRL+ALT+END.
   6. Log on using the user name Administrator and the password pass@word1.
   7. At the Windows Activation prompt, click Ask Me Later, then click OK.

Ensure that the BizTalk Services are started
Procedure List
    1. In Windows Explorer, navigate to C:\AllFiles.
   2. Double click on startBtServices.cmd.
   3. When prompted, press any key to close the command-line window.
Exercise 1: Adding Exception Handling to an Orchestration
Overview
Various things can cause an exception to occur in an orchestration. Adding exception handling
to an orchestration enables you to specify actions to be performed when an exception occurs.
Exception handling blocks can only be added to scope shapes. In this exercise, you will add a
scope shape to the ProcessOrder_Credit orchestration, and then configure an exception handler
that will send a message when a specific exception is caught.

Add a Scope Shape
Procedure List
    1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab10\AdvWorks, and then open
       AdvWorks.sln.
   2. In Solution Explorer, in the Processes project, double-click ProcessOrder_Credit.odx to
      open the orchestration.
   3. In the ProcessOrder_Credit orchestration, right-click the downward-pointing arrow
      above the Determine Lender Decide shape, point to Insert Shape, and then click Scope.
   4. Right-click the Scope_1 shape and click Properties Window
   5. In the Scope_1 Properties window, configure the properties as shown in the following
      table.
         Property                               Value

         Name                                   Send Loan to Lender

         Transaction Type                       None



   6. In Orchestration Designer, drag the Determine Lender Decide shape to a location inside
      the Send Loan to Lender scope shape.

Add Exception Handling to the Send Loan to Lender Scope
Procedure List
    1. In Orchestration Designer, right-click the Send Loan to Lender scope shape, and then
       click New Exception Handler.
   2. In the CatchException_1 Properties window, in the Exception Object Type list, click
      <.NET Exception>.
   3. In the Select Artifact Type dialog box, in the left pane, click
      Microsoft.XLANGs.BaseTypes, in the right pane, click DeliveryFailureException, and
      then click OK.
           This exception handler will be initiated when the send port returns a delivery failure
           notification to a send shape in the Send Loan to Lender scope.
   4. In the CatchException_1 Properties window, in the Name box, type Catch
      DeliveryFailure, and then in the Exception Object Name box, type DeliveryFailure.
    5. In the Catch DeliveryFailure catch exception shape, right-click Drop a shape from the
       toolbox here, point to Insert Shape, and then click Send.
    6. In the Send_1 Properties window, in the Name box, type Rescind Notify Bank, and then
       in the Message list, click msgFinalLoan.

Add the Rescind Port
Procedure List
    1. Right-click the left Port Surface, and then click New Configured Port.
    2. On the Welcome page of the Port Configuration Wizard, click Next.
    3. On the Port Properties page, in the Name box, type Rescind, and then click Next.
    4. On the Select a Port Type page, click Use an existing Port Type, in the Available Port
       Types box, click AdvWorks.Processes.RescindType, and then click Next.
    5. On the Port Binding page, in the Port direction of communication list, click I’ll always
       be sending messages on this port, and then click Next.
    6. On the Completing the Port Wizard page, click Finish.
            Notice that the Rescind port has three operations; the RescindType Port Type has
            been provided for you. The three operations will be used for the exception handling
            and compensation of this orchestration.
    7. Connect the Rescind Notify Bank send shape to the BankNotification operation on the
       Rescind port.

Add a Throw Exception Shape
Procedure List
    1. Right-click the arrow below the Rescind Notify Bank send shape, point to Insert Shape,
       and then click Throw Exception.
    2. In the ThrowException_1 Properties window, in the Name box, type Rethrow
       DeliveryFailure, and then in the Exception Object list, click DeliveryFailure.
            Later in this lab, you will configure another exception handler that will catch the
            rethrown DeliveryFailure exception.

Configure the BankNotification Port to Throw an Exception
Procedure List
    1. On the left Port Surface, click the BankNotification port.
    2. In the Port Properties window, in the Delivery Notification list, click Transmitted.
            The BankNotification port will now throw the DeliveryFailure exception that the
            exception handler is expecting.

Add a Scope Shape
Procedure List
    1. Above the Construct msgSOComplete construct message shape, right-click the arrow,
       point to Insert Shape, and then click Scope.
    2. In the Scope_1 Properties window, configure the properties as shown in the following
       table.
         Property                               Value

         Name                                   Completed Sales Order

         Transaction Type                       None



   3. Drag the Construct msgSOComplete and Complete Sales Order shapes to locations
      inside the Completed Sales Order scope shape.

Add Exception Handling to the Completed Sales Order Scope
Procedure List
    1. In Orchestration Designer, right-click the Completed Sales Order scope shape, and then
       click New Exception Handler.
   2. In the CatchException_1 Properties window, in the Exception Object Type list, click
      <.NET Exception>.
   3. In the Select Artifact Type dialog box, in the left pane, click
      Microsoft.XLANGs.BaseTypes, in the right pane, click DeliveryFailureException, and
      then click OK.
           This exception handler will be initiated when the send port returns a delivery failure
           notification to a send shape in the Completed Sales Order scope.
   4. In the CatchException_1 Properties window, in the Name box, type Catch
      DeliveryFailure, and then in the Exception Object Name box, type DeliveryFailure.
   5. In the Catch DeliveryFailure catch exception shape, right-click Drop a shape from the
      toolbox here, point to Insert Shape, and then click Throw Exception.
   6. In the ThrowException_1 Properties window, in the Name box, type Rethrow
      DeliveryFailure, and then in the Exception Object list, click DeliveryFailure.
           Later in this lab, you will configure another exception handler that will catch the
           rethrown DeliveryFailure exception. Notice that this exception handler does not
           send a message to the Rescind port. It simply re-throws the exception.

Configure the SO_Complete Port to Throw an Exception
Procedure List
    1. On the right Port Surface, click the SO_Complete port.
   2. In the Port Properties window, in the Delivery Notification list, click Transmitted.
           The SO_Complete port will now throw the DeliveryFailure exception that the
           exception handler is expecting.
Exercise 2: Adding Compensation to an Orchestration
Overview
Compensation is used to reverse a transaction that has been committed. Compensation blocks
can only be added to transactional scopes. In this exercise, you will create three transactions;
each transaction will have its own compensation block that is configured to send a rescinding
message if an approval message has previously been sent.

Configure the Orchestration and the Send Loan to Lender Scope Shape as a Long-
Running Transaction
Procedure List
    1. Click any white space on the ProcessOrder_Credit orchestration, in the Properties
       window, in the Transaction Type list, click Long Running, and then in the Transaction
       Identifier box, type LR_ProcessOrder_Cred.
    2. In the ProcessOrder_Credit orchestration, click the Send Loan to Lender scope shape,
       and then configure its properties as shown in the following table.
         Property                               Value

         Transaction Type                       Long Running

         Transaction Identifier                 LR_LoanToLender



Add Compensation to the Send Loan to Lender Scope Shape
Procedure List
    1. Right-click the Send Loan to Lender scope shape, and then click New Compensation
       Block.
    2. In the Compensation_1 Properties window, in the Name box, type Send Loan Comp.
    3. In the Send Loan Comp compensation block, right-click Drop a shape from the toolbox
       here, point to Insert Shape, and then click Send.
    4. In the Send_1 Properties window, in the Name box, type Rescind Notify Bank, and then
       in the Message list, click msgFinalLoan.
    5. Connect the Rescind Notify Bank send shape to the BankNotification operation on the
       Rescind port.
            Alternatively, you could have copied and pasted the Rescind Notify Bank shape from
            the exception handler above.

Add a Transactional Scope to the Orchestration
Procedure List
    1. Above the Construct msgRestock construct message shape, right-click the arrow, point
       to Insert Shape, and then click Scope.
    2. In the Scope_1 Properties window, configure the properties as shown in the following
       table.
         Property                               Value
         Name                                  Restock Inventory

         Transaction Type                      Long Running

         Transaction Identifier                LR_Restock



   3. Drag the Construct msgRestock and Restock send shapes to a location inside the
      Restock Inventory scope shape.

Add Compensation to the Restock Inventory Transaction
Procedure List
    1. Right-click the Restock Inventory scope shape, and then click New Compensation Block.
   2. In the Compensation_1 Properties window, change the Name to Restock Inventory
      Comp.
   3. In the Restock Inventory Comp compensation block, right-click Drop a shape from the
      toolbox here, point to Insert Shape, and then click Send.
   4. In the Send_1 Properties window, in the Name box, type Rescind Restock, and then in
      the Message list, click msgRestock.
   5. Connect the Rescind Restock send shape to the Restock operation on the Rescind port.

Add Compensation to the Completed Sales Order Transaction
Procedure List
    1. Click the Completed Sales Orders scope shape, and then configure its properties as
       shown in the following table.
         Property                              Value

         Transaction Type                      Long Running

         Transaction Identifier                LR_CompleteSO


   2. Right-click the Completed Sales Orders scope shape, and then click New Compensation
      Block.
   3. In the Compensation_1 Properties window, change the Name to Complete Sales Order
      Comp.
   4. In the Complete Sales Orders Comp compensation block, right-click Drop a shape from
      the toolbox here, point to Insert Shape, and then click Send.
   5. In the Send_1 Properties window, change the Name to Rescind Complete Sales Order,
      and then in the Message list, click msgSalesOrderComplete.
   6. Connect the Rescind Complete Sales Order send shape to the CompletedSalesOrder
      operation on the Rescind port.
Exercise 3: Calling Compensation
Overview
Transactions can be nested to provide a parent/child hierarchy. Parent transactions can call the
compensation for each child transaction from the parent’s exception handler, or as part of the
parent’s compensation. In this exercise, you will first add a long-running transaction to the
orchestration. Next, you will move all the existing shapes, including the transactional scope
shapes, into the parent transaction. Finally, you will add an exception handler to the parent
transaction that will call the compensation of some of the child transactions.

Add a Transactional Scope to the Orchestration
Procedure List
    1. In the ProcessOrder_Credit orchestration, right-click the arrow just above the red stop
       sign at the bottom of the orchestration, point to Insert Shape, and then click Scope.
    2. In the Scope_1 Properties window, configure the properties as shown in the following
       table.
         Property                               Value

         Name                                   Credit Process

         Transaction Type                       Long Running

         Transaction Identifier                 LR_CreditProcess



    3. Double-click the icon at the top of the Send Loan to Lender scope shape to collapse it.
    4. Repeat step 3 to collapse the Restock Inventory scope shape and the Completed Sales
       Order scope shape.
    5. Drag the Completed Sales Order scope shape inside the Credit Process scope shape.
    6. Drag the Restock Inventory inside the Credit Process scope shape, and above the
       Completed Sales Order scope shape.
    7. Drag the Send Loan to Lender scope shape inside the Credit Process scope shape, and
       above the Restock Inventory scope shape.

Initiating Compensation from an Exception Handler
Procedure List
    1. Right-click the Credit Process scope shape, and then click New Exception Handler.
    2. In the CatchException_1 Properties window, in the Exception Object Type list, click
       General Exception, and then in the Name box type Catch General Exception.
    3. In the Catch General Exception exception handler, right-click Drop a shape from the
       toolbox here, point to Insert Shape, and then click Compensate.
    4. In the Compensate_1 Properties window, change the Name to CompleteSO Comp, and
       then in the Compensation list, click LR_CompleteSO.
5. Right-click the line below the CompleteSO Comp shape, point to Insert Shape, and then
   click Compensate.
6. In the Compensate_1 Properties window, in the Name box, type Restock Comp, and
   then in the Compensation list, click LR_Restock.
       Notice that the exception handler for the Credit Process scope does not call the
       compensation block of the Send Loan to Lender scope. Consequently, the Send Loan
       to Lender compensation code will never be called.
Exercise 4: Testing the Application
Overview
In this exercise, you will test the application. First, you will process messages normally. You will
then reconfigure a port to simulate the loss of connectivity between Woodgrove Bank and
Adventure Works. Finally, you will resubmit the message to test the exception handling and
compensation.

Deploy the Solution
Procedure List
    1. In Solution Explorer, right-click the AdvWorks solution, and then click Deploy Solution.

Configure and Start the Application
Procedure List
    1. On the Start menu, point to All Programs, point to Microsoft BizTalk Server 2010, and
       then click BizTalk Server Administration.
    2. In the BizTalk Server Administration Console, expand BizTalk Server Administration,
       BizTalk Group, Applications, and AdventureWorks.
    3. Right-click AdventureWorks, and then click Configure.
    4. In the Configure Application dialog box, click ProcessOrder_Cash, and then configure
       the bindings as shown in the following table.
         Property                                 Value

         Host                                     BizTalkServerApplication

         Inbound Logical Ports                    Receive Ports

         SalesOrder                               SalesOrder

         Outbound Logical Ports                   Send Ports/Send Port Groups

         Restock                                  RestockFILE

         SO_Complete                              CompleteFILE



    5. In the Configure Application dialog box, click ProcessOrder_Credit, configure the
       bindings as shown in the following table, and then click OK.
         Host                                     Value

         Host                                     BizTalkServerApplication

         Inbound Logical Ports                    Receive Ports

         SalesOrder                               SalesOrder

         Outbound Logical Ports                   Send Ports/Send Port Groups

         BankNotification                         BankNotifyFILE
         Rescind                                RescindFILE

         Restock                                RestockFILE

         SO_Complete                            CompleteFILE



   6. Right-click AdventureWorks, and then click Start.
   7. In the Start ‘AdventureWorks’ Application dialog box, click Start.

Test the Application
Procedure List
    1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab10.
   2. Open and examine each message.
           There are two Cash messages, which will be processed by the ProcessOrder_Cash
           orchestration, and there are two Credit messages, which will be processed by the
           ProcessOrder_Credit orchestration. The Credit order for over $1,000 will be sent to
           Woodgrove Bank, and the other will be financed by Adventure Works.
   3. Copy the four XML messages to the SalesOrderIN folder.
   4. Open the SalesOrderIN folder.
           Notice that the messages disappear when they are picked up for processing by
           BizTalk Server.
   5. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab10\OUT, and then notice the
      nine output messages.
           Each order has a “Complete” message and a “Restock” message. The credit order
           over $1,000 also has a BankNotify message, which will be sent to Woodgrove Bank.
   6. Delete all of the XML files in the OUT folder.

Modify the CompleteFILE Send Port
Procedure List
    1. In the BizTalk Server Administration Console, in AdventureWorks, click Send Ports.
   2. Double-click the CompleteFILE send port.
   3. In the Send Port Properties dialog box, click Configure.
   4. In the Destination folder box, type C:\FolderThatDoesNotExist, and then click OK.
           The CompleteFILE send port won’t be able to send the completed sales order
           message and will cause the exception handling and compensation to be called.
   5. In the Send Port Properties dialog box, click Transport Advanced Options, change the
      Retry count to 0, and then click OK.
   6. Right-click the CompleteFILE send port, and then click Start.

Test the Exception Handling and Compensation
Procedure List
   1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab10, and then open
      CredSalesOrder1Info.xml.
           Notice that this is the Credit order that totals $1,500, and will therefore be sent to
           Woodgrove Bank for financing.
   2. Copy CredSalesOrder1Info.xml to the SalesOrderIN folder.
   3. Open the SalesOrderIN folder.
           Notice that the message disappears when it is picked up for processing by BizTalk
           Server.
   4. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab10\OUT, and then notice the
      output messages.
           The BankNotification and Restock messages were sent, but delivery of the Complete
           message failed. The delivery failure triggered the Credit Process exception handler,
           which attempted to execute compensation for the Restock Inventory scope and the
           Completed Sales Order scope. A scope’s compensation execute only if it has
           completed successfully earlier in the long-running transaction. Therefore, only the
           Restock Inventory compensation block will execute.

Modify the BankNotifyFILE Send Port
Procedure List
    1. In the BizTalk Server Administration Console, in AdventureWorks, click Send Ports.
   2. Double-click the BankNotifyFILE send port.
   3. In the Send Port Properties dialog box, click Configure.
   4. In the Destination folder box, type C:\FolderThatDoesNotExist, and then click OK.
           The BankNotifyFILE send port won’t be able to send the bank notification message
           and will cause the compensation and exception handling to be called.
   5. In the Send Port Properties dialog box, click Transport Advanced Options, change the
      Retry count to 0, and then click OK.

Test the Exception Handling and Compensation
Procedure List
    1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab10, and then open
       CredSalesOrder1Info.xml.
           Notice that this is the Credit order that totals $1,500, and will therefore be sent to
           Woodgrove Bank for financing.
   2. Copy CredSalesOrder1Info.xml to the SalesOrderIN folder.
   3. Open the SalesOrderIN folder.
           Notice that the message disappears when it is picked up for processing by BizTalk
           Server.
   4. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab10\OUT, and then notice the
      output messages.
The BankNotification message was unable to send. The delivery failure triggered the
Send Loan to Lender exception handler, which send a message to the Rescind port,
and re-threw the delivery exception. The re-thrown exception was caught by the
Credit Process exception handler, which attempted to call compensation on the
Restock Inventory scope and the Completed Sales Order scope. Since these scopes
had not yet executed, their compensation blocks did not run.

								
To top