Introduction to BPM Notation (BPMN)

A standard Business Process Model and Notation (BPMN) will give businesses an understanding of their business procedures in a graphical notation. It will communicate these procedures in a standard manner.

BPMN raises the bar from procedures being simple checklists. Instead of checking tasks off of a list, a business process can be a full blown procedure involving decisions and tasks completed by several people at the same time.

Bonita BPM raises the bar and takes the graphical process representation of BPMN and turns it into an online, web based software system. BPMN diagrams can be run by systems and individuals. The Bonita engine can integrate with existing software (both modern and legacy) and provide users with a consistent “inbox” of tasks to perform.

There are certain events that you’ll find that almost every process has.  After all, a process isn’t useful if it doesn’t do anything.  You will use these 2 event types on almost every single process you create.  Basically, you can either have a human do a task (which creates a task in their to do list) or you can have a computer do the task (which doesn’t show up in anyone’s to do list).

Pools

The pool is fundamental concept in Bonita. Each pool is a process – each process is a pool. As such, we will use the terms “process” and “pool” interchangeably in this book. What causes confusion is that a process diagram may contain several pools. However, in the Bonita execution engine, each pool gets installed and managed separately as a distinct .BAR file (more on this later). Each pool has a label and a version number – this is how the system can keep track of which process is which and can handle inter process communication with instantiated processes from previous versions currently running. The label is displayed on the far left side of the pool in the Bonita Studio. The version is displayed on the General tab below the diagram (See image 3.1). Image 3.1 – Pool Label and Version

You can see in image 3.1 a complete and functional (though not yet very useful) pool. In order for a pool to be executable, it must have a name, a version, at least one start event and at least one end event.

Basic Start and End Events

There are 5 different types of start events and 5 different types of end events. To get started with development in Bonita, you really only need to concentrate on the basic start and end events. One thing to clearly understand is that a process may have multiple ends. Not every path of execution needs to come to the same end event. This will make your process diagrams much more readable. When a objective is completed (e.g. travel has happened, has been cancelled, has been refused, etc.), simply place an end event after the completed event and the process will end. Simple processes will generally have only one start event. Other, more specific, start events will be covered in later lessons.

Image 3.2 Start Event

The start event (See image 3.2) is used for a manual process start. This process start could be triggered from a user clicking the start button in the Bonita BPM Portal or from another process executing a call activity. Either way, the process will begin execution from this point.

Image 3.3 End Event

The end event (See image 3.3) indicates the end of a path. There can be several of these within a pool. Depending on where they are the process may continue on. For example, if there are parallel paths running within the pool and one path ends, the process would then continue on the other path. If there are no other paths currently executing, the end event will end the process.

Human Tasks

Image 3.5 – Human Task

Human tasks (Image 3.5) are the visible portion of your process. A human task has a form that the user can interact with and needs to have a defined actor (the user to do the task). Generally, a human task will provide a simple task description and some variable data that the user must enter in. For example, a human task could be “Review Application” with a simple Yes / No radio box to indicate whether the application was approved or not. Human tasks touch on a couple of points that will be covered in more detail in later lessons and courses. For now, two tips to get you going:

1. An actor can be defined in the Actors area on the General tab (See image 3.6)
2. The user interface is defined in the Pageflow area on the Application tab (See image 3.7)

Image 3.6 – Human Task Actors Definition

Image 3.7 – Human Task Form Definition

Service Tasks

Image 3.8 – Service Task

Service tasks (See image 3.8) define the computer driven or automated portion of your process. The way Bonita BPM handles this is via “Connectors”. Connectors will be covered in more detail in the Introduction to Connectors Course. For now, think of connectors as a way to tell the computer to do some specific task. Specific connector implementation can be defined using the Connectors area of the General tab. Add a new connector and you will be presented with a dialog that lists all of the available connector definitions. Image 3.9 shows a connector to send an e-mail via SMTP.

Image 3.9 – Connector Definition Dialog

Call Activities

Image 3.10 – Call Activity

