Intro to BPMN (Part 12): One Signal To Rule Them All.
When Messages Are Just Not Enough.
Last time, you’ve learned about Business Transactions and how we can ensure, that all tasks in a transaction are executed or rolled back.
Today, I want to look into Signals, which are similar to Message Events, but more powerful. Let’s take a look.
The Kill Switch
The company decides, it wants to be able to cancel all ongoing vacation requests for a certain period in time. This way, they want to make sure, that all employees are present in the office to improve productivity.
Here are the requirements for our new process:
Department Heads can signal a company-wide vacation block.
If an active request is set for a certain period, it will be cancelled and the vacation days are added back to the employees account.
If the request is outside of the period, we keep it running.
Already approved requests are rolled back manually.
The model shows, how the model could look like. As usual, new elements are marked green.
The BPMN Building Blocks
Signal Start Event: “Cancellation Received”
Signal Events can occur in different locations. They can be Start, End and Intermediate Events, and in case of an Event-Subprocess even non-interrupting (with a dashed border)
Signal Events can have multiple recipients, in contrast to Messages, which are for one recipient only.
In the example above, a single Signal “A” can start two processes A and B, and be received by all running instances of Subprocess C.
Author’s Note: Since an Event Subprocesses cannot cancel a parent scope, we use an Interrupting Message Start Event to cancel the parent execution. It means, the parent scope is cancelled immediately and the subprocess finishes, after informing the employee.
What’s Next?
We’re now have a second, very powerful, tool to react to events in our process landscape:
Signals are meant for many receivers and are broadcasted without any receiver informations necessary, even over multiple instances of different processes.
Messages are meant for a single process instance and need to be correlated with a certain process instance key.
This article closes my series about modeling with BPMN (for now). You’ve learned about the most common symbols in BPMN, what they mean and how you can use them to model your use cases.
Every process is different, so there is never the one right solution. Sometimes you’ll need workarounds and your models will get quite big, even if the problem you’re solving is quite easy. This is usually an indicator, that the processes do too much or are involved in too many systems. The process can help making it visible. And now that you see the process, you can also start improving it: Is this review step really necessary? Wouldn’t it be enough to just let employees just go on vacation?
I hope you enjoyed it and are now able to model your own processes.