Configuration of Send Message Event and Receive Message Event within Process model

RE: Configuration of Send Message Event and Receive Message Event within Process model

Tejas Sugandharaju — Fri, 12 Dec 2025 05:56:40 GMT

Thank you both for the detailed explanation. I appreciate your insights and will consider this approach for future implementations.

Thanks!

RE: Configuration of Send Message Event and Receive Message Event within Process model

Mike Schmitt — Thu, 11 Dec 2025 19:09:55 GMT

[quote userid="318496" url="~/discussions/f/general/40014/configuration-of-send-message-event-and-receive-message-event-within-process-model/152764"]After the job completes, it triggers a Web API that starts Process Model B.[/quote]

... 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.

RE: Configuration of Send Message Event and Receive Message Event within Process model

Tejas Sugandharaju — Thu, 11 Dec 2025 18:17:13 GMT

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.

RE: Configuration of Send Message Event and Receive Message Event within Process model

Mike Schmitt — Thu, 11 Dec 2025 15:25:47 GMT

[quote userid="318496" url="~/discussions/f/general/40014/configuration-of-send-message-event-and-receive-message-event-within-process-model/152760"]"wait state," I mean Process Model A is waiting at the Receive Message Event for the message from Process Model B[/quote]

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.

RE: Configuration of Send Message Event and Receive Message Event within Process model

Tejas Sugandharaju — Thu, 11 Dec 2025 14:44:20 GMT

"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.

RE: Configuration of Send Message Event and Receive Message Event within Process model

Stefan Helzle — Thu, 11 Dec 2025 12:22:22 GMT

"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.

RE: Configuration of Send Message Event and Receive Message Event within Process model

Tejas Sugandharaju — Thu, 11 Dec 2025 08:12:21 GMT

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.

RE: Configuration of Send Message Event and Receive Message Event within Process model

Stefan Helzle — Thu, 11 Dec 2025 07:38:54 GMT

I do not really understand why you need process messaging. Can you help me with this?

RE: Configuration of Send Message Event and Receive Message Event within Process model

Shubham Aware — Thu, 11 Dec 2025 05:43:23 GMT

Your configuration is correct.
Send Message Event: Uses DestinationProcessID set to Process Model A’s instance Id so the message is delivered to the correct process instance.
Receive Message Event: Is configured to receive from that Send Message Event and uses imported custom properties to map the incoming data into Model A’s process variables.