Multiple intermediate catching events subscribing to the same message

Good day.
I just want a clear understanding how to send messages to processes that have multiple intermediate catching events subscribing to the same message. I think I understand it but it seems a bit strange to me.

The reason that I ask is because the REST API looks like this:

POST /runtime/executions/<execution Id> 
Data: {
   "messageName":"nameOf TheMessage",
   "variables" : [
     { "name": "someName", "value": "someValue" }

From my experiments, the execution id to pass to this API is not the execution id of the process, but it needs to be a child execution that represents the Intermediate Catching Event (ICE) itself.
Now if I have multiple waiting ICE that all subscribe to the same message, I need to call the API 1 time for each event and pass the same message name and data to it.

This seems odd to me because I expected to call the API only once with the message and data, while the engine would then trigger all ICE that subscribe to that message in one transaction.

Is the current behavior correct as it was designed?
Am I using the ICE concept incorrectly?
Is there a different API that does what I am trying to do?
I would expect that an API should exist where I pass the ID of the process, the name of the message and the data payload, and for these steps to then be executed in 1 transaction.

Thank you for your help in advance.

That is correct. The message event subscription is associated with the execution id.

Not sure what an ICE is? But to answer your question: you’d need to either

  • query before you’re passing the message
  • pass the execution id to the external service and then pass it back when the external service calls back.

Possibly - but for that we’d need to know your use case.

I just shortened Intermediate Catching Event into ICE

My use case is:
I want to do a single API call that will start 1 transaction, and trigger all active/waiting Intermediate Catching Event that subscribe to the specified message, to advance to the next part of the diagram.

Currently our workaround is the query for all the executions ids for the active/waiting Intermediate Catching Events of the process and call the REST API many times for each result.
This creates many transactions instead of the desired 1 transaction.

Hi @joram , I’m just checking if you saw my previous answer.
Not trying to put any pressure on you.

Hey @maudrid,

Message Intermediate Catching Events are associated with an execution. Which means that you can only send a message to a particular execution. However, it seems like you are looking for something like the Signal Intermediate Catching Event. If you send a signal then all processes waiting on the same signal will be triggered within one transaction.

Note 1: When you do this if one process fails the entire transaction will be rollbacked.
Note 2: The signal should be marked as global scoped in your process


Thank you Filip, just to check, would I need to use Signal Intermediate Catching Event even if there is only 1 process that contain the related catching events?

My use-case does not cover multiple processes, I just want to trigger the catch events in a single process instance.

Hi hate bumping posts, but I would like to just get some closure on this one.

Yes, when messages are involved you always need to have the associated execution id. Even if there’s only one process instance using the particular message.

For your use case, it does looks like a signal event is an easier approach, as you don’t need to associate it with an execution/process.