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
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.
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
In case somebody is waiting for this material id - send back notification
Otherwise - collect this id as already notified
In case this material is already notified as completed – notify back the requestor
Otherwise - collect the request for this material id.
Note: This case covers single requester and notifier. In case you need multiple of either of them you have to model additional correlation logic.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
37 | |
19 | |
13 | |
13 | |
12 | |
10 | |
10 | |
9 | |
8 | |
8 |