collectionExpression in MultiInstance is evaluated multiple times

[deepti]

Hi,

Has anybody solved this issue : CAM-1650?

[thorben]

No, is not solved yet.
What is your concrete problem?
Please provide details.

[deepti]

Hi ,

I am integrating Camunda in our web application using the Rest API.Here are the details:

I am working on a process flow which requires multiple users to give their opinion on a particular matter
Example:
Is Global warming an issue ?
Answer :Yes/No/Can’t say.
Based on their response the subsequent flow is decided.

I have created a multi instance task for the above activity with a gateway attached to it to direct the flow based on the response received.

Using a script task I have defined the list of users who are going to work on this task.

The issue is there are duplicate tasks instances created for each of the user in the list.

Example if I have a list, users = [“John”, “Mary”,“Peter”] then there would be
3 instances of the task created for John.
3 instances of the task created for Mary.
3 instances of the task created for Peter.
When there should be actually 1 instance of the task created for each of the user in the list i.e. 1 instance for John, 1 instance for Mary and 1 instance for Peter.

I referred to the work around given in CAM-1650. This is my process definition after implementing the work around.

Can you tell me if there is a way to set the list of users using the Camunda Modeler UI. Instead of defining the list in a process variable in code.
As this “list” is likely to change and any code change is really some thing we would not like to do.

test1-multiuserapproval - Copy.bpmn (12.8 KB)

[thorben]

@deepti

The issue is there are duplicate tasks instances created for each of the user in the list.

Example if I have a list, users = [“John”, “Mary”,“Peter”] then there would be
3 instances of the task created for John.
3 instances of the task created for Mary.
3 instances of the task created for Peter.
When there should be actually 1 instance of the task created for each of the user in the list i.e. 1 instance for John, 1 instance for Mary and 1 instance for Peter.

The way you describe this, it does not sound like CAM-1650 to me. Even with CAM-1650 being present, if the list does not change, then there should be exactly three tasks, one per user. If you would like to follow-up on this, could you please publish an executable test case on github? You can use the unit testing template to get started quickly.

@deepti

Can you tell me if there is a way to set the list of users using the Camunda Modeler UI. Instead of defining the list in a process variable in code.
As this “list” is likely to change and any code change is really some thing we would not like to do.

Wouldn’t it be a better option to keep these users in an external database and query that database whenever the process is instantiated? That way you don’t have to change the model at all and you keep the user management in a single place where it belongs. A BPMN model is generally not a good place to manage users in.

[deepti]

Hi Throben,

Regarding issue #1 duplicate task instances created
This issue does not replicate now. I have the set the user list using a script task and it works fine.

Regarding your comment "BPMN model is generally not a good place to manage users " , could you please elaborate on this.
In our application we give the end user the freedom to modify the model as per his needs. Could you explain the draw backs of this approach?

[thorben]

Hi @deepti,

It sounded as if you were trying to model a user base in a BPMN file, which didn’t appear right to me. If this is actually fine for the people modelling BPMN in your case, then there is nothing wrong with that. In order to define a list of users via Camunda modeler, I see two ways:

1. Edit the script of a script tasks that sets the user list => requires scripting knowledge
2. Define an output parameter in the processon any other activity prior to the activity that accesses the list. In the modeler, you can choose the type List for output parameters.

Cheers,
Thorben