BPMN Flow Objects

This section describes the BPMN design elements and their properties as they are represented in the Intalio|BPMS Designer application. Appendix Contents

Flow Objects Overview Basic BPMN Shapes Events Gateways

Flow Objects Overview

This section provides a brief overview of the key elements used in creating a process design and their properties:

Basic BPMN Shapes Events Gateways Common Properties

Activities, events and gateways are accessed directly from the Palette panel or from Modeling Assistant. Flow connectors, described separately inFlow Connector Properties, are delineated with the mouse cursor.

Basic BPMN Shapes

The BPMN specification describes an activity as "a generic term for work that [a process participant] performs." In the Intalio|BPMS Designer, the Palette panel represents multiple forms of the two basic activities: task and sub-process. Tasks are the most basic unit; subprocesses represent bound BPMN objects. As shown below, activities are represented by rectangles with rounded corners. Pools and lanes are also included inside the basic shapes. A pool represents a participant in a process. It is also acts as a "swim lane" and a graphical container for partitioning a set of activities from other pools. A Lane is a sub-partition within a Pool and will extend the entire length of the Pool, either vertically or horizontally. Lanes are used to organize and categorize activities.

Flow connectors also included inside the basic shapes. Flow Connector: This is using for connecting between two activities in the same pool. Message Connection: This Connector is using for connecting between two activities which

are in different pools Association: This is using for to connect from activity to a text annotation or to a data objects.

These objects and their properties are further described in Activities. Figure 1- Activities Represented in the Palette Panel

NOTE: Technically, per the BPMN specification, an entire pool and its contents also constitute an activity.

Events
Events represent events that affect the process flow. They can cause or trigger or a result. There are three types of events (start, intermediate, and end), as further described in Events. As shown below, events are represented by circular object shapes. The graphical icons indicate the type of trigger or result associated with the event. Figure 2- Events Represented in the Palette Panel

Gateways
Gateways represent points of decision in the process diagram from which the process flow can continue down one or more paths. Gateways direct the process flow in one of three ways:

Exclusively: only one branch can execute. Inclusively: one or more branches may execute. In parallel: all branches execute.

Furthermore, gateways can determine flow direction based on the contents of the process data (data-based) or based on which subsequent event executes first (event-based). Figure 3- Gateways Represented in the Palette Panel

For more information about gateway objects and their properties, see Gateways

Activities
Task and Looping Task Properties
This section describes the Task and Looping Task activities. These activities are identical; the Looping Task simply has the Loop type property preset to Standard. Figure 5- Task Activity Shapes

Property Label

Description Using this you can give the name for activity. You can use this field to add additional documentation about the selected Documentation activity. Technical Name Here you can give the technical name for the looping task Loop type A task can be one of three loop types: While (default) This type will create while condition for the loop. The activity evaluates the Boolean condition and continues to loop as long as the expression evaluates true. Repeat until - This type creates a multi-instance task. The activity evaluates a Boolean expression and continues until the expression evaluates as true. This condition executes minimum once. Foreach - This type creates a multi-instance task. For each element of the node-set (first argument) the quoted XPath expression (second argument) is evaluated and the result put into a node set. NOTE: Foreach is not implemented in Looping task, so this is included for future reference only. NOTE: If the While or Repeat until or For Each option is set, the activity shape will display the curling loop icon. Also, either looping option

Activity Type

necessitates additional properties that must be configured. For more information, see Working with Looping Activities.. It will display the name of the activity type. Using this we can change the activity Type

Sub-Process Properties
This section describes all the Sub-process activitys. The Palette displays two different shapes but these activities are identical and share the same properties; the Looping Subprocess simply has the Loop type property. Both contain prepositioned activities, which be replaced and modified as desired. NOTE: To display sub-process properties, select the outer boundary of the activity. When selected it displays as red. Figure 6- Sub-Process Activity Shapes

Property Label

Description Using this you can give the name for activity. You can use this field to add additional documentation about the selected Documentation activity. Technical Name You can give the technical name for the looping task Loop type A task can be one of three loop types:

Activity Type ODE Failure Handling Fault on failure Retry Delay Retry for

