Message Start Events: Reason for Unique name across Process Definitions?

Reading the docs, shows that Message Start Events have a condition where the message name must be unique across Process Definitions. What is the reason for this?

It seems like this limit creates the need for people to generate another process definition that captures the message and then re-correlates it to many possible definitions that could be waiting for the message?

Is there a un-documented limit or issue with correlating a message name to many definitions?

Hi @StephenOTT,

this is the difference between Message and Signal. Message always has one specific recipient. Signal in opposite is just signaling that smth happened, and all processes interested inn this event, can process it. I’m sure you can find more detailed description in BPMN spec. E.g. this is what I’ve found:

A Signal arrives that has been broadcast from another Process and
triggers the start of the Process. Note that the Signal is not a Message,
which has a specific target for the Message. Multiple Processes can
have Start Events that are triggered from the same broadcasted Signal.

Yes. But in the camunda engine, messages can be used as a signals/messages can be correlated to many recepients :wink:

I did not know this) I even saw exceptions like this: “Cannot correlate a message with name ‘test’ to a single execution. 2 executions match the correlation keys: …”

Could you give an example when it’s possible?

Hi

Have a look in the docs [1], in particular the parameter ‘all’

I discovered this feature a while back. At the time, the guidline was not to think of it as a signal, but to think of it as ‘n’ messages delivered to ‘n’ process instances…

regards

Rob

Thanks Rob. The problem is that you cannot deploy:

The name of the message start event must be unique across all deployed process definitions. The engine throws an exception upon deployment of a process definition in case one or more message start events reference a message with the same name as a message start event already deployed by a different process definition.

@StephenOTT, I think I got your idea now.

In case of intermediate message events we can deploy the processes waiting for the same message, and only in runtime the check will be performed, as at the specific moment when the message is being correlated only one recipient must exist.

In case of start event, we can’t even deploy the processes. But this is logical, because we will have the ambiguity for sure. We’re just able to perform this validation earlier, as we know from the very beginning that more than one process definition will exist, that can be instantiated by this message.