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

For more information. When selected it displays as red. Both contain prepositioned activities. It will display the name of the activity type. the Looping Subprocess simply has the Loop type property.. see Working with Looping Activities.Activity Type necessitates additional properties that must be configured. You can use this field to add additional documentation about the selected Documentation activity. which be replaced and modified as desired. NOTE: To display sub-process properties. The Palette displays two different shapes but these activities are identical and share the same properties. Technical Name You can give the technical name for the looping task Loop type A task can be one of three loop types: � ��� .Sub-Process Activity Shapes Property Label Description Using this you can give the name for activity. Using this we can change the activity Type Sub-Process Properties This section describes all the Sub-process activitys. select the outer boundary of the activity. Figure 6�.

the activity shape will display the curling loop icon. The activity evaluates the Boolean condition and continues to loop as long as the expression evaluates true. 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. Also. The activity evaluates a Boolean expression and continues until the expression evaluates as true. ��� o�Foreach . This condition executes minimum once.� NOTE: If the While or Repeat until or For Each option is set.This type creates a multi-instance task.This type creates a multi-instance task. each of which contains its own set of events: • • • Start Events Intermediate Events End Events All the events having same properties� mentioned below. Using this we can change the activity Type This you can use when you are using boundary events. Here you can use integer value for how many times it needs to retry. Events Event are divided into three categories.� Property Description . For more information.Activity Type ODE Failure Handling Fault on failure Retry Delay Retry for ��� o�While (default) � This type will create while condition for the loop. see Working with Looping Activities It will display the name of the activity type. 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. NOTE: Foreach is not implemented in Looping task. ��� o�Repeat until . so this is included for future reference only. either looping option necessitates additional properties that must be configured.

Technical Name You can give the technical name for the looping task It will display the name of the activity type. 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. You can use this field to add additional documentation about the selected Documentation activity.Label Using this you can give the name for activity. Figure 8�. (Other start events define types of triggers.Message Start Event Icon .) Figure 7�. such as a type of message.Empty Start Event Icon Message Start Event This event triggers process execution based on an incoming message. Using this we can change the Activity Type activity Type Each category is further described below.

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 9�.Rule Start Event Icon NOTE: Timer Start Event also there but it was not implemented in current version.Empty Intermediate Event Icon . Figure 10�.Rule Start Event This event triggers process execution based on an incoming message.

Error Intermediate Event Icon . Attached to an activity.�� Message Intermediate Event This event awaits for the arrival of a message from a participant. see Working with Exception Handlers. 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.Message Intermediate Event Icon Timer Intermediate Event This event waits for a specified duration of time. Figure 12�. NOTE: For more information about this event. Figure 11�.Timer Intermediate Event Icon Error Intermediate Event Within the normal flow. Figure 13�. this event maps to a throw element.

A compensation event uses a compensation flow connector to direct the process to a compensation activity. Figure 14�.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 .Compensation Intermediate Event Icon Rule Intermediate Event This event awaits for the arrival of a message from a participant.Compensation Intermediate Event This event attaches to a transactional subprocess and indicates how that sub-process may be compensated. Figure 15�. In a process design in the event of a rollback.

Empty End Event The Empty end event simply indicates where the process execution ends. Figure 16�.Message End Event Icon Error End Event This event generates an error when the process completes. Figure 17�. Figure 18�.Empty End Event Icon Message End Event This event sends a message when the process completes.Error End Event Icon Terminate End Event .

This event forces a process to terminate even if other. Event-based Process flow direction is determined by the first event to execute . NOTE: For more information about gateways. However. see Working with Gateways and Decision Points. parallel events in the same flow are still executing.Terminate End Event Icon Gateways All four gateway shapes have the same set of properties. Only one branch can execute. they behave differently in the diagram context. except more than one branch is allowed to inclusive execute. Data-based The same as above. Figure 19�. with a default branch if no Data-based conditions are met. exclusive All flow connectors originating from this gateway are condition flow connectors by default. based on matching conditions. 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.

