CAM-11143 - MessageCorrelationBuilder: deprecate correlateAll in favor of Signals

[falko]

BPMN 2.0.2 page 91 (PDF 121) says:

A Message represents the content of a communication between two Participants.

So the API that allows sending a message to multiple process instances at the same time violates BPMN execution semantics. Signals are explicitly designed for broadcasting use cases and should be suggested as an alternative through JavaDoc.

[ThorbenLindhauer]

Hi Falko,

Thanks for raising the PR. I'm sorry I didn't get back to this earlier, during the 7.12 release it escaped my attention.

Overall I think we should not make this change for the following reasons:

• Sending a single message to multiple recipients may not be very close to the BPMN standard, but that is not important to every user. With the deprecation we force the "BPMN purist" view on all users. Initially, message correlation did not have #correlateAll and we only built it for popular demand, which shows that for many people it is not so important to follow BPMN by the word.
• #correlateAll can also be understood as correlating many messages (with the same properties) at once, i.e. like a loop over #correlate in one transaction. This view does not violate the BPMN standard in my opinion.
• Deprecation usually means that there is a better way to do the same (or more) things. However, signals currently offer less functionality than messages. E.g. message correlation has nice parameters to match process instances that signals do not have.
• In the past we have gotten negative feedback for deprecation of other API methods where the case was much clearer in my opinion: https://forum.camunda.org/t/why-got-deploymentbuilder-deploy-deprecated/3100. I currently tend to apply deprecation only where everyone can agree.

I hope this makes sense to you and please let me know if I'm overlooking something.

Cheers,
Thorben