oWhile (default) This type will create while condition for the loop. The activity evaluates the Boolean condition and continues to loop as long as the expression evaluates true. oRepeat until - This type creates a multi-instance task. The activity evaluates a Boolean expression and continues until the expression evaluates as true. This condition executes minimum once. oForeach - This type creates a multi-instance task. For each element of the node-set (first argument) the quoted XPath expression (second argument) is evaluated and the result put into a node set. NOTE: Foreach is not implemented in Looping task, so this is included for future reference only. NOTE: If the While or Repeat until or For Each option is set, the activity shape will display the curling loop icon. Also, either looping option necessitates additional properties that must be configured. For more information, see Working with Looping Activities It will display the name of the activity type. Using this we can change the activity Type This you can use when you are using boundary events. By default it is false while using the boundary events you can this accordingly. Here you can use integer value for how much time it need to delay for retry. Here you can use integer value for how many times it needs to retry.

Events
Event are divided into three categories, each of which contains its own set of events:

Start Events Intermediate Events End Events

All the events having same properties mentioned below.

Property

Description

Label

Using this you can give the name for activity. You can use this field to add additional documentation about the selected Documentation activity. Technical Name You can give the technical name for the looping task It will display the name of the activity type. Using this we can change the Activity Type activity Type

Each category is further described below.

Start Events
There are three kinds of start events:

Empty Start Event Message Start Event Rule Start Event

Empty Start Event The Empty start event simply indicates where the process execution begins. (Other start events define types of triggers, such as a type of message.) Figure 7- Empty Start Event Icon

Message Start Event This event triggers process execution based on an incoming message. Figure 8- Message Start Event Icon

Rule Start Event This event triggers process execution based on an incoming message. Figure 9- Rule Start Event Icon

NOTE: Timer Start Event also there but it was not implemented in current version.

Intermediate Events
There are six kinds of intermediate events:

Empty Intermediate Event Message Intermediate Event Timer Intermediate Event Error Intermediate Event Compensation Intermediate Event Rule Intermediate Event

Empty Intermediate Event The Empty intermediate helps document the process diagram. Figure 10- Empty Intermediate Event Icon

 Message Intermediate Event This event awaits for the arrival of a message from a participant. Figure 11- Message Intermediate Event Icon

Timer Intermediate Event This event waits for a specified duration of time. Figure 12- Timer Intermediate Event Icon

Error Intermediate Event Within the normal flow, this event maps to a throw element. Attached to an activity, the mappings of the activity (to which the Event is attached) will be placed within a scope and the event maps to a catch element within a scope. NOTE: For more information about this event, see Working with Exception Handlers. Figure 13- Error Intermediate Event Icon

Compensation Intermediate Event This event attaches to a transactional subprocess and indicates how that sub-process may be compensated. In a process design in the event of a rollback. A compensation event uses a compensation flow connector to direct the process to a compensation activity. Figure 14- Compensation Intermediate Event Icon

Rule Intermediate Event This event awaits for the arrival of a message from a participant. Figure 15- Rule Intermediate Event Icon

End Events
There are four kinds of end events:

Empty End Event Message End Event Error End Event Terminate End Event

Empty End Event The Empty end event simply indicates where the process execution ends. Figure 16- Empty End Event Icon

Message End Event This event sends a message when the process completes. Figure 17- Message End Event Icon

Error End Event This event generates an error when the process completes. Figure 18- Error End Event Icon

Terminate End Event

This event forces a process to terminate even if other, parallel events in the same flow are still executing. Figure 19- Terminate End Event Icon

Gateways
All four gateway shapes have the same set of properties. However, they behave differently in the diagram context. NOTE: For more information about gateways, see Working with Gateways and Decision Points. Table 2: Gateways and Their Behavior

Icon

Name

Description

Process flow direction is determined by evaluation of process data against conditions set for each branch, with a default branch if no Data-based conditions are met. Only one branch can execute. exclusive All flow connectors originating from this gateway are condition flow connectors by default.

Data-based The same as above, except more than one branch is allowed to inclusive execute, based on matching conditions.

