Read Blog Post

Read Blog Post

Contributed on January 31, 2018

2.1K

914

Interprocess Collaboration Using Conditional Event

Blog: Process is the Main Thing - Anatoly Belychook

I wrote here already that it’s common for what business considers a business process to become several process pools in BPMN – look at process patterns “internal order” or “incoming processor”. In both examples the “client” process posts a task into DB and process to wait message from the “server” process that the task is completed.

The diagrams are valid but here is the caveat: server should know the client internals – namely the event on the client side. It’s ok if the server deals with a single client but what if not?

Let’s consider the example: sales process bills the customer and proceed to wait until another process that polls the bank on timely basis would send the message that the bill is paid –

Now let’s complicate the case: let’s assume that there are several sales processes: one for goods, another for services, yet another to VIP customers, and via partner etc., the list of process templates is open. Where should the server route the message?

Here is the solution: conditional event instead of message –

1. Client process (Sale) writes the task to DB and proceed to wait for the desired task status (bill status = paid).
2. Server process (Incoming payments) changes the bill status.
3. Client process awakens and proceed.

Neither client nor server don’t know each other’s internals, collaborating exclusively via common data (bill). It gives developers freedom to change any process scheme without affecting the others. Or to add another client process variant. Or server variant.

A separate question is whether your favourite BPMS support the conditional event?

The good news for Bizagi customers is that it does now. The above scheme would work in Bizagi BPM Suite – checked.