by Christian Mächler
Design patterns are blueprints that show how a particular problem can be solved reliably. They can be combined as desired and inserted into models. Design patterns also sensitize you to possible problems and can help to break down complex processes into simple building blocks. While there is a wealth of established design patterns in other areas (e.g. object-oriented programming), this is still virtually uncharted territory in process modeling.
The opposite of the design pattern is the anti pattern, which describes things that should be avoided. For example, merging parallel gateways with exclusive ones (tokens would not be consumed).
The following model is an abstracted version of the problem from practice.
The essential part is the timer, which waits for a date stored in a variable releaseDate.
The principle remains the same, even if the variable for the timer is set differently depending on the workflow engine.
The process is executable and works, but why are variable updates ignored by the timer?
When a timer is reached, it is evaluated immediately and the time for the continuation of the process is saved. If this were already over, the process would continue immediately. After the calculation of the continuation time, variable updates no longer have any influence on the timer. The model also does not show that the release date could change. The following design pattern solves the problem and visualizes the possibility of timer updates. Due to this visualization in the model, it is advantageous to consider this at an early stage and not only during automation.
The design patterns in this article are deliberately kept general and reduced to the essentials. They are not solutions to the problems presented, but building blocks for them. To solve the above problem, the timer must be replaced by the following design pattern. Start and end events are not part of the pattern, but show where the flow comes in and goes out again.
This design pattern uses the properties of the event-based gateway, which continues the flow in the direction of the event that arrives at first. This means that only events may immediately follow the event-based gateway. Timers are evaluated when the gateway is reached, as if the timer itself had been reached. Message events allow variable updates in certain process instances at exactly this point in the process and not otherwise. If the process is now waiting at the event-based gateway, a message can be used to update the date variable. We then lead the flow back to the event-based gateway, so the timer is re-evaluated (new timer instance, old one discarded when the flow continued in the other direction) and messages can still be sent. As soon as the timer is triggered, the flow continues in this direction and no more such messages can be sent to the process instance.
What about boundary timers, how can we update them? It is not possible to use an event-based gateway as a boundary event. We need a new design pattern to solve this problem, one with two possible outputs.
This design pattern allows the creation of various tasks, only one of which can be completed. It works similarly to an event-based gateway with tasks instead of events. There should be never more than one user task. Otherwise, it can happen that users work on different tasks at the same time, but only one can complete his/her task, meaning that the work of the others was in vain. Viewed in isolation, the pattern does not seem very useful, but it can still prove to be a useful building block.
First, we create a sub-process so that we can simply consume tokens without affecting the rest of the process. The parallel gateway generates a token for each of its outputs, which then waits at the respective task. After completing a task, all tokens in the sub-process must be destroyed immediately afterwards (same transaction), otherwise it would be possible to complete more than one task. This is done either with a terminate end event, after which it continues normally (happy path) or with interrupting boundary events, which catch the errors or escalations thrown by the end event in the sub-process. With different escalations or errors, separate outputs can be defined in order to react differently depending on which task has been completed.
With the previously developed design pattern, it is possible to separate the boundary timer from the task and still retain the functionality: It is possible to either complete the task or trigger the timer, but not both. Because the timer is no longer a boundary timer, we can easily replace it with the updatable timer pattern and thus obtain the updatable boundary timer pattern.
With these practical examples, we have hopefully been able to demonstrate the advantages of design patterns and awakened your interest.
We would be delighted if a library of established design patterns were to gradually emerge in the BPMN area as well.
More success through documented processes. Our blog post introduces the three abstraction levels of process documentation: strategic, operational and technical. Find out how they differ in depth and detail and how Business Process Model and Notation (BPMN) optimizes your process modelling.
More
The key to success in today's business world is well-structured process management in order to increase service quality and stand out from the competition. Find out how efficient processes make the difference.
More
Process digitization focuses on the optimization and automation of manual processes through the use of technology. In this blog post, we would like to take a closer look at various facets and the benefits of process digitization.
More