The call activity (See image 3.10) is used to call another process. The pool may be in the same process diagram or it may be in another. So long as the process has been installed on the Bonita BPM Engine, the call activity will be able to instantiate the process correctly. The process to call (and which version of that process) is defined in the General Tab (See image 3.11).

Image 3.11 – Call Activity General Tab  

Call activities depend on correct and specific labelling of processes and sub-processes. Much like calling a function or method within an object (for those who come from a programming background), if the subprocess is not named correctly, the call activity will fail. Once the process flow reaches the call activity, the parent process flow will stop and the flow will continue within the sub-process. When the sub-process completes, the process flow will return to the parent process. The whole point of a call activity is to make processes reusable. Parent processes can call sub-processes (or several sub-processes). These sub-processes could also be parent processes to additional sub-processes. By designing real-world processes in this way, simple processes can be strung together to create complex processes. As processes call sub-processes, there must be a mechanism in place to pass data from parent to sub-process and back again. This is accomplished by means of data mapping.

Abstract Tasks

Image 3.13 – Abstract Task

At the design phase of your process, an Abstract Task acts as a placeholder for tasks that need to be defined, but you’re not quite sure of the details. Abstract tasks allow you to keep up with your design schedule. You can go ahead and model the entire design without waiting for the every task detail to be established. It is basically a place holder (you will need to define it as a runnable task eventually). There are no problems when running a process that still has Abstract Tasks (they haven’t yet been completely defined and turned into a more specific task type). Because they are undefined, they will be executed as default service tasks and will not in any way alter or affect the rest of the process flows which values are already defined. No data will be changed and no form will be displayed to the user. So long as there is a sequence flow exiting the Abstract Task, the process will skip right over it.

Message Tasks

Message Tasks are the BPMN method of exchanging information. Message Tasks can send and receive (or “throw” and “catch”) messages. Messages can be used for inter-process communication or between pools.

A common point of confusion is mistaking message tasks as emails.  While Bonita BPM does allow emails to be sent and received, this is done using connectors – not Message Tasks.  Message Tasks were specifically designed to communicate within the studio – generally to pass variable information from one pool to another.

 

To really understand Message Tasks, you need to have a basic concept of how data management works within Bonita BPM.  This is covered in more depth in the Using Data in Bonita Course.

Image 3.14 – Data Subtab

As a simple example, let’s consider a single item we need to keep track of, the client’s name.  We could store the client name in a text (or string) variable called clientName.  In the first pool, we add the variable to the “Data” subtab of the “General” tab.

Image 3.16 – New Variable Dialog

Once this variable has been defined, we can send a message from one pool to another (or even the same pool) to populate the data.  The message contains several critical items to identify it uniquely so that the message is delivered to the correct place.  Specifically, a message requires the following:

1. Name – this must be unique within the pool
2. Target Pool – the pool which contains the receive message task
3. Target Element – the name of the receive message task

In order to pass data, we must also create message content for each variable to pass.  Content items are defined in the table in the Add Message dialog.  The left column contains the content item name, the right column contains the content item value (generally a reference to a variable).

Image 3.17 – Add Message Dialog

Transitions / Sequence Flow

Transitions or “Sequence Flow” are a method of indicating which tasks are executed in what order. By using simple lines and arrows, we can see the behavior of the process segment by segment.

Arrows are used to connect all objects in the diagram from the start of the process all the way to the end.

Because there are many transitions in each pool, it is important that each Transition is properly labeled, more specifically with Conditional Transitions. Users could get confused with a certain Transition since similar conditions may be set in other pools.

For example, instead of saying “A, 1, I” or any less-identifying labels, be specific of the transition being taken. If the transition means using “Airplane” then write “Airplane”.  If “Red” then “Red”. If “None” then “None”.

Conditional Transitions

Conditional Transitions are those which need to be evaluated first to meet a desired outcome given varied state of the process flow. Bonita studio allows flexibility in designing the process, evident by allowing the users to define the criteria of one output or input before proceeding to an input or an output. More of this shall be discussed later.

A condition can be specified within the studio into an Expression, a Decision Table, and declaration of it as a Default Transition.

Sequence Flow  

