Working with Failure and Exceptions

This section shows you how to design around potential failures and exceptions using transactions, exception handlers, and compensations.

In this Section:

• Overview
• Creating Transactions
• Working with Exception Handlers
• Designing Compensations

 

Overview

This overview introduces the basic concepts that enable you to design around failures and exceptions. It explains the types of failure that can occur, mechanisms for dealing with failure and exceptions, and provides illustrative use cases.

In this overview, you will find:

• The Three Types of Failure
• Mechanisms for Designing Around Exceptions
• Compensations vs. Exception Handlers

The Three Types of Failure

There three types of failure that can affect process execution:

• Technical failure

These are events outside the context of the process execution itself that cause the process to become unavailable. Examples of technical failures include disk malfunction, CPU errors, and so on. By their nature, such technical failures cannot be handled, and typically result in interrupting the process execution (until the failure is addressed externally).

• Transient exceptions

These are temporary situations that may resolve themselves over time. Examples would include a downed network, an unavailable Web service, or an offline database. In this case process will be suspended after a number of failed attempts, and then the process can be resumed manually once the problem has been addressed.
In the event of transient, the process will rollback any activities as necessary, then retry the action for specified number of times. If the retries are unsuccessful, the process is then suspended (but not terminated).

• Business exceptions

Business exceptions are typically data-related: the account number may not be recognized or there or insufficient funds for the intended transactions.

 

Mechanisms for Designing Around Exceptions

There are three mechanisms for designing around transient and business exceptions:

• Transactions
• Exception Handlers
• Compensations

These three mechanisms work together to prevent processes from failing by grouping activities into a common all-or-nothing dependency, providing alternative flows when exceptions occur, and triggering compensatory actions to undo completed transactions.

All three mechanisms are further described below.

Transactions

NOTE: Transactions are not fully functional in the current version, so this is for future reference only.

Transactions group a sequence of tasks into an indivisible unit in which either ALL tasks execute or NONE execute. If a task within a transaction fails, all preceding tasks that have already executed are automatically rolled back, meaning that the actions are not committed and in effect, never occurred.

NOTE: Transactionality limits the interaction of tasks in the transaction to XA-compliant participants, such as databases and JMS services. For more information, see Creating Transactions.

In a process diagram, sub-processes are used to join the transaction activities together, as described in Working with Sub-Processes.

Figure 1 - Sub-process as transaction

 

 

Exception Handlers

Exception handlers redirect the process flow when an exception is detected. For example, a task may attempt to debit an account but the account lacks sufficient funds. As a result, an appropriate exception may be raised and an alterative flow is followed. For example, the handler may simply notify the user of the encountered condition and terminate the process.

NOTE: Using an exception handler precludes compensations for previously completed tasks. For more information, see Compensations vs. Exception Handlers.

In a process diagram, exception handlers are designed by attaching an Error event to the sub-process and connecting it to the activity (or sequence of activities) that handles the error.

Figure 2 - Exception handler for a sub-process

 

 

Compensations

NOTE: Compensations are not fully functional in the current version, so this is for future reference only.

Compensations define a process flow that undoes a completed action if a later task fails. For example, Task A receives payment for services provided and completes. Subsequently, however, a Task C fails. The compensation associated with Task A executes activities that refunds the payment.

NOTE: Compensations are not executed if the failing task is assigned an exception handler. For more information, see Compensations vs. Exception Handlers.

In a process diagram, compensations are designed by attaching a Compensation event to the sub-process and connecting it to the activity (or sequence of activities) that compensate for the completed activity of the transactions.

Figure 3 - Compensation activities for a completed transaction

 

 

Compensations vs. Exception Handlers

If an activity fails and raises an exception, the presence of an exception handler provides an alternate flow that prevents the process from failing by indicating an alternative flow of control. It may simply send a failure notification and terminate the process.

However, the exception handler precludes the execution of compensations associated with preceding (and therefore completed) activities. Compensations only execute when exceptions are not handled explicitly.

The following use cases use the same process diagram to illustrate the how exception handlers and compensations are triggered:

• No Exception Handling, No Compensation
• Exception Handler Triggered
• Compensations Triggered
• Order of Compensations

No Exception Handling, No Compensation

In this use case:

1. Task A executes and completes.
2. Task B fails due to a business exception.
3. The process fails because no exception handling has been configured for the Trans_AB sub-process.

Figure 4 - No exception handling, no compensation

Exception Handler Triggered

In this use case:

1. Trans_AB executes and completes.
2. Task Y in Trans_YZ executes and completes.
3. Task Z fails due to a business exception.
4. The Error event attached to Trans_YZ executes, triggering exception handling activities contained in ExHandler_YZ.
5. Task 43 executes and the process flow continues toward completion.

NOTE: Trans_AB is unaffected by the failure; no compensation is triggered because it is precluded by the exception handler attached to Trans_YZ.

Figure 5 - Exception handler triggered

Compensations Triggered

In this use case:

