Support multi-instance embedded variables

[lzgabel]

As required by the specification, each parent execution of the created executions for each instance will have the following variables:

• nrOfInstances: the total number of instances

• nrOfActiveInstances: the number of currently active, i.e. not yet finished, instances. For a sequential multi-instance, this will always be 1.

• nrOfCompletedInstances: the number of already completed instances.

See also the usage in Camunda 7 here: https://docs.camunda.org/manual/7.13/reference/bpmn20/tasks/task-markers/#multiple-instance

blocked by #8321

[korthout]

These variables are not required by the specification, but they are available in Camunda 7. They make completionCondition more powerful, and can could also be used in other expressions.

We could consider using the same approach, but I see 1 downside to it: introducing these local variables to the local scope of the instances of a multi-instance activity can break existing processes of users if they are already using the variables in their processes. For example, these new local variables could hide existing variables at higher scopes. Although it's not likely that many users will be effected by this.

We can also consider exploring alternative solutions, for example adding FEEL-extension functions to Zeebe that provide values for these properties.

EDIT: I striked-through some lines, as @lzgabel pointed out, the spec is clear that these are variables (i.e. attributes) that exist for each instance of the multi-instance activity.

[lzgabel]

These variables are not required by the specification, but they are available in Camunda 7. They make completionCondition more powerful, and can could also be used in other expressions.

Hi @korthout, as we can see from page #224, the variables of multi-instances are defined in the bpmn specification.

[korthout]

😅 Oops I totally missed that! Thanks for pointing it out. 💯

[lzgabel]

duplicate of #2893

[korthout]

Well spotted @lzgabel. Let's close this in favor of #2893.