Due Transitions
A due transition can be specified for 'leaf' activities as well as for 'group' activities.
A group can have a due transition that applies to the instance in any activity within the group. In such case, due time will begin running as soon as the instance arrives at the first activity within the group (entry point).
To define which calendar rule to apply, the engine looks for the organizational unit where the process of the instance being executed has been deployed. If no calendar rule is defined for the organizational unit, the engine keeps looking in the upper levels of the organizational hierarchy until it finds a calendar rule to apply. If no calendar rule is found, it is assumed that all days are working days. The Engine will also take into account the calendar rule set for the organizational unit where the process is deployed and the activity role where the instance is running. The calendar rule set at role level is first evaluated by the Engine and overrides rules defined for the organizational unit, if any are defined. Refer to Calendar Rules for further information.
Group due transitions override any single activity's (within the group) due transition. If a group has a due transition and it exists inside another group that has a due transition, the instance is ruled by the outermost group's due transition if both transitions expire at the same time. For example, between an activity due transition and the group that contains the activity, due transition, the instance will be routed according to the group due transition
- The task timeout interval (defined as an engine property),
- PBL-Method timeout interval that is currently being executed (i.e., the PBL-Method that is being executed within the list of PBL-Methods that might be connected with relay-to),
- The activity due transition interval,
- Each nesting group due transition (if there are multiple nested groups, all due transition are evaluated),
- The process deadline.
Compensate Transitions
Each leaf activity can have its own compensate flow. In addition, the group can also have its own compensate flow. The group's compensate transition can send the instance to a leaf activity or to a group activity that will perform any necessary action to compensate the situation. This group represents the compensate flow.
Within the group's compensate flow, you might not reference a specific inner compensation (compensation defined in some inner activity). Therefore, the engine will call all the compensations defined in the group in the inverted order in which they are executed. If it has reference to an inner compensation, the engine will call only this compensation.
In the following figure, Group 1 is an inner group of Group2. Moreover, Group1 has
activities act1, act3 and act5 within
it.
- If act1 needs to be compensated, the CompensateAct1 activity will be executed.
- If act3 needs to be compensated, as there is no compensate transition going out of this activity, no compensation is performed.
- If no compensate transition is defined for a Group, then all inner activities compensations are performed. They are performed in reverse order of the process flow. In the example, if there were no compensate transition for Group2, inner compensations are executed: CompAct2 and then CompensateGroup1 in this order.
A group can also be defined by grouping activities inside the compensate flow or exception flow. In this case, no exit point for the group will exist. See Compensate Transition.
Exception Transitions
Groups can call and manage their own exception flow. See Exception Transition for more information.