Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
en:rule:conditional_event_collaboration [2024-08-28 19:17] – [0-TBD Use conditional event to model collaboration] Anatoly Belaychuk | en:rule:conditional_event_collaboration [2024-08-28 20:56] (current) – [See also] Anatoly Belaychuk | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== | + | ====== Use conditional event to model collaboration ====== |
{{tag> | {{tag> | ||
- | |||
- | {{en: | ||
The message event creates a tight connection between processes: the sender process must know the internals of the receiver. | The message event creates a tight connection between processes: the sender process must know the internals of the receiver. | ||
Line 681: | Line 679: | ||
===== Notes ===== | ===== Notes ===== | ||
- | * Extra comments (optional) | + | There is no significant difference between two models as long as excactly one process issues invoices. |
+ | The event-message scheme may look preferable since it more clearly shows the collaboration mechanism. | ||
- | ===== Exceptions ===== | + | The situation changes if that the company has different sales processes for different product lines (goods, services) or channels (retail, partner, online). |
+ | In this case, the logic of the bank statement processing process becomes too complicated: | ||
+ | it will need a gateway to send a message to the process from which this specific invoice has come. | ||
+ | If a new variation of sales process emerges, the statement processing process should be modified. | ||
- | * Exceptions, if any | + | The conditional event eliminates this dependency. |
+ | Now the processes don't need to know anything about each other' | ||
+ | * the client process (Order to pay) adds a record to the database table (Invoices) and waits until the value of the " | ||
+ | * the server process (Bank statement processing) searches the database table for the record to which the payment refers, and changes the status to " | ||
+ | * the client process awakens and continues working | ||
+ | |||
+ | There may be unlimited number of client and server processes. | ||
+ | |||
+ | In the case of an executable process model, the event message will be automatically processed by the engine. | ||
+ | If the process engine does not support a conditional event, it can be easily replaced with a combination of an exclusive gateway and a timer: | ||
+ | |||
+ | <bpmnio type=" | ||
+ | <?xml version=" | ||
+ | < | ||
+ | <process id=" | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | <task id=" | ||
+ | < | ||
+ | </ | ||
+ | < | ||
+ | <task id=" | ||
+ | < | ||
+ | </ | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | </ | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | </ | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | </ | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | In the case of a non-executable model, the conditional event models an employee periodically pressing the F5 key | ||
+ | on the automated system page displaying a list of issued invoices together with status. | ||
+ | |||
+ | ===== Exceptions ===== | ||
+ | |||
+ | Collaboration via event message is acceptable if it involves exactly two processes. | ||
===== See also ===== | ===== See also ===== | ||
- | * References to similar rules (optional) | + | * [[external_event]] |
+ | * [[event_gateway_warning]] | ||
+ | * [[collapsed_subprocess]] | ||
+ | * [[single_process]] | ||
===== Author(s) ===== | ===== Author(s) ===== | ||
- | Signature | + | --- // |