In BPMN, there is a set of core elements that has been defined in a business process diagram, allowing users to start creating the essential gist of a process. These core elements can be further elaborated to take care of the complexities, while still maintaining the standard look and feel of the diagrams.
Core elements are subdivided into five categories, each of which contains a specific set of elements:
- Flow objects
- Connecting objects
- Sequence flows
- Message flows
- Data associations
- Data objects
- Data inputs
- Data outputs
- Data stores
- Text annotations
Flow objects consist of the backbone elements in a business process diagram and are used to represent the basic behavior of any process. These elements are events, activities, and gateways.
Figure 1: BPMN flow objects
Events represent the various states relevant for the business process, such as the start of the process, wait time in a process, termination of a process, and so on. Activities denote the work conducted as part of the business process. Gateways are used to represent the decision points where a split or join takes place in the flow of control.
Swimlanes represent the organizational relationships within a business process diagram. Pools usually represent the organizations that interact in a business process, while lanes denote the various departments within an organization.
For modelers who want to create an overview business process for their readers, use of the core elements of BPMN should be enough.
Deeper analysis of BPMN elements
Having looked at the core elements of BPMN from an understanding perspective, it is now essential to understand the various elements in detail and see what extensions BPMN provides to each of the elements to create truly illustrative and complete business process diagrams. Business analysts will realize that BPMN, apart from allowing easy process building, also provides sufficient detail and variety to allow a modeler to capture the complexities of real-life processes. It is also essential to understand how understanding these elements in detail will help the designers of business process and the respective IT teams later on to provide enough detail in a process to allow successful mapping from the process design to its execution in a BPM engine. Let's understand in some detail the main BPMN elements.
Events play a vital role in modeling with BPMN. The comprehensive coverage of events makes BPMN more appropriate as a business modeling language than its counterparts. Events, as we have discussed, define how an organization will respond to a situation through its business processes. Events will usually trigger a flow or will generate a result. Events can trigger-start a particular process, for example, the customer application form received event starts the opening a bank account process. Alternatively, it could be an intermediate event used to delay the execution of the process, for example, an event of wait five seconds prior to the send response to customer activity. Finally, it could be an end event, say account open complete, which completes a given process. So, depending on where an event occurs in a process, we can divide them into three types:
- Start: This indicates the start of a process
- Intermediate: These are events that occur in between a process
- End: This is an event signifying the end of a process
Events come in two flavors—catching and throwing events:
- Events that catch a trigger are event consumers or event sinks. All start events and some intermediate events are catching events.
- Events that throw a result are event producers or event sources. All end events and some intermediate events are throwing events. Events that are thrown may be caught by another event that catches a trigger.
Furthermore, events can be interrupting or non-interrupting. An interrupting event will interrupt the activity which it is attached to, while a non-interrupting event will happen while the activity is still going on.
Events are further represented by types (none, message, timer, error, cancel, compensation, conditional, link, signal, multiple, and terminate).
Simply put, an activity denotes a unit of work that is performed. Activities act as the major components. A series of activities undertaken in order to achieve an objective with clear starting and stopping points is a process. From a process perspective, any activity can be categorized as atomic or compound. An activity would be an atomic activity or task if it cannot be further decomposed, and performs a single atomic action. On the other hand, conduct interview would be a compound activity or a subprocess if it involves several subactivities, for example, analyze resume, ask questions, analyze answers, decide next steps, and so on, to get the work done. In a process diagram, the representation of a process is hierarchical in nature, that is, a given process can have multiple subprocesses. This also allows the process modeler to organize complex business processes in a decomposed fashion, affording easy maintenance and navigation. Any given business process diagram can contain three types of activities: process, subprocess, and task. In BPMN, subprocess and task are represented as rounded rectangles. The activity notation changes with the type of activity and what happens within that particular activity.
In a parent process, a given subprocess will be represented with a plus sign inside the rectangle. This is also called the collapsed process, with a plus sign denoting that the given activity is further elaborated in a separate diagram. This can be seen in the following figure:
Figure 2: Subprocess
The collapsed process could be represented as an 'expanded process', which requires the details of the subprocess to be made available inside the given activity rectangle. Typically, depending on how a modeling tool implements this feature, it is either initiated by clicking on the plus sign or navigating to the subprocess. This can be used to flatten the process diagram to show the details for a process in a single diagram. This makes it easier to visualize the complete process. However, in some practical scenarios, a large diagram could be too cluttered if represented by expanding all subprocesses. The use of expanded subprocesses is also beneficial while visualizing exception flows and provides context to a set of activities inside a subprocess.
Further, a subprocess can have:
- The collapsed subprocess: This is represented with a plus sign. The collapsed subprocess marker can be used in conjunction with any of the four other markers.
- The loop marker: A subprocess with a loop is represented using a curled line with an arrowhead.
- The multiple instance marker: A subprocess with multiple instances is represented using two parallel lines. This marker cannot be used in conjunction with the loop marker.
A subprocess can also be divided into two types:
- The dependent or embedded subprocess: A subprocess is said to be embedded when the parent process spawns the subprocess. In this case, the subprocess is dependent on the parent process for initiation. The embedded subprocess will usually contain basic BPMN constructs, such as activities, flow control, and gateways.
- The independent subprocess: In this case, the subprocess is a complete business process in its own right. The called process is independent of the calling process and hence can be called by any process.
A task is the atomic unit used to represent an activity. We use a task when we cannot break down a process activity into a lower level of detail. Typically, a task is a piece of work done by either an application or a user during execution of the process.
Based on the kind of work involved, a task can be further divided into various types. The task types are as shown in the following table:
Service: This is a task providing some kind of service; it could be a web service or an application.
Receive: This is a task expecting to receive a message from an external participant in a process.
Send: This is a task that sends a message to an external participant.
Business rule task: This is a business rule in a rule engine that helps to determine a decision in the process flow.
Script: This is meant to run a specific script by the execution engine. This kind of task will allow an implementer to specify a script to be run when the task is executed. The task is considered complete when the script has been run.
Figure 3: Tasks
User: This is a workflow-type task, where a user is supposed to perform an activity using an application. It can be also called a semiautomated task.
Manual: Typical manual activities, such as agent shreds the document. These tasks are performed without any help from an application or a BPM engine.
Figure 4: Tasks
In addition to standard BPMN tasks, BPM Suite provides some extra tasks, such as notification tasks to send notifications via e-mail, SMS, and so on. It also provides update tasks to update user (human) tasks.
Gateways are used to control how flows interact as they converge and diverge within processes. In basic terms, gateways are like decision junctions where a particular flow decides to fork into multiple activities or join/merge back into an activity. Depending on the kind of behavior we want to control at a gateway, BPMN allows their representation as an open diamond with options to use markers to differentiate between various gateway types. Gateways can also be interpreted as if-then or switch constructs, which are typically used in programming control structures.
Sequence and message flows
The sequence flow represents the order in which activities are performed in a process. If you use a sequence flow to evaluate a condition before moving on to the next activity, then you use a conditional sequence flow. These are represented by a diamond at the start of the sequence flow, as can be seen in the following figure:
Figure 5: Conditional sequence flow
If you want to represent a default path among a set of options, especially in the case of decision gateways, a default sequence flow should be used. The marker used is a backslash at the beginning of the line, as follows:
Figure 6: Default path
We represent message flows between two participants in a business process using a message flow element. In BPMN, two pools or swimlanes represent two participants involved in a process. For example, the finance department and the human resources department are participants in a process. Interaction between these departments would be depicted using message flows. A message flow must connect two pools or swimlanes or connect flow objects in one pool to flow objects in another. You cannot have a message flow connecting two objects in the same pool.
Message flow is denoted by a dashed line with an empty arrowhead and beginning with a small open circle, as follows:
Figure 7: Message flow
A message flow can be from a flow object within one pool to a flow object in another pool. This is important mostly when depicting how the activities will send and receive messages from participants.
Pools and lanes
A pool depicts the participants in a given process. It allows the swimlane concept to be used in the diagram. The participants in an organization can be different internal departments. In a B2B process, they can be two organizations themselves, or from an SOA point of view, they can be different service providers or consumers. We will typically use a pool in our process diagrams to group various activities performed by different participants in a process.
In a given pool for a process, you may require demarcation of various activities, allowing further organization and categorization to provide greater clarity to the process users. A lane is used to do just that. It is used to subdivide a pool into multiple sections. For example, you might divide a pool representing a loan department into activities performed by the various roles within the department, such as customer service representative, underwriter, and so on. Or alternatively, if the pool represents a company in a collaboration process, lanes can be used to represent various departments within the company.