Subscription correlation key containing a dot


I am working with a BPMN file and a Receive Task configured as follows.

  • Name: Documents uploaded
  • Message name: DocumentsUploaded
  • Subscription correlation key: soa3.token

The Zeebe modeler lets me configure it this way…

Also the soa3.token variable configured as correlation key will exist among the variables of the instance as it is created in a previous task.

Now, when I create an instance, and make it progress until this Receive task, I get an error message in Operate as soon as this task activates: "Failed to extract the correlation-key by ‘soa3.token’: no value found"
Checking the instance, this variable actually exists…

Am I doing something obviously wrong here?

Hi @ajeans,

did you create the workflow instance with a variable soa3 that has a nested property token?

Please note that a variable name must not contain a dot. When extracting the correlation key soa3.token from the workflow instance variables then it tries to access the nested property token of the variable soa3.

Best regards,

Thanks for the quick feedback @philipp.ossler

I indeed did not create a variable with a nested property.

This variable was created from a Java job worker with:

variables.put("soa3.token", soa3Token);

Changing the job worker to

variables.put("soa3", Collections.singletonMap("token", soa3Token));

fixes it for me…

So thanks a lot @philipp.ossler .

Now, I must admit that this is quite confusing for a newcomer.
When I define the correlation key in the modeler, I input “soa3.token”, so it is quite expected that this is the key I would use in the variable map.
Maybe the client code could handle this usage a bit better by:

  • warning if the key contains a ‘.’, or
  • splitting on ‘.’ and creating nested elements
1 Like

Thank you for the feedback. I agree that the broker should validate that the variable names are valid. Feel free to create an issue on GitHub.


Created as

Have a nice day @philipp.ossler


Actually the names are valid right, since it is just a json string.


Thanks for the input @Zelldon.

Handling a variable name with a dot in an expression can be confusing for user. In FEEL (the new expression language for Zeebe), a dot is used to access a nested property of a context (i.e. a JSON document). I would prefer to not allow this kind of variable names to make it easier for users.

Agree, I just remeberred a discussion with you or with some other, about the mapping stuff and naming of variables. I think there was the request that this works with dots in names.

But yes I agree this is weird and confusing.