Multi-instance
Camunda
raf is a Camunda process variable as a collection
having elements. The multi-instance sequential 
sub-process owns the var. as input collection.
By means of FEEL, each raf element
is processed in sequence
For simulation purposes, a timer delays the processing of each element by 5 s.
Since 2 elements are included in raf,
the multi-instance sub-process is aborted (ABORT boundary timer event) after 7 s. Indeed,
2 * 5 s. > 7 s.
raf_after
is a Camunda process variable as
output collection of
the multi-instance sub-process. After deploying and instantiating the overall process, unfortunately,
raf_after isn't visible and thus accessible within
Operate console
Lesson learned: interrupting (boundary) events may let multi-instance sub-processes in unexpected?, even damaged?, state. Diagram on next slide IS NOT wrong on its own, but stakeholders must aware of side-effects on their model
Download Multi-instance-sequential.bpmn file
⤳ case study is based on FEEL
raf is a Camunda process variable as a collection
having elements. The multi-instance parallel 
sub-process owns the var. as input collection.
By means of FEEL, each raf element
is processed in parallel
For simulation purposes, a timer delays the processing of each element by 5 s.
However, whatever the number of elements included in raf,
the multi-instance sub-process is not aborted (ABORT boundary timer event) after 7 s. Indeed,
5 s. < 7 s., i.e., each element is processed in parallel
raf_after
is a Camunda process variable as
output collection of
the multi-instance sub-process. After deploying and instantiating the overall process,
raf_after (within
Operate console) includes elements, which maps to the processing of raf
initial elements
Lesson learned: interrupting (boundary) events may let multi-instance sub-processes in unexpected?, even damaged?, state. Diagram on next slide IS NOT wrong on its own, but stakeholders must aware of side-effects on their model
Download Multi-instance-parallel.bpmn file
⤳ case study is based on FEEL
