Send Message Event:
In the Setup tab, for 'Message Destination', select the Receive Message Event that is in the Process Model where you need to send the message. To do this, search for the process model and select your Receive Message Event.
In Data tab, 'DestinationProcessID' is the ID of the process instance of the Process Model to which you need to send the message. Click on "New Mapping" and name it. Configure the 'type' based on your need. The 'value' should be your process variable which holds the message(data) to be sent.
Receive Message Event:
In the Setup tab, for 'Receive Message', select 'Process to Process'.
In Data tab, click on 'Import Custom Properties', search for the Process Model where you have the Send Message Event, and select your Send Message Event. 'Value' will be automatically set. Then store it in the desired process variable.
My Use Case:
In Process Model A, I call an integration to perform my desired job. When starting that integration, I pass the Process Instance ID because I need this ID to send a message back from Process Model B. After the integration node in Process Model A, there is a Receive Message Event where the process waits.
After the job completes, it triggers a Web API to start Process Model B, passing both the job output and the Process Instance ID that was sent earlier. In Process Model B, I use this Process Instance ID as the DestinationProcessID in the Send Message Event. Additionally, I configured Import Custom Properties to pass the job's output data back to Process Model A.
Process Model A waits at the Receive Message Event until it receives the message from Process Model B. Once the message is received, Process Model A completes the process.
This configuration enables process-to-process communication using message events and Process Instance IDs to pass data between process models. This enables efficient coordination between long-running integrations and targeted message delivery.
Discussion posts and replies are publicly visible
I do not really understand why you need process messaging. Can you help me with this?
Good question! In my use case, I have a long-running integration that takes significant time to complete.
Without process messaging, the process would stay active and wait, consuming resources and potentially timing out.
With process messaging, the process moves to a wait state and frees up resources. When the external job completes, it triggers a Web API that sends the results back to the exact waiting process instance using the Process Instance ID.
This approach is more efficient for handling long-running external operations without blocking the process thread.
"moves to a wait state"? What does that mean. An active process instance waiting for an incoming message is no different than any other active process instance.
Did you consider to split that process in half. After triggering that job, it completes. And that API starts the second part directly.
"wait state," I mean Process Model A is waiting at the Receive Message Event for the message from Process Model B, which gets triggered via Web API after the job completes.As you said, I did consider splitting the process. The first half triggers the Integration and reaches the Receive Message Event where it waits. After the job completes, the Web API starts Process Model B, which sends the message back to Process Model A. Once Process Model A receives the message (second half), it completes the Process.
Tejas Sugandharaju said:"wait state," I mean Process Model A is waiting at the Receive Message Event for the message from Process Model B
But in this state the "Model A" process is still running and consuming resources. When your integration triggers a new process, it should just kick off the second half of Model A as a new instance, query anything needed from the DB, and proceed from there in a fresh instance. At least, doing this would use less resources, be trivially easy to set up, and not force you to utilize the old and hard-to-configure, hard-to-test, p-2-p messaging functionality.
The integration doesn't trigger a new process - it simply initiates an external job. After the job completes, it triggers a Web API that starts Process Model B. Process Model B then sends a message to Process Model A's Receive Message Event, completing the workflow.
In my case, I don't need to query any data from the database, as all required information is already in the process context.Please note this is a simplified use case for a proof of concept I'm currently developing. I'm evaluating process messaging as one of the potential solutions for this type of scenario.
The images below are of the Process models.
Tejas Sugandharaju said:After the job completes, it triggers a Web API that starts Process Model B.
... in other words, starting a new process.
The way you describe here will work, of course, but your original stated request indicated you would rather free up resources utilized by leaving a process running for a long time. The approach Stefan and I have both described would accomplish this. The new process would re-query the needed info from the DB, but this would be a very trivial cost compared to leaving the original process running for a long time.
Thank you both for the detailed explanation. I appreciate your insights and will consider this approach for future implementations.Thanks!