Event-based Process flow direction is determined by the first event to execute

exclusive

on a flow connector originating from this gateway. For example, this gateway may have two branches, one with an activity awaiting a "Not Available" message, the other with an activity awaiting a "Quote" message. If the "Quote" message is received first, the process flow will continue along the flow of the activity that consumes it; the other flow will be ignored. All flow connectors originating from this gateway are sequence flow connectors by default.

Parallel

The process flow follows every direction. All flow connectors originating from this gateway are sequence flow connectors by default.

Table 3: Gateway Properties

Property Label

Description Using this you can give the name for activity. You can use this field to add additional documentation about the selected Documentation activity. Technical Name You can give the technical name for the looping task It will display the name of the activity type. Using this we can change the Activity Type activity Type

Starting a Process Flow

Each participant in a process diagram represents a process flow, and each process flow begins with a start event, which indicates where the process starts its execution. For an executable process, you can only use Message Start event. NOTE: For more information about start events and their properties, see Start Events

To indicate a manually instantiated process (non executable processes only): 1. Create a new process diagram or add a new participant, as described in Creating a New Process Diagram. 2. Open the Palette panel and select the Start Events tab pane. 3. Select-and-drop the Empty start event onto the diagram, positioning it to the far left end of the pool. Or you can directly add the Empty Start Event from Modeling Assistant The Empty start event is an empty activity with no defined triggers. Figure 4 - Start Events tab pane in the Palette panel

To start a process with a message: 1. Create a new process diagram or add a new participant, as described in Creating a New Process Diagram. 2. Open the Palette panel and select the Start Events tab pane. 3. Select and drop the Message start event onto the diagram, positioning it to the far left end of the pool. Or you can place the mouse pointer to far left and add Message Start Event from the Modeling Assistant pop up window 4. Draw a message link from an activity in another participant to the Message Start Event. The process can only be instantiated by receiving a message. NOTE: For more information about message links, see Creating Message Links. Figure 5 - Message Start Event in a process diagram

Ending a Process Flow

You can indicate where a process ends, force a process to terminate, as well as send a message or trigger an error. The end of a process is indicated by an End event, of which there are four kinds:

Empty - The Empty end event simply indicates where the process execution ends. Message - This event sends a message when the process completes. Error - This event generates an error when the process completes. Terminate - This event forces a process to terminate even if other, parallel events in the same flow are still executing.

To end a process: 1. Open the Palette panel and select the End Event Shapes tab pane. 2. Select and drop the desired end event onto the process design. Or you can place the mouse pointer to right and add End Event from the Modeling Assistant pop up window 3. Draw a flow connector from the preceding object the end event. By definition, the end event must terminate a process flow path. NOTE: If you use the Message end event, you must configure a message link to an activity in another participant. If you use the Error end event, you must configure an exception handler, as described in Working with Looping Activities.

Figure 6 - End Event Shapes Tab

Timing and Scheduling Activities

This section shows you how to use the Timer Event to time and schedule activities. You can either specify a date or specify a time duration for the process to wait before continuing. NOTE: You can also specify timeout limits for sub-process. For more information, see Setting a Timeout Value for a Sub-Process. Use the following procedures:
o o o o

Using the Timer Event Specifying a Specific Date Specifying a Time Duration Setting and Scheduling Properties Manually

Using the Timer Event

To configure timing and scheduling for an activity: 1. Open the Palette panel and select the Intermediate Events tab pane. 2. Select-and-drop the Timer event onto the process design so it is positioned before the desired activity. Or you can place the mouse pointer where you need to add Timer Intermediate Event and add it from the Modeling Assistant pop up window

Setting and Scheduling Properties Manually:

1. Select the Timer event as described in Using the Timer Event. 2. Go to Mapper View. Mapper dynamically displays two nodes i.e. date and duration.

3. Dnd operator node in the middle section of the mapper. For more reference check for Intalio|BPMS: Data Mapper Figure 10 - Setting Timer properties manually 4. In the text box enter the duration or instant information using the format described in the table below. Type Format Examples
o

PT10S

PT + number of days + duration number of hours + minutes + seconds