Using this we can change the Activity Type activity Type Starting a Process Flow Each participant in a process diagram represents a process flow. All flow connectors originating from this gateway are sequence flow connectors by default.exclusive on a flow connector originating from this gateway. For an executable process. All flow connectors originating from this gateway are sequence flow connectors by default. you can only use Message Start event. see Start Events . which indicates where the process starts its execution. the other flow will be ignored. the process flow will continue along the flow of the activity that consumes it. NOTE: For more information about start events and their properties. You can use this field to add additional documentation about the selected Documentation activity. If the "Quote" message is received first. one with an activity awaiting a "Not Available" message. For example. Parallel The process flow follows every direction. the other with an activity awaiting a "Quote" message. this gateway may have two branches. Technical Name You can give the technical name for the looping task It will display the name of the activity type. and each process flow begins with a start event. Table 3: Gateway Properties Property Label Description Using this you can give the name for activity.

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

Message . of which there are four kinds: • • • • Empty . Select and drop the desired end event onto the process design. force a process to terminate. you must configure a message link to an activity in another participant. . as well as send a message or trigger an error.Ending a Process Flow You can indicate where a process ends. Or you can place the mouse pointer to right and add End Event from the Modeling Assistant pop up window 3.The Empty end event simply indicates where the process execution ends. The end of a process is indicated by an End event.This event sends a message when the process completes. parallel events in the same flow are still executing. Draw a flow connector from the preceding object the end event.This event generates an error when the process completes. the end event must terminate a process flow path. 2. By definition. If you use the Error end event. To end a process: 1. Open the Palette panel and select the End Event Shapes tab pane. you must configure an exception handler. Terminate . Error . as described in Working with Looping Activities.This event forces a process to terminate even if other. NOTE: If you use the Message end event.

2. For more information. date and duration. You can either specify a date or specify a time duration for the process to wait before continuing. 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. Go to Mapper View. NOTE: You can also specify timeout limits for sub-process.End Event Shapes Tab Timing and Scheduling Activities This section shows you how to use the Timer Event to time and schedule activities. Mapper dynamically displays two nodes i. Select the Timer event as described in Using the Timer Event. 2. see Setting a Timeout Value for a Sub-Process.Figure 6 . Open the Palette panel and select the Intermediate Events tab pane. . Select-and-drop the Timer event onto the process design so it is positioned before the desired activity.e. 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.

The property is now set. 4 hours.000 date YYYY-MM-DDHH+MM+SS+mmm* *mmm = milliseconds (Activity scheduled at 12:39) o 2006-0409T12:39:00. Dnd operator node in the middle section of the mapper. For more reference check for Intalio|BPMS: Data Mapper Figure 10 . In the text box enter the duration or instant information using the format described in the table below. You can use loops to perform repeated operations on the same set of process data until a specific condition is met. 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. Working with Looping Activities Intalio|Designer enables you to include looping constructs in the process diagram. 20 minutes and 10 seconds) o  12:39:00. 2006) The Object Properties dialog box closes.3. This section describes: • Condition-Based Looping .Setting Timer properties manually 4.000  (Activity scheduled at 12:39 on April 9.

but will accept the quote only if it receives a certain level of discount. the activity repeats. This looping will continue till the condition is met. The looping execution is determined by the following parameters: Table 1: Standard looping parameters . the standard loop construction is identical to DoWhile or WhileDo loops. described below.Condition-Based Looping Figure 1 . NOTE: If you are familiar with programming constructs. The process data is evaluated to see if this condition is met. a participant may receive a price quote.Sample loop Condition-Based Looping The standard looping option allows the activity to execute only if a set condition is true. depending on the Loop Type parameter. For example. if it is.

2. In the Properties panel.For each). 4.Description Allows user to select type of looping construct he needs to use in his process. . 3. In the process design. Design the condition using Mapper. In the Properties panel. 5. set the looping parameters described in Table 1: Standard looping parameters: 6. design the looping activities as desired. The decision may be based on contents of the process data (data-based) or based on which subsequent event executes first (event-based). Target side(right panel) will display the condition node (While. 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. Decision points direct the process flow in one of three ways: • Exclusively: only one branch can execute. The Basic Shapes tab pane also contains varieties of these shapes with the Loop type parameter preset.While. 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. 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.Repeat Until.For each) as per user's selection. Click on Looping Sub-process in BPMN Editor . set the Loop type parameter to the type of looping construct required(None. Mapper would be available with 3 panels: Source side(left panel) will display the receiving node that stores the inputted value. Mapper area(Middle panel)will display the mappings that user would want to perform. From the Basic BPMN Shapes tab pane of the Palette.Repeat Until. Select this activity in the process design and go to Properties panel.

