In the reality the need for inter processes synchronization is quite possible, whilst the way of synchronization is not that obvious.
The example is based on master data governance process in SAP ERP. In the process below, each box depicts different attributes of the material master definition.
Imagine you have to model a business scenario which consists of running several processes instances of the process model above for material master definition in ERP. Let’s assume that one of the material masters is a bill of materials (BOM), which means – consists of the others. So you SHALL NOT be able to complete the BOM costing section of the latter unless all the others costing section complete.
At first glance it would be simple by just putting an intermediate event at the point we want to control, prepare a list of processes (ex. correlating them by material id) we are waiting for, after this BOM cost & preparation just trigger an event, notifying all the processed which are waiting for the latter.
Taking a deeper look may turn into a nightmare, because
- We have modeled each different section definition as a separate process.
- Each one of them requires human interaction, which means that we cannot guarantee that all the processes (especially BOM) will be running at the moment of sending the notification.
Keeping in mind that BPM will not take care of any intermediate massage events, sent a prior to starting its consumer, there is a big chance to lose a significant notification and stick in waiting for it forever.
The main idea is to model one additional process which will be responsible for collecting all the notifications and all waiting request, hence we will guarantee that none of the notifications will be lost regardless of the processes starting order. Finally, when everything is done stop the synchronizer. So in the very beginning we could model something similar to the picture below.
Starting the process synchronization
Processes synchronization in details
Process synchronization consists of three parallel flows
– Collect all the notification for BOM cost & preparation completion of all the child materials
– Collect all the request for BOM cost & preparation completion of the parent material
– Waiting for termination
- Intermediate event, correlated by the material master id, waiting for completion notifications.
In case somebody is waiting for this material id – send back notification
Otherwise – collect this id as already notified
- Intermediate event, correlated by the material master id, waiting for completion request.
In case this material is already notified as completed – notify back the requestor
Otherwise – collect the request for this material id.
- Wait for termination event.
- For each notification and request verify if this process is being terminated.
Note: This case covers single requester and notifier. In case you need multiple of either of them you have to model additional correlation logic.