(Activity scheduled in 10 seconds)

o

PT1D4H20M10S

(Activity scheduled in 1 day, 4 hours, 20 minutes and 10 seconds)

o

12:39:00.000

date

YYYY-MM-DDHH+MM+SS+mmm* *mmm = milliseconds

(Activity scheduled at 12:39)

o

2006-0409T12:39:00.000

(Activity scheduled at 12:39 on April 9, 2006)

The Object Properties dialog box closes. The property is now set.

Working with Looping Activities

Intalio|Designer enables you to include looping constructs in the process diagram. You can use loops to perform repeated operations on the same set of process data until a specific condition is met. This section describes:

Condition-Based Looping

Condition-Based Looping
Figure 1 - Sample loop

Condition-Based Looping
The standard looping option allows the activity to execute only if a set condition is true. For example, a participant may receive a price quote, but will accept the quote only if it receives a certain level of discount. The process data is evaluated to see if this condition is met; if it is, the activity repeats.

This looping will continue till the condition is met. NOTE: If you are familiar with programming constructs, the standard loop construction is identical to DoWhile or WhileDo loops, depending on the Loop Type parameter, described below. The looping execution is determined by the following parameters: Table 1: Standard looping parameters

Description Allows user to select type of looping construct he needs to use in his process. To use the looping construct user needs to click on the value corresponding to Loop type given in properties panel and select the looping construct from the drop down Loop Type menu By default value of Loop Type is set to While

Parameter

To create a condition-based loop in a process diagram: 1. From the Basic BPMN Shapes tab pane of the Palette, drag-and-drop a Looping Sub-Process activity onto the process diagram or simply Add Looping Sub-process from the Modeling Assistant available upon focusing onto the pool. The Basic Shapes tab pane also contains varieties of these shapes with the Loop type parameter preset. 2. Select this activity in the process design and go to Properties panel. 3. In the Properties panel, set the Loop type parameter to the type of looping construct required(None,While,Repeat Until,For each). 4. In the process design, design the looping activities as desired. 5. In the Properties panel, set the looping parameters described in Table 1: Standard looping parameters: 6. Design the condition using Mapper. Click on Looping Sub-process in BPMN Editor , Mapper would be available with 3 panels: Source side(left panel) will display the receiving node that stores the inputted value. Target side(right panel) will display the condition node (While,Repeat Until,For each) as per user's selection. Mapper area(Middle panel)will display the mappings that user would want to perform.

Working with Gateways and Decision Points

Decision points represent points in the process diagram from which the process flow can continue down one or more paths. The decision may be based on contents of the process data (data-based) or based on which subsequent event executes first (event-based). Decision points direct the process flow in one of three ways:

Exclusively: only one branch can execute.

Inclusively: one or more branches may execute. In parallel: all branches execute.

In general, you create decision points using gateways, which are specifically modeled for this purpose. The Gateways tab pane of the Palette panel contains the four gateways supported by Intalio|Designer. Figure 1 - Typical decision point designed with a gateway

NOTE: You can design decision points without using gateways, as described in this section. However, it is not recommended. NOTE: For more information about gateway objects, see Gateways. This section describes the following:

Creating Exclusive Data-Based Decision Points Creating Inclusive Data-Based Decision Points Creating Event-Based Decision Points Directing Process Flow Down Multiple Flows NOTE: Decision points utilize business rules created in the Mapper. For more information, see Working with Gateways and Decision Points.

Creating Exclusive Data-Based Decision Points

Exclusive data-based decision points determine the direction of the process flow by evaluating the process data against defined conditions (also referred to as business rules). The decision point includes a default outcome in case none of the conditions are matched. The term exclusive indicates that only one outcome is intended to result. (To allow multiple results, see Creating Inclusive Data-Based Decision Points.) Therefore, the conditions must be rigidly defined to allow only one outcome. For example, if a numerical value (e.g., a price) is to be evaluated against ranges (1-99, 100-199, 200-299, etc.), the ranges must not overlap (1-100, 100-200, 200-299, etc.). For example, NOTE: If the conditions do allow for one or more outcomes, the runtime behavior may be unpredictable. There are two methods for creating an exclusive data-based decision point:

