Now that many of you are acquainted implementing BPM(N) processes, one should have noticed that there are multiple roads leading to the same goal while implementing a business process. One example is the invocation of an asynchronous service. This can either be done with a Send Task or a Message Throw Event. This blog tells about the difference between those two activities within PCS and when you should pick one over the other.
Let’s discuss the Send Task first. The Send Task lets you: instantiate a process, trigger a Receive Task in the middle of a process, or trigger a Message Catch event. Furthermore, the Send Task allows to attach boundary events to it. In other words, you can either attach an error boundary event to a Send Task as well as a Timer Catch Event. The former implies that the process that is invoked by the Send Task propagates its faults to the calling process.
How about the Message Throw Event? Well, it is nearly the same as the Send Task except that one is not able to attach boundary events to it and the calling process won’t be notified upon failures in the called process.
To show an example of the above we implemented two processes. The main process is shown below:
And the process that is called from the main process is implemented in the following way:
While implementing the main process, we ran into the following findings:
- The Throw Intermediate Event is able to invoke the Start, the Catch and the Receive in the calling process.
- The Throw Intermediate Event does – indeed- not allow us to attach boundary events.
- The Send Task allows us to invoke the Start, the Catch and the Receive task.
4) The Send Task allows us – indeed – to attach boundary events to it:
Where the upper boundary allows you to catch system faults and/or (a specific) business fault(s).
So where does that leave us? When to pick which activity? In the left corner of the boxing ring we have the Send Task and in the right corner we have the Throw Message Event. Use the Send Task when:
- You want to keep track of time passing by. A possible use case can be that you start a process that facilitates a customer to pay. When no payment transaction occurs within 30 minutes, the timer expires and the main process can cancel the order.
- You want to be sure that the invoked process is invoked (and executed) correctly. In case of any malfunctioning the main process will be notified.
But only use the Send Task to either invoke a Start event or a Receive task. Don’t intertwine Send Tasks and Message Catch Events.
Use the Throw Message Event:
- When you are implementing a Fire and Forget message exchange pattern. You don’t want to start a process with the Throw Message, but you want to notify running processes.
- In combination with the Catch Message Event.
For those of us that are used to working with BPM suite, there aren’t many differences. However, there is unfortunately no opportunity to use the Throw Message Event to trigger an Event Subprocess, as the Event Subprocess is not part of the PCS implementation. Furthermore, BPM Suite supports the usage of so called Signals to communicate in a 1-n manner with other processes. In PCS there is no such thing as signals.