Design patterns in business process modeling

Design patterns are solutions to commonly occurring problems in their corresponding domain. Business process models try to map general business processes and procedures by using a standard set of elements. The design patterns provided next are solutions for certain commonly occurring problems in business process modeling.

The section focuses on providing an introduction to the design patterns that were identified in the business process modeling domain. Understanding these patterns would help you in identifying solutions easily to the problems you are trying to map using BPMS. The following list of patterns is found in the pattern templates provided by the jBPM designer tools.

Sequence

Sequence is the most basic pattern that occurs in business process modeling, using which tasks to be executed sequentially, one after another, can be modeled.

jBPM supports this by connecting the task using sequence flow connectors, which provide a sequential ordering of the tasks.

The preceding figure illustrates a part of the loan processing in the banking domain, which represents a sequence pattern problem. Activities such as collecting loan information, validations, and sending for authorization have to be done sequentially; these activities can be allocated to separate human users or even to system automated tasks.

Parallel split

A parallel split pattern is used for splitting the branch of execution to more than two branches in such a way that each of the outgoing branches is executed in parallel.

jBPM supports a parallel split pattern by using a parallel gateway, in which all outgoing branches are activated simultaneously.

The preceding figure shows a scenario in the order fulfillment process, where a parallel split pattern is applicable. During the ordering process, after providing the order details the shipment of the order and the invoice sending, payments may be parallel paths of processes. The parallel split pattern fits in here, solving the problem.

Synchronization

A synchronization pattern is just the other end of the parallel split design patterns; it merges two or more branches in such a way that the merged branch would run only after the execution of all incoming branches that are to join.

The preceding figure shows the continuation of the example from the parallel split pattern, after the parallel process paths for shipment and payment making are completed, there is a close order activity to be done. Notice that the close order activity has to be done after the completion of both the payment and the shipment activities.

Simple merge

The simple merge pattern provides a way to merge two or more branches in a process definition into a single path of execution. This is particularly useful in scenarios where there are two or more paths to reach a common set of activities. We can avoid duplicating these common set of activities by using a simple merge pattern.

In jBPM, single merge can be realized by using an XOR or exclusive gateway, which awaits one incoming branch to complete before triggering the outgoing flow.

The preceding example process, which deals with changing the password of an online banking customer, fits nicely with the problem statement of a simple merge. As illustrated in the diagram, for ensuring security, the user is given two options, either provide the debit card details or answer a security question. After giving either of these options, password confirmation occurs. The exclusive gateway (before the Confirm Password activity) provides control to the confirm password activity after the completion of either of the parallel activities.

Exclusive choice

Exclusive choice patterns provide a solution to diverging a branch into more than one branch (or path of execution) such that after the completion of the incoming branch, the flow of execution is handed over to precisely one branch on the basis of the condition of branching.

In jBPM, this pattern can be implemented using the data-based exclusive (XOR) gateway. The XOR gateway splits and routes the execution to exactly one branch on the basis of the branch condition provided.

The preceding figure illustrates a scenario for exclusive choice. The sample is a part of a process for making an online transaction. After entering the password based on a validation in the exclusive gateway with the condition, the selection of the path to continue is made. This pattern is similar to a decision box in a flowchart.

Implicit termination

The implicit termination pattern enables a user to terminate the process from any branch. The process engine verifies the completed workitems and decides the termination of the process. This largely avoids clutter because otherwise we have to design the process in such a way that these paths join at a single point of termination. The complexity of such a design would increase with the increasing number of paths in the process.

The previous figure shows a process with two terminations or termination events attached. Here, either after completion of Task B or after completion of Task C, the process terminates.

If implicit termination is not supported by the BPMN implementation, users can achieve the termination by merging the paths to a common termination, and is called as explicit termination.. The following figure shows the explicit termination:

Referring the preceding figure, we can see that a gateway is used to achieve a common termination point. The results of the process execution in the previous two cases are the same, but the second solution (explicit termination) is more complex.

Deferred choice

Deferred choice gives a business process the ability to choose a path on the basis of an interaction with the operating environment. The execution control waits in the decision gateway; the path where the first task is initiated is chosen as the path of execution.

The preceding figure shows the implementation of a deferred choice pattern in an online banking scenario. The process is for enabling the customer to register his/her e-mail with his/her account to receive updates, account statements, and so on. After the registration, an e-mail is sent to the customer at the registered customer ID to complete registration. If the customer doesn't respond to it within a specified time period (here, 24 Hours), the registration fails.

Multiple instance without synchronization

By using the Multiple Instance (MI) facility, we can create multiple instances of a task. These instances are independent of each other. There is no requirement to synchronize the execution flow after the multiple instance execution, unlike a merge.

jBPM allows us to model a multiple instance sub-process, which can be used to implement the MI patterns. An example is shown in the following figure:

After the execution of Task A, the Task B execution is done by using a collection expression used to define B Multiple Instance Sub process. Multiple instances of Task B are executed depending on the number of items provided in the collection expression. Task C is executed without waiting for the execution completion of Task B (or instances of Task B). This pattern is particularly useful when multiple tasks need to be run in a fire-and forget-manner.

For example, in a process, we have to send e-mails to a set of users (say subscribers for an incident). Here, the collection expression would be the list of subscribers. The multiple instance task (send e-mail task) would send e-mails to each subscriber.

Synchronized merge

Synchronized merge provides a controlled way for merging a branched execution flow. The execution flow is merged when all incoming "active" branches are completed.

jBPM implements this pattern by using the inclusive gateway. Inclusive gateways, upon splitting, activate one or more branches on the basis of the branching conditions. Upon merging, it waits for all active incoming branches to complete.

The preceding process illustrates a synchronized merge scenario. Based on the condition for the levels of approval, one or more levels of approval may be required. The second inclusive gateway ensures that the control to the next activity is done after all active approvals are done.

Arbitrary cycle

Arbitrary cycle patterns address the need for repetition of tasks in a process model in an unstructured manner, without the need of explicit constructs such as loop operators. This pattern helps in representing process models that require a cycle in a visually readable format.

The preceding figure shows that tasks can be cyclically connected using connectors and gateways.