Using the Data-Based Exclusive Gateway Using Tasks and Conditional Flow Connectors

Both methods are described below.

Using the Data-Based Exclusive Gateway

To create a decision point with the Data-Based Exclusive gateway data: 1. Open the Palette panel and select the Gateway tab. 2. Select and drop the Data-Based Exclusive gateway shape onto the process diagram. 3. Using the flow connector tool, connect the incoming process flow from the left to the gateway. 4. Draw a sequence flow connector from the gateway to the first object of each possible outcome flow. Note: Using sequence flow icon also you can create the connections from right side of the gateway. By default, all sequence flow connectors exiting the Data-Based Exclusive gateway are dynamically defined as conditional. When selected and viewed in the Mapper, the inputs include a Condition element, which is used when defining the business rules. You can create as many as outcome flows as needed; there is no limit. 1. Specify a default outcome path. o Select the condition flow connection from the gateway which you want to change as default. o Right click on the connection and Click on "Sets as default choice".

The default outcome specifies the process flow direction if none of the conditions of the other flows are met. This prevents the process from stalling. To specify a default outcome: Note: the condition flow will be change into default condition flow.

The default condition flow is visually distinguished by a slash. 1. Figure 2 - Decision point using the exclusive database gateway.

2. Create the conditions for evaluating the process data: o Select the conditional flow connector. o Open the Mapper. o Graphically create the criteria for the condition. o Repeat for each conditional flow connector extending from the gateway.

Creating Inclusive Data-Based Decision Points

Inclusive data-based decision points determine the direction of process flow by evaluating the process data against defined conditions (also referred to as business rules). The decision point includes a default outcome in case none of the conditions are matched. The term inclusive indicates that one or more outcomes are permitted to result.

There are two approaches to creating an exclusive data-based decision point:

Using the Data-Based Inclusive Gateway Using Tasks and Conditional Flow Connectors

Both methods are described below.

Using the Data-Based Inclusive Gateway

To create a decision point with the Data-Based Inclusive gateway: 1. Open the Palette panel and select the Gateway tab. 2. select and drop the Data-Based Inclusive gateway shape onto the process diagram. 3. Using the flow connector tool, connect the incoming process flow from the left to the gateway. 4. Draw a sequence flow connector from the gateway to the first object of each possible outcome flow. By default, all sequence flow connectors exiting the Data-Based Inclusive gateway are dynamically defined as conditional. When selected and viewed in the Mapper, the inputs include a Condition element, which is used when defining the business rules. You can create as many as outcome flows as needed; there is no limit. 5. Specify a default outcome path. o Select the condition flow connection from the gateway which you want to change as default. o Right click on the connection and Click on "Sets as default choice". Figure 4 - Decision point using the inclusive database gateway

The default outcome specifies the process flow direction if none of the conditions of the other flows are met. This prevents the process from stalling. To specify a default outcome: Note: the condition flow will be change into default condition flow. The default condition flow is visually distinguished by a slash. 6. Create the conditions for evaluating the process data: o Select the conditional flow connector. o Open the Mapper. o Graphically create the criteria for the condition. o Repeat for each conditional flow connector extending from the gateway.

Using Tasks and Conditional Flow Connectors

To create an inclusive decision point with tasks and conditional flow connectors: 1. Select the task that will represent the decision point. 2. Create the sequences for each possible outcome. 3. Specify the default outcome path. o Select the condition flow connection from the gateway which you want to change as default. o Right click on the connection and Click on "Sets as default choice".

The default condition flow is visually distinguished by a slash. The default outcome specifies the process flow direction if none of the conditions of the other flows are met. This prevents the process from stalling. To specify a default outcome: Note: the condition flow will be change into default condition flow. 4. Draw a conditional flow connector from the decision point task to the first object of each conditional outcome path. In this context, conditional flow connectors are distinguished with diamonds at the source point. When selected and viewed in the Mapper, the inputs include a Condition element, which is used when defining the business rules. You can create as many as outcome flows as needed; there is no limit. Figure 5 - Decision point using the exclusive database gateway

