I’m trying to implement a custom aggregated logging of a process instance that nests CMMN-cases via call activities.
I wanted to listen to the called cases “close” event to capture some data when I noticed that the parent process instance actually continues execution after the case is completed but not necessarily closed (to be honest, I haven’t been aware of the distinction before).
Anyway, is this an expected behavior and if so, is it possible to close the called CMMN case after it has completed/has been terminated automatically?
This post describes the same misconception between the runtime state of the database that still holds open cases and the “user perceived state” that the case has actually completed and is therefore “closed”. Is this something that comes from the CMMN standards document or is it implementation specific to Camunda?
The documentation specifically states:
A call activity can also be used to create a new CMMN case instance as a subordinate of the corresponding process instance. The call activity completes as soon as the created case instance reaches the state COMPLETED for the first time.
But is this really a desired behavior as the runtime database will fill up with completed but unclosed cases quickly if there is no external listener defined that actually closes the case?
I think these observation only partly correlate to the post given above, anyway I find the current behavior around call activities suspicious which may be caused by my own misconception. Please allow me to add further thoughts:
The CMMN specification (ch. 7.2) states:
A Case instance is composed of information represented by a caseFileModel and behavior represented by a casePlanModel. In addition, there are roles that correspond to humans expected to participate in the Case.
When a Case instance is created, the caseFileModel, casePlanModel, and caseRoles are all initialized. The Stage instance implementing the casePlanModel starts executing in an Active state (see 7.3), and while the Case instance is not in Closed state the caseFileModel can be modified, planning can occur, and human participants can be assigned to roles.
And furthermore about the case instance lifecycle states (ch. 7.4):
Semi-terminal state for a Case instance, but terminal state for all other EventListener, Milestone, Stage, or Task instances. There is no activity (no behavior being executed) in the element. A Case instance could transition back to Active by engaging in planning at the outermost Stage instance implementing the Case’s casePlanModel.
Terminal state. There is no activity (no behavior being executed) in the Case instance, and further planning in the Case’s casePlanModel is not permitted. This state is only available for the outermost Stage instance implementing the Case’s casePlanModel.
This kind of makes me believe, the current implementation may be a problem as the outer process instance actually only listens for the case to reach a state that may change in the future after the process instance has continued?
In table 7.6 it says:
close- Transition by the system, an administrator, or Case worker (human) when no further work or modifications should be allowed for this Case.
Which would very well make it possible for the process engine to “close” the case after “completion” to guard against further modifications to the case instance after the parent process instance has continued?