Entry Criterion
Introduction
Entry criteria are used to control when a plan item is activated/enabled. Once their condition evaluates to true, the plan item they are attached to is enabled/activated. Plan items can connect to Entry 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 entry sentry is guarding its plan item (any task or even a stage) for being started automatically. 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 entry-sentry on the same plan item, either one of them can fire in order to activate the plan item (OR semantics). Optionally to the connector, a entry-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 activated. 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. |