The chief constituents of a BPMN diagram, BPMN elements, can be broadly classified into five categories:

Artifacts

Artifacts are graphical representations that provide supporting information about the process or elements within the process. They don't interfere with the process flow; in other words, we can say that they are opaque from the perspective of process execution. The basic types of artifacts stated in the BPMN specification are as follows:

• Group: The Group construct can be used to logically group an arbitrary set of flow objects to show that they logically belong together
• Text Annotation: Text annotation can used to associate additional documentation with any element in a BPMN diagram

The banking transaction process is illustrated in the following diagram with the core elements of event, activity, data object, lane, and gateway annotated:

A supply chain is an interconnected set of business procedures and business partners that manages the flow of goods and information from the point of design to the delivery of the product and/or service to the end customer. The supply chain provides a well-coordinated channel to organizations for delivering their products and services to the end customer. Supply chain typical include the following:

A few processes to name in the supply chain domain are as follows:

Order management is a core process in the supply chain domain. The process depicted in the next figure is a trivial process but is intended to exemplify the ease and clarity that a business process brings to the table, particularly to a cross-functional business process. From the process diagram itself, any layman can understand the cross-functional units in the organization and, of course, the flow. Thus, the users, both business analysts and operations users, can understand the bigger picture more easily, thereby improving the overall communication and efficiency.

Payment is an activity but has the size and complexity of a separate process. Further, if we apply the rule of responsibility, a payment needs to be clearly abstracted as a separate process that can be reused across the processes of the organization for processing a payment. Thus, we can take a design decision of making payment a sub-process that reduces complexity, enables better handling of exceptional situations, and enables reusability.

Another point I want you to notice in this particular process is the Stop event in No Stock; a message is embedded in the termination of the process. This can be used as a signal to another organization process for handling No Stock situations; for example, in this case, No Stock would be the signal event to trigger a demand management process.

Banking is another domain where BPMs are heavily applied. BPM enables banks to automate their business process such as account opening, loan processing, payments, and transactions. Visibility of processes and compliance to regulations are critical in the banking domain. Banks continuously make innovative changes in their processes and services, and BPMS provides them with the capability to adapt to process improvement initiatives rapidly.

The typical business processes associated with banking are as follows:

The preceding figure shows a simplified version of loan processing, similar to the supply chain management domain sample process. The clarity it brings in is obvious. However, in the banking domain, the more important aspects are the flexibility, automation, and intelligence options that BPM puts before the business users. The business users can define processes and modify them, thus bringing agility for market promotions; automation helps users to successfully comply with regulatory compliance; and activity monitoring-based analytics help banking organizations to reduce fraud and enhance customer experience.

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.

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.

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.

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 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.

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 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.

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 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.

Kie is the abbreviated form of "Knowledge is Everything," and the Kie workbench is a combination of every tool in the Drools world for capturing and managing knowledge. It combines capabilities such as authoring of projects, data models, rules, decision tables, test services, process authoring, process runtime execution, process simulation, and human task management.

The Kie workbench provides a web frontend and a complete integrated environment for doing all BPM-related activities. It makes it easier for the user to manage the large set of tools. The underlying architecture is highly modular, and you can integrate each part of this functionality independently to your web application, provided it is UberFire-compliant.

The importance of Kie workbench is that it also provides a philosophy, a guideline, and a process, in developing knowledge-based systems. It guides you through developing a knowledge-based system in a structured manner.

The knowledge life cycle, as the community calls it, is a cycle consisting of the following steps:

The knowledge life cycle shows the maturity of the JBoss community in providing ready-to-use, knowledge-based application development environments.

Although as a BPM suite, jBPM focuses on business users with a large set of web-based tooling for business users, the community firmly keeps their feet on the ground, with explicit tooling for technical users who are relied upon to build complex business functionalities.

Eclipse-based tooling is a set of plugins to the Eclipse IDE and allows technical users to integrate the jBPM environment to the software development environment. The Eclipse tooling provides features such as the following:

The core of jBPM is a business process execution engine built in Java. It is lightweight and is easily embeddable in any Java application as a dependency (as dependent libraries). The core engine is designed as a standard-based, pluggable, and highly extensible component. It supports the native BPMN 2.0 specification.

The knowledge repository is where we store all the process definitions and related artifacts. BPM is a continuous process; business processes continuously evolve, and it is important to keep track of the updated processes and provide multiple versions of the processes. jBPM uses Drools Guvnor as the knowledge repository and provides the following:

We have already discussed the knowledge repository in the core concepts section of jBPM, and you guessed correct, jBPM uses Drools Guvnor as its knowledge repository.

Drools Guvnor provides the following features:

Drools Expert is a rule engine. The knowledge is stored in the knowledge base as rules, which are defined in a declarative language, Drools Rule Language (DRL). The engine matches the incoming data or facts against these rules to reach a decision and execute actions attached to the inferences/decisions.

Drools Fusion is an event processing engine used to detect and select the events of interest (business interest) from multiple streams or an event cloud. Fusion works in tight integration with Drools Expert.

Drools Fusion provides the following features:

Now that we have discussed the tools, we can now move on to visualize how these tools work together to make a business solution that is completely rule-driven. The following figure provides a bird's eye view of a possible solution architecture where we use these tools together.

Together, they enable business analysts to write and manage applications by mapping business scenarios to process definitions, rule definitions for decisions, and rules including temporal logic.

Another important thing I want to highlight from the preceding figure is the technology platforms used by the individual tools. The web-based user interface for process designing and operation management is developed using the UberFire framework; the Eclipse-based tooling is based on eclipse RCP; the runtime is based on the Kie framework; and Guvnor is based on virtual file system-based storage and by default uses Git. The details of these technology platforms so as to customize and extend jBPM will be discussed in Chapter 7, Customizing and Extending jBPM.

Red Hat also provides a commercially supported flavor of this package and is called Red Hat JBoss BPM Suite.