Message Events and Subscription Correlation Keys

Camunda 8 Topics
,
1

Hello, I am trying to understand the restrictions around the configuration of Message Correlation Keys. Could not find any explicit mention in the docs.

When I was testing something else I noticed that if I used the same value for Message Name, whenever I updated the Subscription Correlation Key of one message event with a value, all other messages had their Subscription Correlation Keys updated to the same value. This is a simplified version of a model that I used to reproduce it (using Camunda Desktop Modeler v. 5.48.0)

image
image644×383 16.6 KB

Ignore the model - it does nothing; it was just a way to test the updates in the Subscription Correlation Key. All Message Events have the Message Name = “Message_Test” and the value I set to Subscription Correlation Key in any of the Message Events is replicated to the others.

I thought “Okay, there must be a restriction and the same process instance cannot have subscriptions with same Message Name and different Subscription Correlation Keys.” But then I remembered another test I did with a multi-instance Receive Task.

image
image358×181 4.3 KB

In this test I pass a collection of different strings to the Receive Task that also had Message Name = “Message_Test”. Each string is used as Subscription Correlation Key for each instance of the Receive Task, resulting in 3 simultaneous subscriptions:

Message Name = "“Message_Test”, Subscription Correlation Key = “0123”

Message Name = "“Message_Test”, Subscription Correlation Key = “4567”

Message Name = "“Message_Test”, Subscription Correlation Key = “8901”

I ran this process and it worked perfectly. So, the engine can have simultaneous subscriptions of messages with the same Message Name and different Subscription Correlation Keys.

My doubt is: if the engine supports different Subscription Correlation Keys for the same Message Name why the Modeler won’t allow me to configure different values?

PS. Tried the Web Modeler and it seems to behave the same way.

2

You can always use a variable. Correlation Key = =my_correlation_key. That’s basically what you’re doing when you pass in a collection.

I’ve wondered about this limitation as well and I cannot explain why the modeler works like this.

3

I didn’t mention but the behavior is the same with variables. If I set a variable as a Subscription Correlation Key in one of the Message Events, it is replicated to all others, forcing me to use the same variable in all Message Events.

4

Looking at the XML file, when we create a Message Reference, a block is generated:

  <bpmn:message id="Message_1i0ieql" name="Message_Test">
    <bpmn:extensionElements>
      <zeebe:subscription correlationKey="=&#34;4567&#34;" />
    </bpmn:extensionElements>
  </bpmn:message>

And this block is referenced by its id on each of the Message Events.

    <bpmn:intermediateCatchEvent id="Event_1jzuqux">
      <bpmn:incoming>Flow_1kpb8bc</bpmn:incoming>
      <bpmn:outgoing>Flow_0xupnix</bpmn:outgoing>
      <bpmn:messageEventDefinition id="MessageEventDefinition_1qjjr0u" messageRef="Message_1i0ieql" />
    </bpmn:intermediateCatchEvent>
    <bpmn:sequenceFlow id="Flow_1kpb8bc" sourceRef="Gateway_17umkeh" targetRef="Event_1jzuqux" />
    <bpmn:intermediateCatchEvent id="Event_07ixhgp">
      <bpmn:incoming>Flow_0xpp76y</bpmn:incoming>
      <bpmn:outgoing>Flow_146qkgm</bpmn:outgoing>
      <bpmn:messageEventDefinition id="MessageEventDefinition_16s3ik6" messageRef="Message_1i0ieql" />
    </bpmn:intermediateCatchEvent>

That’s why when you change in one of the Message Events it changes everywhere - you changing the same piece of information.

I tried to hack it and create another message block with a different ids and Subscription Correlation Keys but with the same Name but it failed deployment.

ERROR: Multiple message event definitions with the same name ‘Message_Test’ are not allowed.\n",“instance”:“/v2/deployments”}. Enhanced stack trace available as error.source. [ deploy-error ]

Apparently the Modeler and some other parts downstream work with the assumption that in a process instance, a Message Name will be associated with a single Correlation Key (which is not an absurd assumption but it does not take too much effort to think of scenarios where it doesn’t apply) but the Engine works with a different assumption, otherwise the multi-instance Receive Task with the same Message Name and different Subscription Correlation Keys should raise an exception.

5

The same name can only be used in different diagrams, although that is discouraged.

Have you thought about creating a bug report?

It might be a limitation of your use case, though. In your diagram, the first two message events become enabled at the same time, so they will use the same correlation key. The message event following the timer event could get another correlation key, as could any message event further down the flow.