Multiple same message subscriptions within one process

I know that if you have multiple process instances of one process, a message will only get correlated to one of them.

But this also seems to be the case for when a single process instance has multiple identical message subscriptions. Take for example this diagram:

When an instance is created, we immediately get 2 message subscriptions. The one on the Receive task and the one on the non-interrupting message start event.
They are both the same message subscription (name and correlationKey). But when a I publish a message with this name and key, only 1 subscription gets correlated: the one for the non-interrupting start event. Actually, no matter how many messages I publish, it will always correlate to the non-interrupting start event.

Of course, this is a minimal example and in this minimal example I could work around it by having a parallel gateway after the receive task. However, in my real diagram this isn’t so simple and I believe I have some valid use case to have one message fulfill multiple subscriptions (within one process instance).

Is there a way to achieve this?

Hey @sebakerckhof

thanks for raising this. This is actually the expected behavior which is also described in the docs Messages | Camunda Cloud Docs

Message cardinality#
A message is correlated only once to a process (based on the BPMN process id), across all versions of this process. If multiple subscriptions for the same process are opened (by multiple process instances or within one instance,) the message is correlated only to one of the subscriptions.

When subscriptions are opened for different processes, the message is correlated to all of the subscriptions.

What you actually want to use is signal events. You can read about it here BPMN 2.0 Symbols - A complete guide with examples. - Camunda Unfortunately signal events are not yet supported by Zeebe (Camunda Cloud). But there is an open feature request for it Maybe you can add some comment here to express your need and use case :slight_smile:

As a work around you can remodel your process, which would my suggestion now, to either use the event sub process and cover all work which should be done on that event or use a boundary event on a sub process or something.


1 Like