1. Trans_AB executes and completes.
2. Trans_YZ executes and completes.
3. Task 43 fails due to a business exception.
4. The Compensation event attached to Trans_YZ executes, triggering the compensatory activities contained in YZ_Comp.
5. The Compensation event attached to Trans_AB executes, triggering the compensatory activities contained in AB_Comp.

NOTE: The exception handler for Trans_YZ is not triggered in this use case because it executed successfully.

Figure 6 - Compensations triggered

At this point, even though the actions have been compensated, the process fails. To prevent process failure, however, the entire sequence (including the transactions) could be nested in another sub-process for which exception handling is also configured, as shown below.

Figure 7 - Multi-level exception handling

 

 

Order of Compensations

If a process flow contains multiple sub-processes with configured compensations, the compensations execute in reverse order. As shown below, the compensating activities for the Nested 2 sub-process execute prior to the compensating activities for the Nested 2 sub-process.

Figure 8 - Multiple compensating activities

 

 

Creating Transactions

 

This section describes the following:

• Understanding XA-Compliance and Rollback
• Using a Sub-Process Task
• Setting Transaction Properties
• Nesting Sub-Processes

Understanding XA-Compliance and Rollback

Transactions group a sequence of task into an indivisible unit in which either ALL tasks execute or NONE execute. If a task within a transaction fails, all preceding tasks that have already executed are automatically rolled back.

