Multiple Messages to One Receive Message Event

Certified Associate Developer

Hi,

is it possible to receive multiple messages on one Receive Message Event?

I need to use Receive Message Event to stop the process flow until all the fields of multiple entities are populated, so I have a Send Message Event on each asynch subprocess that sends a message to my main one that the fields have been populated. There is also an Expression Condition on Receive Message Event that checks if all entities have populated values. If it's possible to receive multiple messages, does the condition get validated each time it receives a message?

Thanks!

  Discussion posts and replies are publicly visible

    1. Yes, a Receive Message node (a "listener") can either be exercised once and once only, or for the life of the process instance
    2. Yes, each time a Receive Message is triggered and steps in the flow from that event will be executed again.

    I'd issue a warning here that this is not a scalable option and there may well be a better pattern. For instance, instead of sending/receiving messages your process instance could run on a repeating timer and retrieve the data from the entities you mention and run validation on the data retrieved to determine if your data in complete and valid.

    Alternatively, every time an entity is updated you could call a sub-process that also runs the data retrieval/validation to achieve the same outcome.

  • 0
    Certified Lead Developer

    I think you may really be overthinking this, especially if your choice was to do asynchronous subprocesses.  Those run on the same engine, so while you get some multithreading benefit, I don't think that really nets you very much.

    What if instead you used AND gates to branch your parent process into parallel flows and changed them to synchronous processes, then used an AND gate at the end to wait for all the flows to come back together?  You'd automatically get what you needed from the subprocesses, because when they're synchronous you can get returned values directly back from them.  Your parent process can be informed of all the storedValues you passed out of your write nodes. Plus, they have to succeed before your process can move on.  They can still run in parallel, and they were already on the same engine shard, so you don't lose anything going synchronous.

    The AND gateway waiting for all the threads to be joined together can't complete until it receives all incoming flows, which sounds like exactly what you want.  Then, you don't have to fight with inter-process messaging, the best part of this approach.