For more information. The Gateways tab pane of the Palette panel contains the four gateways supported by Intalio|Designer.Typical decision point designed with a gateway NOTE: You can design decision points without using gateways. see Gateways. In parallel: all branches execute. as described in this section. you create decision points using gateways.• • Inclusively: one or more branches may execute. 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. Figure 1 . NOTE: For more information about gateway objects. which are specifically modeled for this purpose. see Working with Gateways and Decision Points. In general. Creating Exclusive Data-Based Decision Points . it is not recommended. However.

the runtime behavior may be unpredictable. The decision point includes a default outcome in case none of the conditions are matched. 200-299. if a numerical value (e. a price) is to be evaluated against ranges (1-99. For example. 2. You can create as many as outcome flows as needed. NOTE: If the conditions do allow for one or more outcomes. Open the Palette panel and select the Gateway tab.. there is no limit. Using the Data-Based Exclusive Gateway To create a decision point with the Data-Based Exclusive gateway data: 1. which is used when defining the business rules. the ranges must not overlap (1-100.g. The term exclusive indicates that only one outcome is intended to result. 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. Specify a default outcome path. . 200-299. o Select the condition flow connection from the gateway which you want to change as default. the conditions must be rigidly defined to allow only one outcome. the inputs include a Condition element. 4.). connect the incoming process flow from the left to the gateway. Note: Using sequence flow icon also you can create the connections from right side of the gateway. Using the flow connector tool. all sequence flow connectors exiting the Data-Based Exclusive gateway are dynamically defined as conditional. Select and drop the Data-Based Exclusive gateway shape onto the process diagram. Draw a sequence flow connector from the gateway to the first object of each possible outcome flow. 3.) Therefore. 1.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). For example. o Right click on the connection and Click on "Sets as default choice". see Creating Inclusive Data-Based Decision Points. etc.). etc. 100-200. When selected and viewed in the Mapper. 100-199. (To allow multiple results. By default.

This prevents the process from stalling. o Repeat for each conditional flow connector extending from the gateway. o Open the Mapper. Figure 2 . The decision point includes a default outcome in case none of the conditions are matched. o Graphically create the criteria for the condition.Decision point using the exclusive database gateway. The default condition flow is visually distinguished by a slash. To specify a default outcome: Note: the condition flow will be change into default condition flow. . 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). 1.The default outcome specifies the process flow direction if none of the conditions of the other flows are met. Create the conditions for evaluating the process data: o Select the conditional flow connector. The term inclusive indicates that one or more outcomes are permitted to result. 2.

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

This prevents the process from stalling. Specify the default outcome path.The default outcome specifies the process flow direction if none of the conditions of the other flows are met. Select the task that will represent the decision point. 6. 2. . 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. o Open the Mapper. 3. o Graphically create the criteria for the condition. o Right click on the connection and Click on "Sets as default choice". o Repeat for each conditional flow connector extending from the gateway. o Select the condition flow connection from the gateway which you want to change as default. Create the conditions for evaluating the process data: o Select the conditional flow connector. Using Tasks and Conditional Flow Connectors To create an inclusive decision point with tasks and conditional flow connectors: 1. Create the sequences for each possible outcome.

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

Drag and drop the Event-based exclusive gateway shape onto the process diagram.Event-based decision point To create an event-based decision point: 1.Event-based decision point above illustrates a gateway with two outcomes: if the Receive NA activity executes first. If the Quote message is received first. connect the gateway to the possible outcome flows. 2. For example. the process . 4. Figure 6 . the direction of the process flow is determined by the first activity or event to execute on a branch stemming from the gateway. To the right of the gateway. 3. Using the Sequence Flow Connector Tool. Open the Palette panel and select the Gateway tab. For example. Creating Event-Based Decision Points Event-based decision points are passive and contain no logic (such as conditions). Unlike data-based gateways. Figure 6 . connect the incoming process flow from the left to the gateway.o Repeat for each conditional flow connector used in the decision point. the process flow continues down a different path than if the Not Available message is received first. a customer participant may be awaiting for one of two possible responses from a vendor participant: a Quote message or a Not Available message.