To be truly transactional, any communication with other participants must conform to the XA (transaction authority; see http://www.opengroup.org/bookstore/catalog/c193.htm), namely JDBC, JMS, or the Intalio Internal connector. Otherwise roll-back is not possible and the activity will not behave transactionally.

Roll-back means the completed activities are undone: it is as if they never took place. For example, a transaction contains a sequence of two activities. The first activity communicates with an XA-compliant booking database to reserve a seat assignment; the second activity processes a credit card payment. However, if the credit card payment fails, the seat reservation is rolled back.

Figure 9 - XA-compliant exchanges in a transaction

 

 

NOTE: Roll-back is NOT compensation. Compensation reverses actions executed in completed transactions. For more information, see Compensations.

Using a Sub-Process Task

Transactions are designed as sub-processes with specific property settings.

To create a sub-process for a transaction:

1. Open the Palette panel and select the Basic Shapes tab.

The Basic Shapes tab pane contains two pre-configured sub-process activities. These activities differ only by their contents; they share the same sub-process properties.

2. Drag-and-drop a sub-process activity onto the desired pool in the process diagram.

Figure 10 - Creating a transaction sub-process




3. Design the transaction activities by modifying the contents of the sub-process.

If the activity (or sequence of activities) intended for the transaction is already in the process diagram, you can select them and use the Group tool to transform them into a sub-process.

4. Ensure that communications with activities outside the transaction use XA-complaint transports, as described in Understanding XA-Compliance and Rollback.

You can now set the transaction properties, as described in the next section.

Setting Transaction Properties

After the sub-process activity has been added to the process diagram you can configure the properties to make it transactional.

To set the transaction properties:

1. In the process diagram, select the sub-process by clicking its outermost edge.

When properly selected the outer edge displays as red. If you accidentally select any activity in the sub-process, the activities of that activity will be displayed instead.

2. Open the Properties panel.

Figure 11 - Transactional sub-Process properties




3. Set the properties as follows:
   • Label (optional) - Enter the name of the transaction as it should appear in the process diagram.
   • Transactional - This property must be set to True.
   • Retry count - Specify the maximum number of retries to be attempted if the transaction fails. For example, a value of 0 (the default) will invoke the transaction only once; if it fails, no retry will be attempted.

   NOTE: For more information about sub-process/transaction properties in general, see Sub-Process Properties.

   You can now design compensations for later tasks, as the transaction properties, described in the next section.

    

Nesting Sub-Processes

To make full use of exception handlers and compensating activities, you can nest transactions within sub-processes. For example, compensating activities may undo the actions performed by completed transactions, but they do not handle the exception that may have necessitated the compensations in the first place.

By nesting the transactions in a sub-process, however, you gain a new level at which you can handle the exception, as shown below:

Figure 12 - Transactional sub-Process properties

 

 

In this example, the failure of Task 43 would trigger the compensations for Trans_YZ and Trans_AB (in that order), but instead of the process failing at that point, the exception handler for the AB_YZ_Wrapper sub-process enables the process execution to continue toward completion.

NOTE: You can nest sub-processes within a transaction, you can nest a transaction in a sub-process, but you cannot nest a transaction within a transaction.

You can nest a transaction within a sub-process using one of the following methods:

• Select an existing transaction (and any other activities in the same desired sequence) and click the Group tool.

The selected transaction (and other activities) will be nested inside the newly created sub-process.

OR

• Drag and drop a sub-process shape from the Palette into an existing sub-process and design the transaction activities as desired.

NOTE: In either case, be sure to set the transaction sub-process properties correctly, as described in Setting Transaction Properties.

Figure 13 - Nested sub-processes

Working with Exception Handlers

Exception handlers are used to specify an alternate flow (exception handler) to be invoked if one or more activities in the process diagram fails to execute.

This section describes:

• Throwing and Catching Exceptions
• Configuring Exception Handlers

Throwing and Catching Exceptions

Exception handlers have two parts: the throw and the catch. The throw is an Error event inserted into the process flow (contained in a sub-process that causes an exception; the catch is an Error event attached to the sub-process. When an exception is thrown, the process looks for a matching catch to direct the process flow to the correct exception handler.

For example, the following illustration shows a transaction in which a credit card payment is processed through a database. (The throws and catches have been color-coded for easy visual association.)

Figure 14 - Correlated throw and catch errors

 

 

After the payment information is returned by the database, the process flow enters a data-based gateway that evaluates the data for proper validation:

• If the credit card information was validated, the process flow continues through the Payment Validated activity and the process execution continues toward normal completion.
• If the credit card number evaluates as invalid, however, the process flow is directed to the Invalid CC Error event, which catches the error and activates the Handle Invalid CC exception handler.
• If the funds available value evaluates as invalid, the process flow is directed to the No Funds Error event, which catches the error and activates the Handle No Funds exception handler.
• If the payment is rejected for another reason for which no throw has been defined, the Other Error event catches it and activates the Handle Other exception handler.

As implied above, the throw and the catch are correlated by matching properties, as described in the following section.

Configuring Exception Handlers

To create an exception handler:

1. Create a sub-process that contains the activity or sequence of activities for which you wish to handle an exception.

For more information about creating sub-processes, see Creating a Sub-Process.

2. Define Sub-process:
   
   • Select the Sub-process and open the Properties panel. The panel lists the three additional elements in order to implement ODE Failure Handling:
     

     Element	Description
     Fault on Failure	Value of Fault On Failure is set to true, if you want the activity to throw a fault on failure.
     Retry Delay	Value of Retry Delay is set to a reasonable time delay (specified in seconds) between retries.
     Retry For	Value of Retry For is set to a positive integer if you want the activity to attempt self-recovery and retry up to that number of times.

    

   • Apply values for the three elements.
     
3. Open the Palette panel and select the Intermediate Events tab pane.
4. Define the throw Error event:
   • Drag-and-drop the Error event into the process flow at the desired point.
   • Select the event and open the Properties panel. The panel lists additional element:

     Element	Description
     Throw<Variable>	The value for this field will be validated against its counterpart in the configuration for the catch error.The variable needs to get selected from the option of values. By default its is set to (No variable selected)

   • Apply values for the three elements.

    



5. Define the catch Error event:
   • From the Palette panel, drag-and-drop the Error event onto the bottom edge of the sub-process shape in the process diagram. The Error event will attach to the sub-process.
   • Select the event and open the Properties panel. The panel lists additional element:

     Element	Description
     Catch	The value for this field is retrieved from throw variable or can invoke the value that is directly sent by a webservice. The variable needs to get selected from the option of values. By default its is set to (invoke fault:null)

     
     
   • Apply values for the three elements
     
6. You can now design the activities that will handle the exception.
7. Independent of any process flow, design a sub-process that contains the activities to be executed if one of the sub-process tasks fails to execute.

This sub-process comprises the exception handler.

8. Draw a flow connector from the Error event to the exception handler sub-process.

Figure 15 - Error event attached to a sub-process

As indicated in Correlated throw and catch errors, you can create multiple, correlated throw and catch Error events.

Designing Compensations

NOTE: Compensations are not fully functional in the current version, so this is for future reference only.

Compensations are designed the same as any sequence of events. They are linked to the sub-process/transaction to be compensated via the Compensation event and a compensation flow connector.

NOTE: As described in Compensations, compensation events execute only when a subsequent event fails, and only if there is no exception handler assigned to the failing event.

To compensate for completed sub-processes/ transactions:

1. Identify the sub-process/transaction that needs to be compensated.
2. Open the Palette panel and select the Intermediate Events tab.
3. From the Intermediate Events tab pane, drag a Compensation event onto the bottom edge of the transaction.

Figure 16 - Add compensation event




4. Release the mouse.

The event attaches itself to the left side of the bottom edge of the transaction sub-process.

Figure 17 - Attached compensation event




5. Design the compensating activity (or sequence of activities enclosed in a sub-process).

It is recommended you design these activities immediately below the sub-process/transaction to be compensated or in an alternative lane in the same participant. For conservation of space, you may wish to encapsulate the compensating activities in a sub-process.

NOTE: If the sub-process/transaction is wrapped in another sub-process/transaction, the compensating activities cannot be placed in an alternative lane. The compensating activities must be contained within the same "wrapper."

6. On the toolbar, click on the down arrow next to the Connector tool icon.
7. Select the Sequence Flow Mode option.
8. Draw a flow connector from the Compensation event to the compensating activity.

By default, this creates a compensation flow connector, which is unique to this context. For more information, see Flow Connector Properties.

Figure 18 - Connecting transaction to compensating activities