Multi instance - input collection issue

I have some issue. I am testing the multi-instance support, as described here.

I have a simple process.

start → task 1 → task 2 → end

  • when task 1 is executed it will send with the completion command, some variable (let’s call it items)
    The name is “items”. In zeebe monitor the value can be seen it is [“b2e3a0a2-ca6c-4729-a46c-720268fdfe00”,“81ecfc98-0c10-4202-ab98-5b5c38daf5f2”], so an array directly not a JSON.

  • task 2, is multi instance, so on inputCollection I set “= items”
    But when the task 2 is executed - I get an incident like “expected Array but found Null” on the data extraction.

I don’t understand what is the issue, my use case, seems exactly what is described in the link above.
The docker image I use to test this, is zeebe latest, updated today for me.

EXTRACT_VALUE_ERROR Expected result of the expression ’ items’ to be ‘ARRAY’, but was ‘NULL’.
This is the error I see on incident.

Oke, this is odd.
I noticed something.

The actual name of the variable in my example was something else, not “items”. But I put “items” in this example.
In my actual work, the naming was something like “some-name-variable”.
So I actually changed it to “items” and some other name without “-” and it worked.

SO IS THIS THE ISSUE ?
Is there some actual naming constraint, making the fact that in my scenario I had “-” in the name, to not work ?

2 Likes

It probably gets parsed by the FEEL parser as a binary subtraction operator.

If the name or path contains any special character (e.g. whitespace, dash, etc.) then the name needs to be wrapped into single backquotes/backtick `foo bar`.

From the section Path Expression here:
https://camunda.github.io/feel-scala/1.11/feel-expression

1 Like

The constraints for variable names are listed in the documentation here: Zeebe | Camunda Cloud Docs

Please have a look :slight_smile:

1 Like

Thank you @philipp.ossler @jwulf !

One other question. When collecting the output, do you know
it you can transform the output collection into a Json Document,
instead of a direct Array ?

The output collection will be always a JSON array. You can transform the array later in the workflow using input/output variable mappings. Or, using an output mapping on the multi-instance activity to collect the results instead of the output collection.

Does this help you?
Please provide an example if this is not clear.

So basically let’s say the output element is a complex object something like

outputElement ->
{
    "name" : "someName",
    "version" "0"
}

By default this will be collected into the outputCollection as a JsonArray

outputCollection ->
[{outputElement1}, {outputElement2}]

What I would like is to have the result be a JsonDocument instead something like

outputCollection ->
{
   "results" : [{outputElement1}, {outputElement2}]
}

If I try to put an output mapping on the Activity, it seemed to me it is prone to errors, when collecting
the output collection, because it will use the output collection variable that is used on the individual subprocess instances, and it can lead to unexpected override behavior.

So maybe, the only solution is to do an input mapping on the next task ?

The input mapping in the next task is the easiest solution :+1:

Or, wrapping the multi-instance activity in an embedded-subprocess that do the transformation in the output mapping.


Just to demonstrate how the solution could look like using an output mapping on the multi-instance activity.

Given that the workflow instance has the following variable (e.g. passed in as variable on creation):

outputCollection: {"results":[]}

When the job is completed with a variable “outputElement” then the result can be collected using the following output mapping on the multi-instance activity:

source: =append(outputCollection.results, outputElement)
target: outputCollection.results

It appends the output to the result list and updates the property “results” in the “outputCollection” variable.

1 Like

That sounds oke. Thank you !
I appreciate your help.
I am currently assessing these aspects, cause I am analyzing the
technology, cause I am considering in using it in a production project,
for some more complex processes and Zeebe really started my interest.

I know it’s unrelated to this thread, but I would really appreciate
your informed input on Availability for production, as well.
Thanks in advance @philipp.ossler