The Control Flow determines the flow of tokens through tasks and conditions.
The process life cycle of control flow in Infinity includes the following elements:
Start events instantiate the process. They can be determined to start a process automatically or allow an external event to initiate the process start. There are several types of start events enabling the process start by different resources, e.g. a performer, an incoming mail, a point in time or specific messages, depending on the modeler you choose. In order to be executed, each process needs at least one trigger, or otherwise needs to be used as a sub-process or by an event.
In the Eclipse modeler, start events are defined as automatic start event or as triggers. Refer to chapter Working with Triggers for details on the provided trigger types and how to use them.
For details on using start events in the Modeling perspective, refer to section Adding Start Events in chapter Events - Introduction of the Business Process Modeling Handbook.
End events describe how a process ends.
The Eclipse Modeler provides a simple End Event only.
End events in the Modeling perspective can be defined as message event or simple end event.
For details on using end events in the Modeling perspective, refer to section Adding End Event in chapter Events - Introduction of the Business Process Modeling Handbook.
Control flow between activities at runtime is determined by transitions. A transition or sequence flow connects at least two activities.
At runtime, after the source activity instance is completed the transition is instantiated and, if available, a transition condition is evaluated (see below). If the condition evaluates to true the subsequent activity instance(s) is(are) instantiated.
Transition conditions are specified if the successor activity is to be performed under particular circumstances only. If a transition condition is set to true, the transition will always be traversed and the successor activity executed.
Refer to chapters Working with Transitions and Working with Sequence Flows for details on setting transition conditions in the Eclipse modeler and the Portal Modeling perspective accordingly.
A transition in the Eclipse modeler is rendered as a blue line with an arrow indicating the transition direction.
Refer to chapter Working with Transitions for details on using transitions in the Eclipse modeler.
A sequence flow in the Modeling perspective is rendered as a gray line with an arrow indicating the transition direction.
Refer to chapter Working with Sequence Flows for details on using sequence flow in the Modeling perspective.
Gateways are used to control sequence flow. Diamond-shaped rectangles represent these gateways. Gateways controlling outgoing sequence flow are called splits. They are modeling constructs for choices or parallel activities. Gateways controlling ingoing sequence flow are called joins. These are modeling constructs to merge parallel parts of the flow.
Refer to chapters Specifying Activity Control Flow and Working with Gateways for details on working with gateways in the Eclipse modeler and Portal Modeling perspective accordingly.
A process instance is completed when all activity instances are completed and no new activity instances can be created. This is called implicit process completion.
See also the section Start Events for more details on triggering a process.
Splits are opening connectors. They determine the splitting behavior after a task.
The following variants exist for splits:
|Split Type||Icon in the Eclipse Modeler||Icon in the Portal Modeling perspective|
Refer to section Modes of Split and Join Handling for details on the different handling variants of splits.
Joins are closing connectors. They determine the joining behavior before a task.
The following variants exist for joins:
|Join Type||Icon in the Eclipse Modeler||Icon in the Portal Modeling Perspective|
Refer to section Modes of Split and Join Handling for details on the different handling variants of joins.
The following modes of split and join handling are provided in a Infinity control flow:
An XOR-split indicates a decision point where only the first transition is instantiated that condition evaluates to true. In the Eclipse modeler, the evaluation order corresponds to the order of transitions listed in the XOR split properties.
After the gateway exactly one activity thread is performed. You should make sure that always at least one transition evaluates to true, e.g. by providing an alternative default flow. If no condition evaluates to true, this default flow will be taken.
Suppose a document should be sent to a customer. It should be decided if it will be send via fax or e-mail. If none of these options is possible, an alternative way of providing the document should be found.
Assume the sequence flow to the activity to send via fax internally has a higher order than the sequence flow to the activity to send via Email. If an employee gets the document and decides to send it via fax and another decision is taken to send it via E-mail, the document gets sent via fax and the sequence flow to send via Email is ignored.
Figure: XOR Split usage example
An XOR-join waits and instantiates a new join activity instance for each active incoming transition. If XOR joins are combined with split types other than XOR, multiple incoming transitions may be instantiated at runtime.
If not the alternative flow was taken, exactly one of the send options has been taken and performed. The XOR join waits until one of the activities has been completed and then proceeds with the workflow.
Figure: XOR Join usage example
An AND split indicates the start of a parallel workflow processing. Usually AND splits are used for unconditional parallel flow. All outgoing transitions get activated simultaneausly and are processed in parallel threads. Each outgoing transition is instantiated exactly once.
If you like to prepare a meal with salad and meat, you have to prepare the salad as well as to fry the meat. This could be done in parallel threads.
Figure: AND Split usage example
AND joins require tokens in all the conditions preceding the AND join to enable the execution of the subsequent task. It waits for all incoming transitions before the join activity instance is instantiated.
An AND join will block indefinitely in the following cases:
Taking the example above for using AND splits. The intention is to prepare a meal with salad and meat. You have done both in parallel, prepared the salad and fried the meat. For example if the salad is prepared, but the meat not fried yet, you do not start dinner. Once both actions are done, you can eat the dinner.
Figure: AND Join usage example
OR splits in IPP are similar to AND splits, but using conditional sequence flow. Using an OR split you can have multiple outgoing conditional sequence flows. All outgoing sequence flow conditions will be evaluated. For the sequence flow conditions that evaluate to true the sequence flows are followed in concurrent execution.
Use OR splits if you want to perform one or more activities based on specific conditions. Create an alternative default sequence flow to follow for the case that none of the specified conditions of all sequence flows evaluate to true. If no condition evaluates to true and no default flow is available, the gateway blocks.
You like to prepare your dinner with salad and meat, but, if one of the ingredients is not present, you are also content to have dinner with only one of those. The conditions are to have meat and/or salad in your fridge.
Now the following possibilities arise:
Figure: OR Split usage example
OR joins used in IPP basically are equal to AND joins. They both wait for all incoming tokens to be evaluated.
If one condition evaluates to true this does not exclude the evaluation of the other conditions. All sequence flows which evaluate to true will be traversed by a token. All incoming sequence flow arriving at the inclusive gateway wait in the gateway until an execution has arrived for each of the incoming sequence flows that have a process token.
The join is instantiated when all active transitions have reached the OR join gateway. The possibility of incoming transitions that still arrive or not is dynamically recalculated at each activity processing step. This takes into account:
Let us look at the example above for using OR splits. The intention is to prepare dinner with salad and meat, or, if not present, only one of those. If at least one of the conditions that you have either salad or meat or both in the fridge, is fulfilled, you have either prepared salad or fried meat or done both. Thus, the following process is to eat dinner at home.
Figure: OR Join usage example
The following example demonstrates a use case where an XOR split is combined with an XOR join.
Similar to the XOR split and join example above, documents should be send via fax or mail. Altogether there are three alternatives, from which only one is taken:
Once one of the transition conditions to send via fax or via mail is evaluated to true, the according activity is performed. No further transitions need to be evaluated and the workflow continues with the activity after the XOR join.
Figure: Exclusive Alternative Example
To process several activities in parallel, you can use a combination of AND splits and joins.
An alternative to using several activities to be processed in parallel is to use multiple instance activities. Refer to chapter Using Multiple Instance Activities for details.
To send the documents mentioned in the example above via both options, fax and email, you can use an AND join and split combination. Both actions are done in parallel and the join gateway waits until both actions are completed before continuing with the subsequent activity to confirm the sending.
Figure: AND split and AND join example
Note that in case one of the activities fails, a locking conflict might occur at the join.
To process several activities in parallel, which are potential optional, you can use a combination of OR splits and joins.
An alternative to using several optional activities to be processed in parallel is to use multiple instance activities. Refer to chapter Using Multiple Instance Activities for details.
This example demonstrates a simple usage of an inclusive gateway. Similar to the example above documents should be sent, but in this example there is the option to send them either via fax, or e-mail or both.
In the first activity the user imports the forms and decides the type of sending. We use an OR-split to two following activities, one for sending via e-mail and one for sending via fax. The transitions to these activities have conditions to decide whether the according send type is selected by the user.
The last activity has an OR join to merge these activities.
To prevent a blocking of the workflow in case the user will not send the forms at all, we also create an alternative flow. For this we use the OTHERWISE condition to an alternative activity, which notifies that the forms were not sent.
Figure: Inclusive Gateway Usage Example
The possible execution types of the above business process are:
Special care should be taken when using parallel or AND gateways to avoid deadlocks. The following sections show some typical scenarios causing deadlocks.
Vicious circles, e.g. like the one in the following screenshot, can produce deadlocks. They are detected in the modeler as well as during deployment.
Figure: Vicious Circle Example
In the Eclipse modeler, a warning is indicated for the process containing the potential deadlock. You can view details in the Problems view.
Figure: Deadlock warning in the Problems view
During model deployment, a warning dialog opens to indicate a potential deadlock in the process definition between specific activities.
Figure: Deadlock warning during deployment
You should avoid to use nonmatching split and join gateways that can never terminate.
Combine an XOR split with an AND join. The sequence flow which evaluates to true and has the highest order is followed only, but the AND join still waits for all incoming tokens and thus cannot continue.
In the following example, even if both options to send per fax and to send per mail are chosen, only one of the sequence flows is traversed and we face a deadlock at the join gateway. The join gateway requires that all incoming sequence flows must be completed before continuing.
Figure: Nonmatching Split and Join Gateways
If an exception handling is added to an activity in an inclusive control flow, even in case an exception is thrown and the exception handler is activated, all sequence flows which evaluate to true are still performed and completed in parallel.
In our example for sending documents per fax or Email, we add the case that the fax progress fails. We add an exception handling to the activity for sending by fax. If we cannot send per fax, but additionally have chosen to send by Email, the documents are sent by Email and the exception handling for the failed fax (e.g. a notification) is also performed.
Figure: Exception flow in an inclusive flow