the process continues down that flow. NOTE: Technically. connect the incoming process flow from the left to the gateway. 3. Figure 7 . Use the Parallel gateway object to design this type of decision point: 1. Create the sequences for each possible outcome. You can then reunite these flows back into a single flow. it is possible to use a Task shape (from the Basics tab pane) in place of the Parallel gateways in this construct. there is no limit. Open the Palette panel and select the Gateway tab. but it is not recommended. You can create as many as outcome flows as needed. 6. NOTE: The process execution will wait until the last task in each parallel flow has completed. 4. Select and drop the Parallel gateway shape onto the process diagram. 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). 2. Figure 7 . if the Receive Quote activity executes first. At the point after which the parallel activities have executed. Draw a flow connector from the gateway to the first object of each parallel outcome path. Using the flow connector tool.terminates.Parallel gateway used to create parallel flows shows the parallel paths being rejoined into a single flow. 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.Parallel gateway used to create parallel flows . 5.

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

and so on. you will find: • • • The Three Types of Failure Mechanisms for Designing Around Exceptions Compensations vs. or an offline . 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. In this overview. It explains the types of failure that can occur. Examples would include a downed network. • Transient exceptions These are temporary situations that may resolve themselves over time. such technical failures cannot be handled. 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. CPU errors.Working with Failure and Exceptions This section shows you how to design around potential failures and exceptions using transactions. and provides illustrative use cases. and typically result in interrupting the process execution (until the failure is addressed externally). exception handlers. By their nature. Examples of technical failures include disk malfunction. an unavailable Web service. mechanisms for dealing with failure and exceptions.

In the event of transient. Transactions group a sequence of tasks into an indivisible unit in which either ALL tasks execute or NONE execute. If the retries are unsuccessful. • Business exceptions Business exceptions are typically data-related: the account number may not be recognized or there or insufficient funds for the intended transactions. as described in Working with Sub-Processes. All three mechanisms are further described below. If a task within a transaction fails. see Creating 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.Sub-process as transaction . sub-processes are used to join the transaction activities together.database. NOTE: Transactionality limits the interaction of tasks in the transaction to XA-compliant participants. then retry the action for specified number of times. never occurred. so this is for future reference only. and then the process can be resumed manually once the problem has been addressed. the process will rollback any activities as necessary. Transactions NOTE: Transactions are not fully functional in the current version. In a process diagram. Figure 1 . meaning that the actions are not committed and in effect. the process is then suspended (but not terminated). and triggering compensatory actions to undo completed transactions. In this case process will be suspended after a number of failed attempts. For more information. providing alternative flows when exceptions occur. such as databases and JMS services. all preceding tasks that have already executed are automatically rolled back.

the handler may simply notify the user of the encountered condition and terminate the process. For example. Figure 2 . For example. 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. Exception Handlers.Exception Handlers Exception handlers redirect the process flow when an exception is detected.Exception handler for a sub-process . an appropriate exception may be raised and an alterative flow is followed. For more information. As a result. a task may attempt to debit an account but the account lacks sufficient funds. see Compensations vs. NOTE: Using an exception handler precludes compensations for previously completed tasks. In a process diagram.

a Task C fails. Subsequently. Figure 3 . Exception Handlers. Task A receives payment for services provided and completes. For example. however. 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. NOTE: Compensations are not executed if the failing task is assigned an exception handler. see Compensations vs. The compensation associated with Task A executes activities that refunds the payment. so this is for future reference only.Compensations NOTE: Compensations are not fully functional in the current version.Compensation activities for a completed transaction . Compensations define a process flow that undoes a completed action if a later task fails. For more information.

. No Compensation In this use case: 1. However. 2. Exception Handlers If an activity fails and raises an exception. The following use cases use the same process diagram to illustrate the how exception handlers and compensations are triggered: • • • • No Exception Handling. It may simply send a failure notification and terminate the process. Task A executes and completes.Compensations vs. 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 presence of an exception handler provides an alternate flow that prevents the process from failing by indicating an alternative flow of control. No Compensation Exception Handler Triggered Compensations Triggered Order of Compensations No Exception Handling. Task B fails due to a business exception.

