A part of my bachelor “Business Process Modeling” course is related to teaching common control-flow behavior in business processes and process-aware information systems – commonly known as workflow or more specifically control-flow patterns.
The website workflowpatterns.com is a perfect reference source for teaching control-flow patterns whereas I try to represent the patterns in BPMN, a standardized process modeling language, my students get familiar with in the same course.
Critical Section pattern
The Critical Section pattern limits two or more sections (e.g. tasks or sub-processes) of a process from executing concurrently, which may occur in case of resources (e.g. persons, IT resources, peripheral devices, etc.) capable to handle a single request at the same time only. Just imagine the challenge of two persons trying to change the same desktop document simultaneously.
Critical sections modeled with BPMN
The workflowpatterns.com website evaluated BPMN as not having a dedicated construct capable of modeling critical sections. However, a similar functionality may be realized with existing BPMN constructs as evident from the following diagram. The presumption in all examples is that critical sections are not entered in the exactly the same time (in milliseconds), which would result in an exception.
The first example is most simple and realizes a critical section with guards (conditional events), which validate if the conditions for entering a critical section are met.
The drawback of this implementation of the pattern is that the logic, which test the conditions is implicit and rather abstract. This drawback is well addressed in the following example, which realizes the ‘logic’ of the ‘Critical section’ pattern with Gateways and works almost perfect if the critical sections-related information is available to Exclusive Gateways (should be available in a workflow environment).
The drawback is that a token (depicted on the above figure as a circle) remains in a deadlock after all critical sections have been performed. With some additional logic, this can be addressed as follows.
The above example realizes the ‘Critical section’ pattern with additional Conditional flows, which bypass the problem with the remaining tokens. However the conditions are rather complex (i.e. the underlying workflow environment should have the knowledge if a critical section is waiting for being performed).
The following Critical section pattern example is realized without complex conditions. Instead it uses Even-based sub-processes and Signal events. A precondition is that Signals are persistent (in case of being transient, the diagram would become more complex).
As evident from the above pattern, critical sections are entered in case of the default paths (timer events) followed after the Event-based Gateways.
Without a dedicated concept, modeling critical sections in BPMN is rather complex.
The presented example demonstrate that it is possible to implement critical sections with BPMN, without a dedicated ‘critical section’ concept. However, the solutions are rather complex, where each of the presented implementations of the pattern has also its own limitations.