(For more resources on Oracle, see here.)
BPMN 2.0 concepts
BPMN stands for Business Process Modeling Notation and is a public standard maintained by OMG. It describes a business-friendly, flow chart-like graphical notation that business process analysts and business users can use to model business processes and has support for process interactions, exception handling, compensation semantics, and so on. It is widely accepted by both commercial and open source BPMS tooling vendors. It is highly adaptable and can be used to capture everything from abstract process outlines to detailed process flows to implementation ready processes. One of the main value propositions of BPMN besides being a diagram standard is the precise semantics behind the diagram. The shape, the symbols (also referred to as markers), the borders, the placement of the BPMN diagram elements, as well as their properties have well defined meanings and have to be interpreted in the same manner by all tools.
While BPMN 1.1 comprehensively addresses process modeling notations, it's failure to address an interchange format (for diagram exchange) has resulted in implementation vendors adopting different standards (BPEL, XPDL, other proprietary formats) to store BPMN process models leading to not only a loss of portability across tools but also making it difficult to communicate across the various stakeholders. The vision of BPMN is to have a single specification for notation, metamodel, and interchange. In addition, BPMN 2.0 has been expanded to include orchestrations and choreography of process models.
Salient enhancements to BPMN 2.0 are as follows:
- BPMN 2.0 includes both diagram interchange as well as model interchange (the interchange formats can be either XML or UML) enabling portability of BPMN models across tool vendors.
- Formal execution semantics for all BPMN elements—BPMN 2.0 can not only be used to capture process models but can be used as an implementation model as well. IT simply layers the process execution details on top of the business process model leading to effective business-IT collaboration. Historically, business process models developed by business people have been technically separated from the process representations required by systems designed to implement and execute those processes. Thus, there was a need to manually translate the original business process models to the execution models. Vendors used standards such as BPEL and XPDL to save as well as execute BPMN Process models. Such translations are subject to errors and the impedance mismatch made it difficult for the process model and the executable process to be in sync with each other, as changes were made to both during the process development life cycle. With BPMN 2.0, there is no translation involved and the model is the implementation as well.
- Defines an extensibility mechanism for both Process model extensions and graphical extension.
- Refines event composition and correlation.
- Extends the definition of human interactions and aligns BPEL4People with the BPMN specification.
- Defines a Choreography model.
A quick introduction to BPMN
At its heart, BPMN has only three main elements, also referred to as Flow Objects—Activity (rectangle), Events (circle), and Gateways (diamond). An Activity represents some work done; Gateway represents a decision point or parallel forking or merge or join; Event represents either a trigger generated by the process or received by the process (from external source or from some other part of the process).
These Flow Objects are linked by connections referred to as Sequential Flows. These Sequential Flows represent the chronological sequence of process steps. The preceding steps pass control to the following step(s) along the connection. The data is also passed along the connection flow.
The Activity can be either a Task (an atomic process step) or Embedded Sub- process (compound process step). The Embedded Sub-Process can be either expanded or collapsed and has access to the process data. BPMN 2.0 supports different flavors of Tasks, namely: User Task for a human step managed by the workflow component of the BPM run-time engine; Manual Task for a human step that is not managed by the BPM run-time engine); Service Task for synchronous system interactions; Send Task and Receive Task for asynchronous system interactions; Script Task for scripting needs; Call Task for invoking another BPMN process (process chaining). The different task types have different symbols or markers to visually distinguish them.
In BPMN, the lane objects are used to group activities based on the categories (can be human resources or system resources) that they are associated for better visualization purpose. In Oracle BPM Studio, the lanes are associated with the BPM Role object and the Performer of the User Task is automatically set to the BPM Role object associated with the lane.
The User Task is associated with Process Participants or Performers who represent the business users who need to carry out the User Task. The associated Task (work to be performed) is shown in the inbox of the assigned Performers when the User Task is triggered. The actual work is performed only when the Performer executes on his Task. The Task is presented to the Performers through a browser-based worklist application. In BPM Studio the Process Participant or Performer is a BPM Role object in the Organization model.
Oracle BPM Suite supports out-of-the-box workflow patterns. Workflow patterns allow users to declaratively specify approval chains, notifications, and escalation and expiration policies. This simplifies the process logic by encapsulating approval chains within reusable task components. It is always possible to model the approval pattern using simple Tasks, Gateways, and Events within the BPMN process—but for many processes it is more convenient to define workflow patterns as well as notification, expiration, and escalation policies as part of the user task definition. BPM Studio exposes these workflow patterns through six flavors of Interactive Tasks.
The User Task refers to the Single Approver pattern and the participant or assignee is the member of the Role associated with the BPMN Process swim lane. The Management Task refers to the sequential management pattern and there are multiple participants assigned to the Task in a sequential pattern. Further, these participants are based on the Management hierarchy defined as part of LDAP and have the notion of a starting participant as well as the number of levels to be traversed up the management chain from the starting participant. The Group Task refers to the Parallel Voting pattern and the participants are members of the Role associated with the BPMN Process swim lane. The tasks are assigned in parallel to the participants in this case and the task is completed when a percentage of defined voting outcomes are reached. The FYI Task refers to the notification pattern and the participants are based on the Role associated with the BPMN Process swim lane. The task is completed as soon as the work items are assigned to the Task Inbox of the participants. Finally, the Complex Task for complex patterns involving task chaining and in this case the participants are not tied to the BPMN Process swim lanes.
(For more resources on Oracle, see here.)
The Gateways are used for conditional data splits, conditional merge, parallel forking and parallel joins. The conditional data splits can be exclusive ( XOR Gateway—one and only one path can be taken) or inclusive ( OR Gateway—one or more paths can be taken. The XOR Gateway is used for exclusive conditional merges and the OR Gateway for inclusive conditional merges). The parallel forking (AND) is used to indicate parallel paths. The AND Gateway is also used for joining parallel paths.
The Events can occur at the beginning ( Start Events) or at the end (End Events) or in the middle (Intermediate) of the process. The Events can be of catch (receive trigger) or throw (send trigger) type. The Start Events are always of catch type and the End Events are always of throw type. The Intermediate Events can be either of throw or catch type. Similar to Activities, there are various flavors of Events to denote the type of trigger.
The Event Types are listed as follows:
- Message Events—send or receive messages
- Timer Events—are always of catch type and used to signify waiting for a specific time condition to evaluate to true
- Signal Events—are used for publish and subscribe of signals
- Error Events—are used for exception handling and they can occur only at the end of the process
- Termination Event—to abruptly terminate the process and can occur only at the end of the process
- Conditional Event—for rule-based trigger
- Escalation Event—has been newly introduced in BPMN 2.0 to handle escalation conditions
- Compensation Events—to handle compensation
There can be multiple End Events and the process completes only when all parallel paths complete. The exception to this is the Error End Event (as shown in the following figure). When the process encounters the Error End Event, it abruptly terminates irrespective of whether there are other parallel paths which are still being executed.
Sales Quote Process Flow
In order to analyze and optimize the business process, you need to create an accurate representation of the process with a model and then simulate how the process performs under different conditions. Oracle JDeveloper with the BPMN Editor extension is called Oracle BPM Studio. BPM Studio provides business user friendly process modeling and simulation. Using BPM Studio, a process analyst can model a business process including activities in the process, transitions between each activity, and roles associated with each activity. BPM Studio also allows the process analyst to define business rules and business indicators in the context of business processes. You can simulate processes based on certain assumptions to perform throughput analysis, to identify bottlenecks, and to determine the optimal resource requirements to achieve a specified SLA. The following details have to be captured before you design the process model:
- Process Flow: What are the sequence of steps in the Process Flow and how are they connected to each other?
- Process Participants: Who are the business users and groups responsible for the various human steps in the process?
- Business Data: What are the inputs/outputs of the various process steps and the process as a whole?
- Task Outcomes: What are the possible outcomes for the human steps (managed by a workflow engine)? Do these outcomes affect the flow of the process?
- Exception Paths: How to handle errors and external events.
The Sales Quote process flow for creation of Sales Quote process model is described below. The business process implements a solution for Sales Representatives to submit Sales Quotes and manage all the approvals within a particular Sales organization. A quick recap on the business process definition and its flow is detailed below:
- The Sales Representative receives a Quote in his/her Task Inbox. He/She needs to complete the Quote. This is a human step, the Sales Representative role is the participant (task performer) and the input as well as output data is the Quote.
- The next step is to review and approve the Quote by Business Practices role. This is a human step; the Business Practices role is the participant and Quote is the input as well as output data. The Business Practices Review step can have two possible outcomes:
- APPROVE: Quote is approved by Business Practices role.
- REJECT: Quote is rejected by Business Practices role.
- The APPROVE outcome continues the process on the forward going path.
- On the other hand, the REJECT outcome redirects the process to the Enter Quote Details step so that the Sales Representative can refine the quote and resubmit.
- If the Quote gets approved by the Business Practices step, it then has to get approved in parallel for the deal structure and the terms. The Approve Deal step is used for approving the deal structure of the Quote and the Approve Terms step is used for approving the terms of the Quote, respectively.
- The Approve Quote step is a human step executed by individuals belonging to the Approvers role. The input and output data is the Quote.
- The Approve Terms step is a human step as well, executed by individuals belonging to the Contracts role.
- Similar to the Business Practices Review step, the Approve Deal and the Approve Term steps can have two possible outcomes—APPROVE and REJECT.
- The APPROVE outcome for both Approve Deal and Approve Terms steps continues the process on the forward going path
- On the other hand, the REJECT outcome for one or both of these steps redirects the process to the Enter Quote Details step so that the Sales Representative can refine the Quote and resubmit.
- If both Approve Deal and Approve Terms steps have been approved, then the process proceeds to the Finalize Contracts step. This is a human step executed by an individual in the Contracts role.
- Finally the Quote data is saved.
- Quote is the only business data. Use the Quote.xsd provided with the sample.
This article provided a brief overview of the Business Process Modeling Notation (BPMN) concepts. It also described the steps involved in modeling the Sales Quote Process.
- Oracle Coherence 3.5 [book]
- EJB 3.0 Database Persistence with Oracle Fusion Middleware 11g [book]
- The Business Analyst's Guide to Oracle Hyperion Interactive Reporting 11 [book]
- Using Oracle Service Bus Console [article]
- Introduction to Oracle Service Bus & Oracle Service Registry [article]
- Oracle BPM Suite 11gR1: Creating a BPM Application [article]