collection is the name of the process variable that you want to iterate over (e.g. a list with the values john, mary, peter is going to result in three tasks). If you use collection, the loopCardinality should not be defined
elementVariable is the name of the process variable the element will be assigned to (assuming you set this to assignee, then assignee will have the value john for the first instance, mary for the second instance, etc.)
camunda:assignee is the name of the assignee. It can also be an EL expression and that way, you can set it dynamically based on a process variable. That means, setting it to ${assignee} should do the trick
Thanks Thorben. So collection process variable cannot hold values (ex: camunda:collection=“john,mary,peter” etc.), it can only hold a variable name which intern gets evaluated by org.camunda.bpm.engine.impl.bpmn.behavior.MultiInstanceActivityBehavior#evaluateCollectionVariable().
Is my understanding correct?
can I model like camunda:assignee=“john,mary,peter” and camunda:collection="${assignee}"?
Thanks Thorben. I’m able to achieve it using test case. I’m trying to understand, how things are co-related from modeling perspective. The reason why I’m asking this because, modeling will be done mostly by business users.
I think adding technical properties to the model should not be done by business users. Getting those properties right is not a trivial task as it requires good knowledge of how Camunda and its API work.
If there is a business requirement on how assignees are to be determined, then business users could document that requirement visually in the model (e.g. via BPMN annotations or via the name of the lane the task is contained in). Technical users can then implement that by setting the correct technical properties.
You can implement an embedded start form to post a JSON-serialized Java variable. We have an example on how to post a custom POJO. Posting a java.util.ArrayList object should work in a similar way.