Task Z fails due to a business exception. NOTE: Trans_AB is unaffected by the failure. no compensation Exception Handler Triggered In this use case: 1. Figure 5 . triggering exception handling activities contained in ExHandler_YZ. Figure 4 . Trans_AB executes and completes. 5.3. no compensation is triggered because it is precluded by the exception handler attached to Trans_YZ. The process fails because no exception handling has been configured for the Trans_AB sub-process. Task Y in Trans_YZ executes and completes. 3. 4. 2.No exception handling.Exception handler triggered . The Error event attached to Trans_YZ executes. Task 43 executes and the process flow continues toward completion.

5. 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. 3. 4. triggering the compensatory activities contained in YZ_Comp. Trans_AB executes and completes. The Compensation event attached to Trans_YZ executes. The Compensation event attached to Trans_AB executes. Task 43 fails due to a business exception. Trans_YZ executes and completes. 2.Compensations triggered . Figure 6 .Compensations Triggered In this use case: 1.

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. the process fails.Multi-level exception handling Order of Compensations .At this point. Figure 7 . even though the actions have been compensated.

the compensating activities for the Nested 2 sub-process execute prior to the compensating activities for the Nested 2 subprocess.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. . Figure 8 . If a task within a transaction fails.If a process flow contains multiple sub-processes with configured compensations. As shown below. the compensations execute in reverse order. all preceding tasks that have already executed are automatically rolled back.

The Basic Shapes tab pane contains two pre-configured sub-process activities. Roll-back means the completed activities are undone: it is as if they never took place. see Compensations. For more information. Open the Palette panel and select the Basic Shapes tab. However. or the Intalio Internal connector. Compensation reverses actions executed in completed transactions.To be truly transactional. These activities differ only by their contents.XA-compliant exchanges in a transaction NOTE: Roll-back is NOT compensation.htm). see http://www. Figure 9 . For example. the seat reservation is rolled back. Otherwise roll-back is not possible and the activity will not behave transactionally. they share the same sub-process properties. To create a sub-process for a transaction: 1. a transaction contains a sequence of two activities. namely JDBC. Drag-and-drop a sub-process activity onto the desired pool in the process diagram. if the credit card payment fails.opengroup. 2. JMS. The first activity communicates with an XA-compliant booking database to reserve a seat assignment. the second activity processes a credit card payment. Using a Sub-Process Task Transactions are designed as sub-processes with specific property settings.org/bookstore/catalog/c193. . any communication with other participants must conform to the XA (transaction authority.

the activities of that activity will be displayed instead. Ensure that communications with activities outside the transaction use XAcomplaint transports. Design the transaction activities by modifying the contents of the sub-process. 4. To set the transaction properties: 1.Creating a transaction sub-process 3. Figure 11 . 2. as described in Understanding XA-Compliance and Rollback. you can select them and use the Group tool to transform them into a sub-process. Setting Transaction Properties After the sub-process activity has been added to the process diagram you can configure the properties to make it transactional. select the sub-process by clicking its outermost edge. If the activity (or sequence of activities) intended for the transaction is already in the process diagram. You can now set the transaction properties. Open the Properties panel. If you accidentally select any activity in the sub-process.Transactional sub-Process properties . as described in the next section. In the process diagram. When properly selected the outer edge displays as red.Figure 10 .

For example. but they do not handle the exception that may have necessitated the compensations in the first place. compensating activities may undo the actions performed by completed transactions. o Transactional .Specify the maximum number of retries to be attempted if the transaction fails. By nesting the transactions in a sub-process. o Retry count .3. a value of 0 (the default) will invoke the transaction only once. For example. described in the next section. NOTE: For more information about sub-process/transaction properties in general. you can nest transactions within sub-processes. Set the properties as follows: o Label (optional) .Enter the name of the transaction as it should appear in the process diagram. as shown below: Figure 12 .This property must be set to True. as the transaction properties. however. see Sub-Process Properties. You can now design compensations for later tasks. Nesting Sub-Processes To make full use of exception handlers and compensating activities. if it fails.Transactional sub-Process properties . no retry will be attempted. you gain a new level at which you can handle the exception.

as described in Setting Transaction Properties. . the exception handler for the AB_YZ_Wrapper sub-process enables the process execution to continue toward completion. The selected transaction (and other activities) will be nested inside the newly created sub-process. 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 failure of Task 43 would trigger the compensations for Trans_YZ and Trans_AB (in that order). OR • Drag and drop a sub-process shape from the Palette into an existing sub-process and design the transaction activities as desired. but you cannot nest a transaction within a transaction.In this example. you can nest a transaction in a sub-process. be sure to set the transaction sub-process properties correctly. NOTE: You can nest sub-processes within a transaction. but instead of the process failing at that point. NOTE: In either case.