Process always follows this path. The Sequence Flow (see Image 3.15), represented by a single arrow, should start and end with only one process.  It can begin with a “diamond” or “slash” when talking about conditions.

 

Image 3.15   Conditional Sequence Flow

Conditional Sequence Flow is an expression associated with transition. The transition is taken only if the condition is evaluated with the criteria TRUE. It is represented by an arrow with diamond at the beginning.

Image 3.16   Default Sequence Flow

Process follows Default Sequence Flow only if all other flows are evaluated as “FALSE”. It is represented by an arrow beginning with a slash.

Image 3.17

Parallel Gate

Image 3.18  – Parallel Gateway

In Parallel Gateway, all inputs before a specific step should be satisfied first, regardless of the order, for the process to continue. In the image below, Step 1 and 2 should deliver their input to the parallel gateway first before the process continues to Step 3.

Image 3.19 – Parallel Gate Input  

Image 3.20 – Parallel Gate Output  

The same thing goes for the output of Parallel Gateway. Once the flow reaches the gateway, in this case Step1, the next steps will be executed simultaneously.

If Step2 in this case is a human activity, then the person assigned to it should perform his task, simultaneous with Step3 which could be a service task for example, which would run automatically.

Exclusive Gate

Image 3.21  

In Exclusive Gateway, as soon as one of the inputs is delivered, the output will go on with its process.

Image 3.22 – Exclusive gateway input

In the image above, we can see that Step1 delivered to the Exclusive Gateway, this makes Step2 automatically out of the whole process. The system does not care about Step2 anymore and will continue with the process to Step3.

If there are people working on Step2 or if there is an intention to execute Step2, their performance will be disregarded by the system. The ongoing process on Step2 will be halted.

Image 3.23 – Exclusive gateway output  

On the other hand, Exclusive Gateway Output requires conditions. In the image above, we can see that there are 3 Steps to choose from. Each step has different conditions represented by a, b, and c. The system will only choose from conditions which have “true” value.

Image 3.24 – User Specifies the transition order  

If there are two or more conditions, they will be evaluated according to how the system was ordered, which can be manually done in the studio. The first among the conditions with “true” value will be the one chosen. Thus, Step2 is chosen and Step2 and 4 are disregarded.

Inclusive Gate

Image 3.25 – Inclusive Gate

You can have multiple output transitions. All outputs which have “true” value are all taken. The same is true with output transition which has no condition attached to it. If there is a default condition, the system will only be taken if there are no other conditions existing.

Image 3.26 – Exclusive gateway output

Implicit Gate

BPMN notation allows having Implicit Gateways. We can say that Implicit Gateways can interpret activities by just using transition arrows. Notice how links are interpreted as “Exclusive” and “Parallel then Inclusive” in the next images (Images 3.26 and 3.27 ) If you don’t have a gateway but you have activities linked together the flow of the process becomes as follows:

Image 3.26 – Implicit gateway input  

Image 3.27 – Implicit gateway output  

Best Practices

Following the standards set by BPMN is essential to have uniformity when implementing processes and interpreting designs. But the most important thing to remember is to achieve desired outputs even if that would mean not following all the standards.

In Bonita BPM, there are times when some practices may not be the same as what others in the BPM community is doing. But as long as your organization gets to communicate the whole process effectively, it won’t matter a lot.

Below are some of the Best Practices we have discovered:

1. The goal is always to make sure you can hand your process design to somebody else and not have to sit with them and explain everything.
2. Label Exclusive gateways with a yes/no question, and label the outgoing sequence flows yes and no. It makes reading your diagrams and process flows a lot easier.
3. Focus on readable diagrams; it doesn’t affect the execution.
4. Explicit gateways give you a lot of opportunities to be clear about what’s happening about the process.
5. State your assumptions anywhere you can.
6. When using Exclusive gateways, always define a default sequence flow. Avoid situations where your multiple outputs have “true” values. It is allowed by the system and BPMN 2 but it’s better to do away with that.

Image 3.28 – Example of Exclusive Gateway with Conditional and Default Sequence Flow  

In the image above, the default is labeled as “none”, which means the person does not take a train or an airplane. Please refer to “Best Practices” number 6.