Exit Criterion
Introduction
Exit criteria are used to control when a plan item is terminated/exited. Once their condition evaluates to true, the plan item they are attached to is terminated/exited. Plan items can connect to Exit Criteria to make their evaluation dependent on another plan items state transitions.
Properties
General
| Attribute | Type | Description | Category |
|---|---|---|---|
| Model Id | Text | Model Id identifies the element within the process model. | The model id, name and documentation properties can be found on any element. They are used respectively to uniquely identity the sentry, to give the gateway a user-friendly name and to add a free-form description. |
| Name | Text | The name of the element. This is the name displayed in the diagram. | |
| Documentation | Multiline Text | The documentation attribute additionally adds a description to the component. | |
| Condition | Text | A back-end expression (${..} syntax) resolving to a Boolean value. A missing expression resolves to true. The evaluation context is the plan item which also gives access to all case variables. | An exit-sentry on a plan item is used to either terminate (exit) or complete it. If connected to another element with a connector, it will be triggered once the specified event is fired by the connected element (e.g. occur on a listener or complete on a plan item). If connected to more than one element (AND semantics), all of the events need to trigger in order for the sentry to be satisfied, which is normally only possible with the event deferred triggering semantics. If there are more than one exit-sentry on the same plan item, any one of them can fire in order to end the plan item (OR semantics). Optionally to the connector, an exit-sentry can additionally have a condition which is evaluated to enable the sentry. Evaluation depends on the trigger mode: if on event is specified, the condition is evaluated whenever the event happens and if evaluating to false, that event is lost and the sentry will not be triggered. If the trigger mode event deferred is set, the sentry will have a 'memory'. Whenever an on-part is triggered, it is saved. The same for a condition becoming true at any given evaluation cycle. As soon as all on-parts have been triggered and the condition was evaluated to true at least once, the sentry is satisfied. |
| Trigger mode | Selection:
| Defines the sentry's trigger semantics. The setting here is only relevant for sentries that are connected to other model elements (sentries with one or more 'on-parts'). 'On event' - the sentry will only 'fire' if one or more of the on-part elements undergo the desired transition as part of the current model evaluation cycle. If the sentry has a condition, and the condition evaluates to false, the sentry won't trigger and any transition event will be lost. 'Event deferred' - the sentry is evaluated against any on-part element's last transition. If there is a transition and a false sentry condition, the sentry does not trigger. If the condition turns to true at a later point in time, the sentry will fire based on the state of any relevant on-part element's last transition. |
Advanced
| Attribute | Type | Description | Category |
|---|---|---|---|
| Exit type | Selection:
| Exit type for this exit sentry. | The Exit type can be used for exit sentries on plan items, not stages or the case plan model though, and helps define how to exit the plan item. It particularly makes sense in combination with repetition. A possible use case might be that you want to terminate active instances of a repetitive plan item, but maybe later on it becomes available again as the conditions change in the case. With the exit type other than the default, this is possible as the plan item is not terminated for good, but only active or active and enabled instances. The Exit event type can be used for exit sentries on stages or the case plan model as it offers an alternative exit than default terminate semantics. The Exit event type can be used to follow the complete or force complete semantics. When selecting complete, the sentry can only be triggered in a state where auto-complete would actually complete as well, meaning there is no more active plan item to be completed first and no required ones are left. If the sentry is triggered, an exception will be thrown if this is not the case. If the state of child elements is irrelevant, force complete can be selected. It has similar semantics as the default, but in the audit history the plan item or stage will be marked as being completed, which often has a different business meaning than termination. |
| Exit event type | Selection:
| Exit event type for this exit sentry. |