Incoherent behavior concerning call activities of suspended parent processes

I found the following feature request in JIRA that describes a method that suspends child instances while suspending a process instance. This hasn’t been implemented yet which isn’t so much of a problem. What is odd though, is the current behavior of child instances regarding user interaction.

For example, a case instance B initialized by a callActivity of a now suspended process instance A can be worked on but may not be completed. The following error is triggered:

Error while completing sub case of case execution 'CaseInstance[#...]'. 
Reason: 'ENGINE-03043 Execution with id '#...' is suspended.': 

I understand that this is caused by the suspension state of the parent process instance but the behavior isn’t coherent. If a user is able to work on the child instance, every step of the child’s lifecycle should be available. From a user perspective it’s unclear why the self-contained unit of work of B can’t be completed. The user may not even know that B is a nested execution of A.

Reactivating A should probably trigger a check if the underlying process/case instance B of the callActivity has completed while it has been suspended. That’s the moment A may continue marking the callActivity as complete.

Would you consider this a bug?

Edit:

I found the following open tickets related to suspending/activating case instances.

As CaseWorker I can suspend an active Stage, Task or CaseInstance (CAM-2461)
As CaseWorker I can resume a suspended Stage or Task (CAM-2462)

CAM-2462 describes the same desired behavior while resuming a case for caseTasks and processTasks as I was expecting in the context of a callActivity.

Edit 2:

I filed this as CAM-6758.

Hi @bentrm,

thank you for reporting the bug. This is an interesting but maybe not an easy topic.

IMO, I would prefer that the called instance is also suspended. Otherwise, you may run into problems when the call activity has an output mapping. The expected behavior may depend on the use case.

Best regards,
Philipp

From an implementors perspective it’s probably easier to just suspend all child activity of a suspended parent activity. Ideally though, I would prefer the functionality described in CAM-3337 to decide if suspension is to be propagated down the activity tree (ticket is only concerned with BPMN but I would relate this to CMMN as well). Output needs to be mapped after the parent continues and finds the child activity is already closed/ended.

Also, for CMMN there is no suspension functionality at this time (CAM-2461) so even the all or nothing approach might be tricky to implement.

1 Like