"All business does IT" (Information Technology). This was a superlative but a futuristically interesting tweet I came across recently. The impact of information technology on business in recent years has been overwhelming. They are like two large galaxies in our universe, colliding and merging. The current state of this merger can be defined by one term - collaboration. Businesspeople collaborate with information technology (IT) people and use IT services to continuously improve and deliver commercially viable and profitable product/services to their customers.
Collaboration quintessentially needs effective communication, and Business Process Modeling smoothly fits into this scenario. Business process modeling is not new; business people have always used it. Models were developed in mind, and then, they were written down as text or depicted as diagrams. With IT embracing business, these models evolved into standard flow charts and activity diagrams. However, there was ambiguity; the diagrams and text provided by business as requirements were interpreted by the technical people and they had their own representation, architectural models, requirement documents, and design. This was duplication of effort and people, intensive, often with a line of meetings between business stakeholders and information technologists negotiating, and arriving at conclusions about the business requirements. This being the scenario, what improvement does business process modeling bring to the table? Business process modeling brings in the concept of a common artifact between business and information technologists.
Business models are prepared by business analysts and shared with technologists. They collaborate and improve on the model and arrive at an artifact that is executable. Further, technologists as always reduce their work by automating their involvement; that is, we are moving largely to software systems where business people can configure the business process and execute it without the intervention of an information technologist.
Concluding the philosophy, let us jump to the larger context of Business Process Management (BPM) and discuss it in detail. This chapter covers the following concepts:
Business process management concepts
The standard – business process model and notation (BPMN 2.0)
Use cases of BPM as applied in the industry
Design patterns in the BPM world
A brief introduction to jBPM
Business logic integration platform, the bigger picture
BPM involves the designing, modeling, executing, monitoring, and optimizing of business processes. A specialized software system that helps achieve these objectives completely is called Business Process Management System (BPMS). Most of the IT infrastructure used in business is in fact part of one or more business processes, and a BPMS should have the capability to manage the complete life cycle of a business management process. Further, jBPM provides a complete BPMS.
A business process consists of a set of activities, organized to complete a specific business objective, which varies from creating a product to delivering a service. A business process model also provides a visual representation of the business processes. The activities in a business process (also called tasks) are connected to represent the execution flow of a business process; further, these activities can be categorized.
jBPM helps its users to define and model business processes by using its process designers. Business users can in fact design the business process online, and efficient versioning and history capabilities help in making the activity of modeling business processes collaborative. There are provisions to simulate how a business process might behave during runtime. jBPM also provides capabilities to migrate the process definition to an updated version when business changes stipulate process improvements.
The defined business process models are deployed to BPM software, where instances of these process definitions are created to execute the process. jBPM provides the capability of executing business processes and has complete operation management capabilities such as tracking, controlling, and maintaining the history of the life cycle of all process instances.
An important concept that we need to discuss in detail while explaining BPMS is Human Interaction Management (HIM). The activities that form business processes can be broadly classified into automatic and manual. Automatic activities are those that can be completed by the software system without any manual intervention. For example, in a banking transaction process, the customer has to provide the details of the transaction, such as the bank account number to which the money needs to be transferred and the amount to be credited into this account. This is a manual activity. In contrast, if an SMS alert needs to be sent to the customer's mobile as part of this process, no manual intervention is needed; the software can fetch the mobile number registered with the customer's account and send the SMS automatically. An SMS alert is an automatic activity in the banking transaction process.
Therefore, human tasks are in fact human interactions in the business processes or, in a broader sense, human interactions with the software system in place. Usually, human activities are physical tasks that are performed outside the software system and the results or conclusions are then fed as input into the software system. Technically, from the perspective of the system, we can say that the associated human activities would provide an input to the business process and there would be scenarios where the business process would be able to continue only after manual decisions. For example, in a banking transaction business process, the customer has to provide a one-time password to continue the process.
A Human Interaction Management System (HIMS) should have the capability to handle the life cycle of a human activity, which includes notifying the users who are associated with the activity, collecting information or results from the users, and keeping track of the history of the tasks. The information collected from human interactions is used in process execution and decision making. jBPM has an in-built human task service and can be integrated with any other HIMS. The in-built human task service of jBPM is in compliance with the WS-Human Task specification.
jBPM also provides a form modeling feature that helps business analysts to design user interface forms that can be attached to the jBPM user task, using which information about the completion of the user task (if any) can be collected.
Business Activity Monitoring (BAM) provides online monitoring capabilities for business activities and enables businesses to arrive at key performance pointers by slicing and dicing the activity event data. BAM refers to a general software system that can monitor business processes, but attaching BAM with a BPM-based software system is relatively easy and powerful. In general, BAM software has the capability to show business data using dashboards, enabling business users to create customer reports and charts for performance indicators and trend analysis.
The jBPM core engine stores the process and task history and provides APIs to perform the BAM operations. Further, the jBPM tooling includes the dashboard builder, which enables its users to create custom dashboards from the business process history.
Consider a banking transaction process where a customer carries out a transaction from his/her account to another account. By analyzing the process history logs, the business user can create trend analysis reports of the peak hours of the day at which the maximum number of transactions took place. This analysis can be used to optimize related IT costs.
Another more frequent use case where BAM is applied is the optimization of a business process by avoiding process bottlenecks. Process bottlenecks can be caused by various problems including resource shortage (insufficient supply of staff) or a system not performing up-to-the-mark. A resource shortage problem would be quite obvious, but a system inefficiency may not be very apparent. For example, suppose that the One-Time Password (OTP) activity in a banking transaction process is often delayed. Let us say it takes more than one minute, which prompts users to perform the transaction again (or use the resend option) and leads to customer dissatisfaction. This also leads to wastage of resources by sending multiple OTPs; in other words, a delayed OTP confuses the customer and the bank further loses its credibility. Such issues are often noticed by banks when diligent customers notify them about the issues. BAMs can make the corrections of these issues more proactive, leading to increased customer satisfaction.
Business process simulation provides the business user with the ability to see how the business process model created by them would work during runtime. Simulation is a term that goes hand-in-hand with modeling. A model designer would really love to have a simulator to test his model and understand the runtime impacts of his/her model. Business process simulation is the capability to analyze the runtime behavior of business processes. It helps in the optimization of business process models for quality, performance, and resource utilization.
Comparing business process simulation with the more regular models of testing these processes, we find that the user has to manually test these processes after deploying them in a Quality Assurance (QA) environment. Further, for automated verification, the user would have to rely on a programmer to script the automated test cases. In both cases, the process of verification is not carried out locally with the modeling process and delayed results mean iterations for corrections, adding to the cost of process improvements.
Business process simulation provides business users with the ability to see how the business process model created by them would work during runtime. The users can provide the simulation information, which includes the input to the processes, interrupts, and resource information to be used in the simulation mode. While executing the simulation, the software collects the statistical information about the running process, and this information can be analyzed by the users to optimize their business model.
jBPM is an early adopter and implementer of the Business Process Simulation Interchange Standard (BPSim). BPSim provides a standardized specification that allows business process models to be analyzed using a computer interpretable representation or a meta model. Using jBPM, the end user can provide the metadata for simulation by using the process designer and execute simulations to view the execution paths and the performance metrics associated with the various execution paths.
Business Process Model and Notation (BPMN) is the widely accepted standard for business process modeling and provides a graphical notation for specifying business processes in a Business Process Diagram (BPD). It is based on a flowcharting technique very similar to the activity diagrams of Unified Modeling Language (UML). BPMN is maintained by Object Management Group (OMG), and the current version is 2.0 (released in March 2011).
The primary goal of BPMN is to provide a standard notation readily understandable by business stakeholders. These include business analysts who create and refine the processes, technical developers responsible for implementing these processes, and operation managers who monitor and manage the processes. Consequently, BPMN serves as a common language, bridging the communication gap that frequently occurs between business process design and implementation. BPMN also serves as a communication medium between organizations who partner for achieving common business goals, to share functional processes and procedures.
One of the main differences between BPMN and other process definition standards such as Business Process Execution Language (BPEL) is that BPMN supports human interaction. Human interaction support provides completeness to business process modeling, as humans are the primary actors in any business organization. Being a specification of visual programming notations, BPMN places considerable emphasis on diagrammatic representations of the elements of the business process model. So, a reader of a BPMN diagram can easily recognize the basic type of elements and understand the business process. BPMN conformance ensures a common visual representation, although it allows variations without dramatically changing the basic look and feel of the diagram.
The detailed explanation of the BPMN 2.0 specification can be found in the specification document.
BPMN specification documents can be found at http://www.bpmn.org/.
Conformance to standard BPMN specification defines four types of conformance:
Process modeling conformance: Tools claiming conformance must support BPMN core elements, human interactions, pools, and message flows.
Process execution conformance: Tools claiming conformance must support and interpret operational semantics and activity life cycle as stated in the specification.
BPEL process execution conformance: A special type of process execution conformance that supports BPMN mapping to WS-BPEL.
Choreography modeling conformance: Tools claiming conformance must support choreography diagrams and their elements. Choreography diagrams focus on the collaboration of different groups in activities and the message flow between them.
A jBPM implementation partially claims the first two types of conformance, namely process modeling conformance and process execution conformance. Although jBPM supports all core elements in process modeling, it does not support all the elements described in the specification.
The chief constituents of a BPMN diagram, BPMN elements, can be broadly classified into five categories:
Flow Objects: These objects define the behavior of a business process
Data: This represents the data associated in the business process
Connecting Objects: These objects are used to connect the flow objects to each other
Artifacts: These provide additional information about the process
Flow objects are the meat of BPMN; they are used to define how the business process would behave. The following are the major types of flow objects:
Events: An event is something that happens in the course of a business process. These events affect the flow of the model and usually have a trigger for and an impact on the business process. Some examples of events are Start, Stop, and Error. A Start event triggers the start of a process instance and is triggered using an explicit trigger, a message, or a timer. Events can be either signaled from a process (thrown) or can be waited upon (catch).
Activities: Activities are actions performed within a business process. They can be either atomic (called Tasks) or compound (Sub-processes). An example of an activity is a user task or a service task. A user task indicates a human interaction and the action has to be taken manually to complete this task. A task can be complete upon being triggered or can wait for completion (a wait state); for example, a service task is triggered and completed, while a human task is triggered and waited upon for a user to complete the action.
Gateways: Gateways are used as controllers for the branching, merging, forking, and joining of execution paths within a business process. An example is the parallel gateway, which can be used to split the execution path into multiple outgoing branches, with all outgoing branches activated simultaneously. Parallel gateways can also be used to merge branches; they wait for the completion of all incoming branches to complete before triggering the outgoing flow.
Business process execution results in the production of data; for example, in the banking transaction process, the transaction details are data provided by the user regarding the transaction. This data would have to be saved or transferred to another activity for further processing. The following elements are the core of data modeling in BPMN.
Data Object: Data objects are data created as part of a business activity. They can be used for informational purposes to indicate that the activity produces such data.
Data Input: Data inputs specify the input needed for an activity for its completion. For example, an OTP sending task in the banking transaction process would need the details of the customer to send the SMS. So, the input of this activity is mapped from the output of the previous activity or from data that is globally associated with the process instance.
Data Output: Data outputs are data resulting from an activity that have to be mapped to a global process variable or to serve as input to a subsequent activity.
Data Store: A data store provides a mechanism for activities to retrieve or update stored information that persists beyond the scope of the process.
Flow objects are connected to each other by using connecting objects. The following are the types of connecting objects:
Sequence Flows: A sequence flow is the basic element used to represent a connection. It is used to connect flow objects and defines the execution order of activities.
Message Flows: Message flows are used to represent information flow across organizational boundaries (a group of activities within an organization or a department, or a role of users).
Associations: Associations are used to represent the association of data or an artifact to a flow object.
Swimlanes are a visual mechanism for organizing and categorizing activities and form the basis of cross-functional charts using BPMN. They represent an organization, a role or, a system. They are basically of the following two types:
Pools: A pool represents the higher-level categorization of activities. For example, an organization can be represented as a pool. A pool consists of multiple lanes. An example of lanes would be the departments within an organization.
Lanes: A lane represents the categorization within the pool. The lane contains flow objects, connecting objects, and 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:
The banking transaction process is illustrated in the following diagram with the core elements of event, activity, data object, lane, and gateway annotated:
BPM is typically used in industries where the following is true:
The business process is distributed and spans across multiple applications or software systems
The process involves complex rules that have to be maintained and updated overtime
There is a need to continuously improve the business process by monitoring the existing activities
The business is done by the collaboration of multiple stakeholders
With the above considerations, we can apply BPM to any process-oriented domain, such as healthcare, insurance, point of sales, supply chain management, and banking and financial services. A fully functional BPM system gives a huge advantage in terms of the turnaround time for an organization with a new product/service offering or an improved process.
Considering the scope of this book, we can briefly detail some domains in the upcoming sections. A detailed study of these use cases is done in the subsequent chapters, and these use cases are used throughout the book for explaining each and every aspect of jBPM.
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:
Distributors: They distributes the product for sale to the retailers.
Customers: They buy and use the product. Therefore, a supply chain is a collaboration of multiple functional units, and these groups can be within the same organization or from different business units. Coordinating the jobs and meeting end user expectations in a cost-effective manner is a challenge and is attributed to supply chain management systems. As you can see, the domain is inherently process oriented, with a lot of complex rules and regulations governing each stage of the process, and this is a best-fit domain for applying complete BPM systems.
A few processes to name in the supply chain domain are as follows:
Manufacturing flow management: This deals with the manufacturing of products and/or provision of services
Order management: This meets customer requirements in terms of order fulfillment
Customer service management: This provides real-time information about product availability, shipping dates, and order status
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:
Account opening and maintenance
Payments and transaction processing
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.
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 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 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.
jBPM is an open source BPM suite with a complete tool stack supporting everything right from the modeling and execution to the management and maintenance of business processes. It was released under Apache License 2.0, and was developed and is actively supported by the JBoss community.
The tool stack focuses on serving the following two types of users:
Business users who model the application and use the application
Technologists who assist the business users to make the models executable and the application completely functional
The following diagram will give you an overall view of the jBPM tool stack and the set of functionalities that it provides. We will discuss in brief the functional components. Detailed discussions of each of these components will be presented in subsequent chapters.
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.
UberFire is a web-based workbench framework inspired by Eclipse RPC. It is plugin-based, and the runtime is a composition of UberFire-compliant plugins.
For more information, see http://www.uberfireframework.org/docs/.
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:
Discover: The business knowledge required to drive your company.
Author: Formalize your business knowledge.
Deploy: Learn how to configure your environment.
Work: Reduce the paperwork.
Improve: Enhance your business performance.
The knowledge life cycle shows the maturity of the JBoss community in providing ready-to-use, knowledge-based application development environments.
Process Designer is a web-based rich user interface that allows us to model BPMN2-compliant business processes. Its aim is to provide an intuitive workbench where both business and technical users can model and simulate executable business processes.
The output of modeling is executable business processes. Management tooling enables users to manage the execution of processes, monitor the execution, and report it.
jBPM provides web-based tooling for process management, monitoring, and reporting. Web-based tooling in fact uses the core engine APIs. These APIs are exposed via Representational State Transfer (REST), Java Message Service (JMS), and Contexts and Dependency Injection (CDI) interfaces so that they can be integrated with other enterprise software systems.
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:
Wizard for creating a new jBPM project
Graphical modeler for BPMN 2.0 processes
Runtime support (for selecting the jBPM runtime to use)
Debugging, the current states of the running processes can be inspected and visualized during execution
Process instance view, providing information showing all running process instances and their state
Audit view showing the audit log
Synchronizing with the Kie workbench repositories, enabling collaboration between eclipse tooling users and the web-based users
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:
Persistence storage for processes and related artifacts such as processes, rules, data models, and forms
Deploying selected processes
Authentication and authorization
Categorization and searching of knowledge artifacts
Scenario testing to make sure you don't break anything when we update processes
Features for collaborative development of business processes, such as comments and change notifications
It is also important to understand that jBPM is a part of a package provided by JBoss, the Business Logic Integration Platform (BLIP) that consists of the following:
Drools Guvnor (Business rules manager)
Drools Expert (Rule engine)
jBPM (Process Management)
Drools Fusion (Event processing/Temporal reasoning)
Together they form a complete solution for knowledge-based application development and management for enterprise solutions.
BILP can be visualized as a rapid enterprise application development platform from which applications can be solely built by modeling rules, business process flows, events, data models, and forms with very little help from the technical users. The technology and its tools have dual focus: they explicitly serve business users, enable these users to express requirements directly by modeling, and help to engage them in the application development process, guided by technical users who make the models fully functional and realize the software application with all its qualities (nonfunctional requirements).
BLIP integrates the following three paradigms in business language-driven applications:
These paradigms, although developed as three different streams, as obvious from the definitions itself, are interrelated in a business solution context. No wonder in most of the solution architectures, these three form the cornerstones of business modeling.
These paradigms are integrated into a unified platform, where all features of one module are leveraged by the other modules. The decision-making (from the knowledge base) capabilities in Drools Expert are used by Drools Fusion; the event processing capabilities of Drools Fusion can be used by the BPM suite jBPM; and jBPM uses Drools Expert internally for executing business rule tasks.
The following figure depicts this integration and the interactions between the modules in the platform. Drools Guvnor is used for designing processes, events, rules, and related artifacts; storing them; and providing integrated testing facilities. As an integrated platform, BLIP allows interactions between rules, processes, and events.
As depicted in the preceding diagram:
Drools Expert can start a business process or create events based on its rule inference
Drools Fusion can trigger rules or signal processes based on its temporal reasoning capacity based on the incoming pattern of events; and jBPM can trigger rules as one of its activities or generate events based on the business activity
We have already discussed the overview of jBPM; now, let us briefly discuss the other component in the platform in subsequent sections.
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 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:
Temporal reasoning, which allows the definition and inference of business rules based on time factor of events
Scheduling and delaying of actions to be taken on inferences
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.
The designer tools enable business analysts to map the business scenarios required for a solution to rules, processes, events, or related artifacts.
The applications/users can interact with the solution by using the operation management tooling provided by jBPM, or they can use the RESTful web service interface to access the same from their proprietary applications.
The runtime integrates the business processing, rule inference, and temporal reasoning capabilities to infer decisions and take actions for a business scenario.
The knowledge repository module provides storage, version management, deployment, and testing of the applications developed.
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.
The goal of this chapter was to give you a picture of the world of BPM. We explored the basic concepts, the standard, patterns, use cases where BPM is applied in the industry, and its benefits. We also explored the jBPM tool stack and the bigger picture of BLIP. These concepts and tools will be discussed in detail throughout this book.
In the next chapter, we will discuss how to install the jBPM tool stack and create our first business process-centric application using jBPM.