5. Create the conditions for evaluating the process data: o Select the conditional flow connector. o Open the Mapper. o Graphically create the criteria for the condition.

Repeat for each conditional flow connector used in the decision point.

Creating Event-Based Decision Points

Event-based decision points are passive and contain no logic (such as conditions). Unlike data-based gateways, the direction of the process flow is determined by the first activity or event to execute on a branch stemming from the gateway. For example, a customer participant may be awaiting for one of two possible responses from a vendor participant: a Quote message or a Not Available message. If the Quote message is received first, the process flow continues down a different path than if the Not Available message is received first. Figure 6 - Event-based decision point

To create an event-based decision point: 1. Open the Palette panel and select the Gateway tab. 2. Drag and drop the Event-based exclusive gateway shape onto the process diagram. 3. Using the Sequence Flow Connector Tool, connect the incoming process flow from the left to the gateway. 4. To the right of the gateway, connect the gateway to the possible outcome flows. For example, Figure 6 - Event-based decision point above illustrates a gateway with two outcomes: if the Receive NA activity executes first, the process

terminates; if the Receive Quote activity executes first, the process continues down that flow. You can create as many as outcome flows as needed; there is no limit.

Directing Process Flow Down Multiple Flows

You can create a decision point that simply directs the process flow down multiple flows so activities execute in parallel (as opposed to executing in a sequential dependency). You can then reunite these flows back into a single flow. NOTE: The process execution will wait until the last task in each parallel flow has completed. Use the Parallel gateway object to design this type of decision point: 1. Open the Palette panel and select the Gateway tab. 2. Select and drop the Parallel gateway shape onto the process diagram. NOTE: Technically, it is possible to use a Task shape (from the Basics tab pane) in place of the Parallel gateways in this construct, but it is not recommended. 3. Create the sequences for each possible outcome. 4. Using the flow connector tool, connect the incoming process flow from the left to the gateway. 5. Draw a flow connector from the gateway to the first object of each parallel outcome path. 6. At the point after which the parallel activities have executed, restore the multiple flows to a single common flow: o select and drop a second Parallel gateway onto the process design at the end of the parallel o Draw a flow connector from the last object of each parallel path to the second gateway shape. Figure 7 - Parallel gateway used to create parallel flows shows the parallel paths being rejoined into a single flow. Figure 7 - Parallel gateway used to create parallel flows

You can also nest Parallel gateway constructs inside one another, as shown below. Figure 8 - Nested parallel gateways

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. 2. 3. 4. Trans_AB executes and completes. Task Y in Trans_YZ executes and completes. Task Z fails due to a business exception. 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. 2. 3. 4. Trans_AB executes and completes. Trans_YZ executes and completes. Task 43 fails due to a business exception. 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 subprocess. 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 XAcomplaint 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: o Label (optional) - Enter the name of the transaction as it should appear in the process diagram. o Transactional - This property must be set to True. o 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 databased 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: o 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 Value of Fault On Failure is set to true, if you want the activity to throw a Failure fault on failure. Value of Retry Delay is set to a reasonable time delay (specified in seconds) Retry Delay between retries. Value of Retry For is set to a positive integer if you want the activity to Retry For attempt self-recovery and retry up to that number of times. 3. o Apply values for the three elements. 4. Open the Palette panel and select the Intermediate Events tab pane. 5. Define the throw Error event: o Drag-and-drop the Error event into the process flow at the desired point. o Select the event and open the Properties panel. The panel lists additional element: Element Description The value for this field will be validated against its counterpart in the configuration for the catch error.The variable needs to get selected Throw<Variable> from the option of values. By default its is set to (No variable selected) o Apply values for the three elements.

6. Define the catch Error event: o 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. o 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 7. You can now design the activities that will handle the exception. 8. 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. 9. Draw a flow connector from the Error event to the exception handler sub-process. Figure 15 - Error event attached to a sub-process
o o

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 subprocess. Figure 17 - Attached compensation event

5. Design the compensating activity (or sequence of activities enclosed in a subprocess). It is recommended you design these activities immediately below the subprocess/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 subprocess/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