Figure 13 .) Figure 14 . (The throws and catches have been color-coded for easy visual association. 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.Correlated throw and catch errors . When an exception is thrown.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. For example. the process looks for a matching catch to direct the process flow to the correct exception handler. the following illustration shows a transaction in which a credit card payment is processed through a database.

As implied above. the process flow is directed to the No Funds Error event. If the payment is rejected for another reason for which no throw has been defined. which catches the error and activates the Handle No Funds exception handler. the process flow continues through the Payment Validated activity and the process execution continues toward normal completion.After the payment information is returned by the database. which catches the error and activates the Handle Invalid CC exception handler. If the credit card number evaluates as invalid. the process flow enters a databased gateway that evaluates the data for proper validation: • • • • If the credit card information was validated. the throw and the catch are correlated by matching properties. If the funds available value evaluates as invalid. as described in the following section. the Other Error event catches it and activates the Handle Other exception handler. the process flow is directed to the Invalid CC Error event. Configuring Exception Handlers . however.

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. For more information about creating sub-processes.To create an exception handler: 1. 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. drag-and-drop the Error event onto the bottom edge of the sub-process shape in the process diagram. see Creating a Sub-Process. o Select the event and open the Properties panel. Value of Retry Delay is set to a reasonable time delay (specified in seconds) Retry Delay between retries. 3. Define Sub-process: o Select the Sub-process and open the Properties panel.The variable needs to get selected Throw<Variable> from the option of values. The Error event will attach to the sub-process. Define the throw Error event: o Drag-and-drop the Error event into the process flow at the desired point. 2. if you want the activity to throw a Failure fault on failure. o Apply values for the three elements. The panel lists additional element: Element Description Catch The value for this field is retrieved from throw variable or can invoke the value . 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. Create a sub-process that contains the activity or sequence of activities for which you wish to handle an exception. By default its is set to (No variable selected) o Apply values for the three elements. o Select the event and open the Properties panel. Open the Palette panel and select the Intermediate Events tab pane. 6. Define the catch Error event: o From the Palette panel. 4. 5.

The variable needs to get selected from the option of values. You can now design the activities that will handle the exception. Figure 15 . This sub-process comprises the exception handler. They are linked to the sub-process/transaction to be compensated via the Compensation event and a compensation flow connector. correlated throw and catch Error events. you can create multiple.that is directly sent by a webservice. Independent of any process flow. Designing Compensations NOTE: Compensations are not fully functional in the current version. so this is for future reference only. 8.Error event attached to a sub-process o o As indicated in Correlated throw and catch errors. design a sub-process that contains the activities to be executed if one of the sub-process tasks fails to execute. By default its is set to (invoke fault:null) Apply values for the three elements 7. . Compensations are designed the same as any sequence of events. 9. Draw a flow connector from the Error event to the exception handler sub-process.

To compensate for completed sub-processes/ transactions: 1. and only if there is no exception handler assigned to the failing event. 3. Identify the sub-process/transaction that needs to be compensated.Attached compensation event . Figure 17 . Release the mouse.NOTE: As described in Compensations. 2. From the Intermediate Events tab pane. The event attaches itself to the left side of the bottom edge of the transaction subprocess.Add compensation event 4. Open the Palette panel and select the Intermediate Events tab. Figure 16 . compensation events execute only when a subsequent event fails. drag a Compensation event onto the bottom edge of the transaction.

the compensating activities cannot be placed in an alternative lane. Select the Sequence Flow Mode option. For conservation of space. you may wish to encapsulate the compensating activities in a sub-process. The compensating activities must be contained within the same "wrapper. Draw a flow connector from the Compensation event to the compensating activity. 8. For more information. click on the down arrow next to the Connector tool icon. NOTE: If the sub-process/transaction is wrapped in another subprocess/transaction. By default. which is unique to this context.Connecting transaction to compensating activities .5." 6. Figure 18 . 7. 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. this creates a compensation flow connector. On the toolbar. see Flow Connector Properties.

Sign up to vote on this title
UsefulNot useful