With repeating tasks (symbol *|||*) there are situations, where you want to restrict the number of task instances being "active" (or "not in a terminal status") at a given time.

Attached is a CMMN model example:
Whenever the entry Sentry is satisfied (e.g. data "Grundstücke" is updated) the model creates a new instance of task "Objektbewertung". Without a restriction every data change triggers the creation of a new task instance, which in this case you want to restrict.
The idea here is to have exactly one task which handles all last changes on the referenced data "Grundstücke".

Solution 1:
Would there be the need for an additional attribute like "multiplicity" (on repeating tasks only?), set to "exactlyOne" or similar, to implement the desired behaviour. (One can think of more complex restriction / settings here, but we leave it to that for now.)

Solution 2:
Or can this be handled in the RepetitionRule of "Objektbewertung" itself: with Introspection in the runtime model --> get "active" instances of task "Objektbewertung" and depending on that --> RepetitionRule evaluates to true or false --> control if further instances can be created

Harald

Re-evaluating the repetition rule every time the entry criteria of a repeating Task, Stage, or Milestone is satisfied

This proposal is to re-evaluate the repetition rule every time the entry criteria of a repeating Task, Stage, or Milestone is satisfied. This will allow people to control both the number of repetitions (by having a counter) and concurrent repetitions (by introspection of the runtime for concurrent instances – assuming implementers provide a way to do so). In both cases, race conditions can occur, and implementers must provide a way to deal with them (a potential implementation may want to serialized the evaluation of repetition rules).
Note that in this proposal several statements mix repetition rule and required rules. To avoid mixing proposals, the sentences with required rule were treated as if issue 23 and proposal 52 does not exist.

Relevant paragraphs in the specification:

Section 5.4.11.3 RepetitionRule, page 42. Add a third statement as follows as follows:

A RepetitionRule specifies under which conditions Tasks, Stages, and Milestones will have repetitions. Each repetition is a new instance of it. The first instantiation is not considered a repetition. The trigger for the repetition is a Sentry, that is referenced as entry criterion, being satisfied, whereby an OnPart of that Sentry occurs. For example: A Task might be repeated each time a certain document is created. The Task (as PlanItem) might have an entry criterion, referring to a Sentry, having on OnPart, whereby the onPart refers to the CaseFileItem that represents the type of document, and whereby the standardEvent of the OnPart is specified as “create.” When the RepetitionRule as contained in the PlanItemControl of the Task (as PlanItem) also evaluates to “true,” the Task is repeated upon creation of the document.

Section 5.4.11.3 RepetitionRule, Table 5.42 - RepetitionRule attributes, cell (2,4) condition : Expression[1], page 43, second paragraph. Reads:

An Expression that MUST evaluate to boolean. If the Expression evaluates to “true,” then the instance of the Task, Stage, or Milestone maybe repeated, otherwise it MUST NOT be repeated.

Leave alone.

Section 7.4.2 Stage and Task Lifecycle, Table 7.8 - Stage and Task instance transitions, cell (4, 2), page 72. The sentence that reads:

The RepetitionRule and the RequiredRule Boolean expressions MUST be evaluated in this transition, and its Boolean values SHOULD be maintained for the rest of the life of the Stage or Task instance.

Change as follows:

The RepetitionRule Boolean expression MUST be evaluated in this transition. and t The RequiredRule Boolean expression s MUST be evaluated in this transition, and their Boolean value s SHOULD be maintained for the rest of the life of the Stage or Task instance.

Section 7.4.3 EventListener and Milestone Lifecycle, Table 7.11 - EventListener and Milestone instance transitions, cell (4,2), page 77. The sentence that reads:

For a Milestone instance, the RepetitionRule and RequiredRule Boolean expression MUST be evaluated in this transition, and its Boolean value SHOULD be maintained for the rest of the life of the Milestone instance.

Change as follows:

For a Milestone instance, the RepetitionRule Boolean expression MUST be evaluated in this transition. and For a Milestone instance, RequiredRule Boolean expression MUST be evaluated in this transition, and their Boolean value SHOULD be maintained for the rest of the life of the Milestone instance.

Section 7.6.4 RepetitionRule, page 79. Reads:

This rule MUST be evaluated when the Milestone, Stage, or Task instance is instantiated and transitions to the Available state, and their Boolean value SHOULD be maintained for the rest of the life of the Milestone, Stage, or Task instance.

Stage and Task instances with a RepetitionRule evaluating to “true” will create an instance every time an entry criterion with an onPart is satisfied. Under that condition a new instance is created and because the entry criteria is satisfied it moves from the Available state to either Active or Enabled state depending on the ManualActivationRule.

Change as follows:

This rule MUST be evaluated when the Milestone, Stage, or Task instance is instantiated and transitions to the Available state , and their Boolean value SHOULD be maintained for the rest of the life of the Milestone, Stage, or Task instance . The first time, a Milestone, Stage, or Task instance is instantiated and transitions to the Available state, it is not considered a repetition, nevertheless the RepetitionRule MUST be evaluated and its result discarded.

Stage and Task instances with a RepetitionRule evaluating to “true” will create , will try to create an a new instance every time an entry criterion with an onPart is satisfied. Under that condition the RepetitionRule is re-evaluated and if the Expression evaluates to “true,” then a new instance is created and because the entry criteria is satisfied it moves from the Available state to either Active or Enabled state depending on the ManualActivationRule.