This chapter is from the book
This chapter is from the book
This chapter is from the book
Transaction and Exception Activities
Transactions apply to workflows and to transactional/context activities. If a transactional/ context is used, the workflow can continue after any exception has occurred. If an exception is caught at the workflow level it can be handled but the workflow cannot continue.
TransactionalContext Activity
The TransactionalContext activity provides short- and long-term transaction support, exception-handling support, and event-handling support. It defines the transaction boundary and contains all the activities that are to be part of the transaction. This section focuses on catching transaction exceptions at the workflow level.
The TransactionalContext activity actually refers to a set of behaviors that are described in Chapter 8.
)
Figure 3.17 A Listen activity with a Delay path and a Web Service path.
Throw Activity
An exception may be thrown using the Throw activity (shown in Figure 3.18) from within a workflow or within a transactional/context. An exception may also be thrown by another activity on an error condition. Workflows use the second tab on the lower-left of the design surface as shown in Figure 3.1 for accessing the exceptions views. For the exception view of a Transactional/context use the context menu in a Scope to access the exception view.
){kind=link}
)
Figure 3.18 A Throw activity.
When an exception is thrown it will terminate the workflow immediately unless it is caught. To catch an exception in the workflow click on the View Exceptions tab to show the Exceptions view. The Exceptions view is where you can drag and drop exception handlers.
ExceptionHandler Activity
Exception handlers can only be dragged and dropped to the Exceptions view. Figure 3.19 shows the Exceptions view with no exception handlers. The Scope exceptions view behaves in a similar way.
)
Figure 3.19 The Workflow exceptions design surface.
To catch an exception, you must drag and drop an exception handler from the toolbox and have properties configured. You can drag and drop any number of exception handlers to handle different kinds of exceptions in different ways. In this way, an ExceptionHandler activity functions just like a catch block in code. Figure 3.20 shows the exceptions view with one exception handler and a Code activity added to the body of the exception handler.
In Figure 3.20 the code2 activity will be executed if the exception handler catches an exception. The Code activity has access to the specific exception through a variable specified in the Variable property of the exception handler. The Type property specifies what exceptions will be caught by this exception handler. If the Type property is set to System.Exception, all exceptions will be caught by this exception handler.
For a long-running transaction a Compensate activity is added to the exception handler body.
Compensate Activity
The Compensate activity (shown in Figure 3.21) can only be added to the body of an exception handler. It is used to point to compensation logic that is required to roll back any long-running transaction that has failed. Failure of a long-running transaction is identified by an exception being raised. This figure shows a Compensate activity in the body of an exception handler. For more detail see Chapter 8.
)
Figure 3.20 The Workflow exceptions design surface with one exception handler.
)
Figure 3.21 An exception handler that contains a Code and a Compensate.