Multi-instance current element variable

I use multi-instance call activities and subprocesses quite a bit in Camunda, and I have read the Zeebe documentation for this here:

Something seems to work differently with Zeebe/FEEL because I can’t get the multi-instance subprocess to recognize the input element. I have tried a few different configuration options, but can’t find the correct one. It finds the input collection, but claims,
“failed to evaluate expression ‘{orderedOption:orderedOption,orderedOptions:orderedOptions}’: no variable found for name ‘orderedOption’”

I am doing this in the job worker:
List orderedOptions = (List) variablesMap.get(“orderedOptions”);
Option orderedOption = (Option) variablesMap.get(“orderedOption”);
I am assuming that Zeebe knows how to create the current element, “orderedOption” in this case, per the documentation:
“In order to access the current element of the inputCollection value within the instance, the multi-instance activity can define the inputElement variable (e.g. item ). The element is stored as a local variable of the instance under the given name.”

I am sure that it is something fundamental that I don’t yet see, but I am attaching two screen shots in the hopes that someone has the time to take a look.


Ok. When I removed the “=orderedOption” from the multi-instance input variables, Zeebe was able to create it, and it is included as a the input element in the job worker.
(The collection is not a List of my objects (Option in my case), but instead Java maps it to a list of LinkedHashMaps, but this is a separate issue.)

Hi @ken,

In the configuration of the multi-instance activity, the input element must be set as “orderedOption”. It should not start with = (an equal sign). It defines the name of the variables. Only expressions start with =.

Regarding the serialization, the type of a variable can change when it is deserialized. When a variable is provided (e.g. by a job worker or when creating the workflow instance), it is serialized to JSON. When a job worker receives the variable then it is deserialized to a Java object again. Since it doesn’t store any additional type information of the variable, it uses the default (Jackson) JSON deserialization. So, the type of the variable may change.

Does this help you?

Best regards,

Yes, great. Thanks.