The Javadocs for TransitionInstance say that these are used to represent asynchronous continuations. However, for a multi-instance activity, where 1 out of 3 instances have completed, the completed instances are represented as transition instances, e.g.
└── Process:1:3=>7
└── userTask#multiInstanceBody=>userTask#multiInstanceBody:10
├── transition to/from userTask:17
├── userTask=>userTask:28
└── userTask=>userTask:30
This is bad, because:
- cancelling this instance via modification makes no sense (yet the API is there to cancel transition instances)
- it is not possible to differentiate whether the transition instance is actually completed or not yet completed but async after the inner activity
This is not easy to fix, because:
- in the database, the two scenarios cannot be easily distinguished. The Execution#isEnded flag could be used, but is not persisted.
Side note:
- this is related to the joining behavior of parallel multi-instance, i.e. the question how we distinguish whether all instances are complete or some are still async after the inner activity. The answer in this case is considering the loop variables for joining the instances. While this answers the question whether there are any async after transition instances (and vice versa, completed inner instances), it cannot tell us which is which.
This is the controller panel for Smart Panels app
- is related to
-
CAM-5373 I can migrate process instances with multi-instance
-
- Closed
-