Question about Canceling a Task in a Multibody Instance

Camunda 7 Topics Discussion & Questions
1

Hello, we are running into an invalid state when using a multibody instance wrapper around a task that is to be performed by each user.

In particular, our setup is that each recipient will enter a subprocess. Inside of this subprocess, the user must complete a task by doing a user-related task in our application. Once the task is completed, the sub-process for that recipient is moved into an end-of-process state.

Additionally, we allow the initiator of the task to cancel an individual assignee’s sub-task, for the task might no longer be valid for that individual recipient.

To do this, we tried leveraging the cancel task process instance modification for an individual recipient. This typically seems to handle the canceling of the task in an effective manner, however there is one bug with this: if the last recipient is canceled, the multibody instance never completes.

To summarize, let’s assume we have two recipients, A and B.
If A completes the task, and then B completes the task, then the multibody instance step is completed and it moves on.
If A cancels the task, and then B completes the task, the multibody instance step is also completed and it moves on.
If A cancels the task, and then B cancels the task, then the entire process instance is marked as canceled.
Lastly (the bug), if A completes the task and then B cancels the task, the process instance is left in an invalid state, and the Camunda cockpit shows as the multibody instance as being active, even though there are no more recipients.

How can I go about correcting this state? Also, I’m using the rest api for this, but I’m comfortable using it and just need an overview of what we should do in this situation. I’m sure the answer involves using the process instance modify command, but I’m not quite sure how.

Thanks for your help!

BPMN Diagram:

image
image297Ă—548 3.14 KB

2

Hi @jamespedid,

in your use case, you should not use the process instance modification. If the canceling of a task is a part of your regular process (as it seems) then you should model this behavior in the process. For example, you can add an interrupting message boundary event to the task which is triggered when you want to cancel the task.

Use cases for modification are

  • Repairing process instances in which some steps have to be repeated or skipped
  • Migrating process instances from one version of a process definition to another
  • Testing: Activities can be skipped or repeated for isolated testing of individual process segments

Does this help you?

Best regards,
Philipp

2 Likes
3

Hi
I have the same problem. I need to cancel/skip one user task in a Multi-Instance User Task (MIUT)

I tried 2 variants

  1. Trigger Execution to explicitly skip user task
    I send “POST engine-rest/execution/{id}/signal” but triggered task still remains in the task list, which looks like it’s still active

  2. Added Interrupting Message boundary event to my MIUT

First to get the execution id I used “POST /execution”

  • next request body:
    {
    “processInstanceId”: {id},
    “messageEventSubscriptionName”:{messageName}
    }

The problem is that the response contains id which represents a common execution id for all MIUT
So if I send
“POST /execution/{id}/messageSubscriptions/{messageName}/trigger”
then all of the Message boundry events of MIUT are triggered, while I need only one.

Is there any REST command which can trigger one concrete Message boundry event of MIUT ?

4