Process instances continue before CMMN call activities are closed?

Camunda 7 Topics Discussion & Questions
1

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?

Edit:

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?

Edit 2:

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):

  • Completed
    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.
  • Closed
    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?

2

Hi @bentrm,

Since the BPMN Spec does not say anything about cases, we decided to implement the (Case) Call Activity in the way it is done for the Case Task in CMMN. Therefore the CMMN Spec says, that when a called case (by a Case Task) is completed, then the corresponding Case Task is also completed (see ch 5.4.10.6 in CMMN 1.1 Spec).

If you want to have a guard against further modifications then you can add a case execution listener which closes the case instance when the case instance gets completed.

Cheers,
Roman

3

@roman.smirnov, thanks for your pointer and the tip how to implement this. That’s a comprehensible decision.

To some degree, I still think this may be a bad decision for a callActivity as well as a caseTask though and could be caused by the overloaded meaning of the word “completed” in the CMMN spec (I’m no expert on this so please bare with me):

For the “Closed” state its noted

This state is only available for the outermost Stage instance implementing the Case’s casePlanModel.

This makes sense as it’s my understanding that nested stages will be considered closed and immutable after the outermost stage has been closed.

In the source you provided I found:

When a CaseTask is “blocking” (isBlocking is “true”), the CaseTask is waiting until the Case associated with the CaseTask is completed.

This is where I think the meaning of “completed” becomes blurry, as the spec only describes “Completed” and “Closed” in the light of the contextual lifecycle state of a case instance.

Further it is written:

The difference between using a CaseTask and a Stage is that a CaseTask calls a Case that has its own context, i.e., it is based on its own CaseFile, whereas a Stage represents behavior that shares the same context with the Stage, i.e., it is based on the same CaseFile and is “embedded” in the same Case.

This could mean, that the contextual information of a case being in the “Completed” state shouldn’t be available to the calling task, or at least shouldn’t render the called case “complete” from an outside perspective. Only after the case has become “Closed” and therefore read-only the blocking caseTask (or callActivity) should be completed as well.

Also, I noticed how the spec uses uppercase letters to designate the state “Completed” while using “completed” to describe the perception that the case has actually been completed. (Sorry, nitpicking.)

Well, yadda yadda, I really think this is an oversight that should be considered for the execution logic of callActivities as well as caseTasks. I hope I was able to describe what I actually mean. :worried:

4

@roman.smirnov, do you think I should file a ticket describing my concerns or are these false expectations to begin with? I understand that this is the way it is implemented and doesn’t really describe a bug, but I think it should be discussed?

5

Hi @bentrm,

You are always free to open a ticket :wink:

IMHO I would still stick to the current behavior, since the BPMN specification does not specify this case and as I already said it is aligned with the behavior of Case Tasks in CMMN.

Furthermore, it is currently not possible to “re-activate” a completed case instance by using the Java/REST Api. So, at the moment further modifications cannot happen after case instance completion.
Even if it would be possible to “re-activate” a completed case instance, what would that mean? According to the CMMN specification it means that discretionary items can be planned and added to the case plan model. But the engine does not support discretionary items, so when the case instance would be re-activated, then there are not tasks which can be executed to modify variables.

Cheers,
Roman

6

@roman.smirnov, thanks for your input, I filed this as CAM-6759.

7