BPMN DIAGRAMS

BPMN
Business Process Modelling Notations(BPMN) was

created to represent work processes in diagrams that

are readily understandable by business people
Yet are rich enough in detail to allow IT departments to
translate process maps into technical specifications
Serve as bridge between process participants and the IT
staff that build systems
There are four core shape types
Events,
Activities,
Gateways and
Connecting objects

- with multiple variations of each

Event
Start Event
Intermediate Event
End Event

Start Event
None Start event

Interrupting - Message start event

Interrupting - Signal start event

Non-Interrupting Signal start event

Non-Interrupting - Message start event

Interrupting -Multiple start event

Interrupting - Timer start event

Non-Interrupting - Multiple start event

Non-Interrupting -Timer start event

Interrupting Parallel Multiple start event

Interrupting - Conditional start event

Non-Interrupting - Conditional start event

Interrupting - Escalation start event

Non-Interrupting - Escalation start event

Non-Interrupting Parallel Multiple start event

Interrupting Error start event

Interrupting Compensation start event

Activity
Sub Process

Task

Adhoc Sub Process

Sub Process
Transaction

Call activity
Event Sub Process

Sub Process

Collapsed Sub Process

Expanded Sub Process

Gateway
Exclusive Gateway

Complex Gateway

Exclusive Gateway -with Marker

Event-based Gateway

Inclusive Gateway

Event-based Gateway to start

a process

Parallel Gateway

Parallel Event-based Gateway

to start a process

Connecting Objects
Sequence Flow
Message Flow
Association

Book Lending Example

Order Processing with Collapsed

sub process

Sub process activity

Expanded Sub Process

In this example our Order Process is depicted with a collapsed Call Activity
Approve Order. This diagram is quite different than the previous example, as
here we are introducing the notion of Process re-use. In this case, the Approve
Order is not a Sub Process of Order Process but separate independent
process that is called (re-used) within the Order Process.
Order Process with Collapsed Call Activity

The Approve Order Process

Order Fulfilment and Procurement

This order fulfilment process starts after receiving an order message and
continues to check whether the ordered article is available or not. An
available article is shipped to the customer followed by a financial
settlement, which is a collapsed sub-process in this diagram. In case that an
article is not available, it has to be procured by calling the procurement sub
process. Please note that the shape of this collapsed sub-process is thickly
bordered which means that it is a call activity. It is like a wrapper for a
globally defined task or, like in this case, sub-process.
Another characteristic of the procurement sub-process are the two attached
events. By using attached events it is possible to handle events that can
spontaneously occur during the execution of a task or sub-process. Thereby
we have to distinguish between interrupting and non-interrupting attached
events. Both of them catch and handle the occurring events, but only the
non-interrupting type (here it is the escalation event late delivery) does not
abort the activity it is attached to. When the interrupting event type triggers,
the execution of the current activity stops immediately.

Order Fulfilment and Procurement

The process for the stock maintenance is triggered by a conditional start event. It
means that the process is instantiated in case that the condition became true, so
in this example when the stock level goes below a certain minimum. In order to
increase the stock level an article has to be procured. Therefore we use the same
Procurement process as in the order fulfillment and refer to it by the call activity
"Procurement", indicated by the thick border. Similar to the order fulfillment
process this process handles the error exception by removing the article from the
catalog. But in this stock maintenance process there appears to be no need for
the handling of a "late delivery" escalation event. That's why it is left out and not
handled. If the procurement sub-process finishes normally, the stock level is
above minimum and the Stock Maintenance process ends with the end event
article procured.

Procurement sub-process
We now zoom into the global sub-process procurement that is used by both order fulfillment and stock
maintenance. Because this is a sub-process, the start event is plain, indicating that this process is not triggered
by any external event but the referencing top-level-process.
The first task in this sub-process is the check whether the article to be procured is available at the supplier. If
not, this sub process will throw the not deliverable-exception that is caught by both order fulfillment and stock
maintenance, as we already discussed.
In case that the delivery in the Procurement process lasts more than 2 days an escalation event is thrown by
the sub process telling the referencing top-level-process that the delivery will be late. Similar to the error event,
the escalation event has also an escalation Code which is necessary for the connection between throwing and
catching escalation events.
Contrary to the throwing error event, currently active threads are neither terminated nor affected by the
throwing intermediate escalation event. Furthermore, the Procurement process continues its execution by
waiting for the delivery.
But the thrown event is handled by the nearest parent activity with an attached intermediate escalation event
which has the same escalation Code as the thrown escalation event. In the order fulfillment process, the "late
delivery" escalation event attached to the Procurement sub-process catches the thrown "late delivery" event.
But now, the event is a noninterrupting event. Because of that a new token is produced, follows the path of the
escalation handling and triggers the task that informs the customer that the ordered article will be shipped later.
When the procurement sub-process finishes, the Order Fulfillment process continues with the shipment of the
article and the financial settlement.

Procurement sub-process

The Leave Application Process Example

In this case, the BPMN has a pool which represents the participant, ABC Company. Within
the pool, there are multiple lanes in which each of them consists of a participant of the
company. There are altogether three participants in this ABC Company, the employee, the
manager as well as the HR.

In order for the process to initiate, something must be happened, that is, an employee in this
company wants to take a leave. So, on the diagram, the start event symbol is drawn on the lane
labeled Employee to indicate the start. Then, a solid arrow is linked from the start event symbol to
a task symbol to indicate the process flow direction and to show that the first thing the employee
needs to do is to fill in the leave application form. After that, he has to submit the form to the
manager for approval.
From here, the manager is responsible for the process, so, we link the task Submit Leave
Application For Approval to another task event Evaluate Leave Application on the Manager lane.
After the manager received the application, he will evaluate on it in order to decide whether to
approve the leave request or not. At this point, since there are two possible results, either approve
or decline, a gateway symbol is drawn on the diagram to diverge the process into two ends. That is,
if the application is rejected, the manger will need to inform the employee and the application
process terminates. So, the task Inform Employee The Request Is Declined is connected to an end
event symbol. On the other hand, if the application is accepted, the manager will inform the
employee and the application process will continue to follow to the lane of HR where he needs to
manage the application.
Finally, what is left in the process is for the employee to take the leave. The end event symbol is
connected to the last task Take the Leave to indicate the whole process completes.

The Leave Application Process Example

Loan Request Process

The Loan Request Process handles the necessary activities to receive, analyze
and approve loan applications submitted by customers of a financial entity.
A simplified version of this process consists of a couple of activities. First, a
customer submits a loan request together with the required documents, then, the
information submitted is verified and the application is studied. Finally, the amount
of the loan is disbursed, if approved.

Collaboration diagrams depict the interaction between two or more processes. Usually they contain
two or more pools to represent the collaboration performers.
Lets take the parallel processes performed by a company and its suppliers when a purchase is managed.
Each performer carries out independent processes, however, those processes constantly interact by
changing information (calls, emails, faxes, etc.) and no one will finish without the information given by the
other. The next diagram shows this situation:
The process is started by the company which receives a purchase request from a department. When
accepted, the request starts the Quotations sub-process .
This sub-process manages the necessary activities to receive and evaluate quotations of the requested
products in order to select a supplier.
Once the supplier has been selected, a purchase order is sent, this is depicted through a Message Event.
In Collaborative diagrams, the information flow between processes is represented through message flows.
The message event activates the message and the outgoing dotted line that you see in the diagram is a
flow line. This line connects two message events to relate them to each other. Note that in the diagram the
Send Purchase Order Message Event is related to the Receive Purchase Order Start Message Event The
last one will start a process instance for the supplier process once the purchase order is received.
The supplier starts a flow to process the company order and sends the products of the order and their
invoice. This is depicted through the Send Invoice Message Event. In parallel, the company waits for the
invoice and the products. The Receive Invoice Message Event waits for the invoice while the Receive
Products none intermediate event is enabled so that it can be manually executed once the order is
received. Such events are enabled in parallel thanks to the parallel gateway. In order to ensure the
company process does not continue until the invoice and the products of the order are received, a parallel
gateway is used to merge active flows. Finally, a service task processes the supplier payment and sends a
payment confirmation, again, using message events and flows. Once the confirmation is received by the
supplier both processes finish.

The Pizza Collaboration

If we step through the diagram, we should start with the pizza customer, who has noticed
her stomach growling. The customer therefore selects a pizza and orders it. After that, the
customer waits for the pizza to be delivered. The event
based gateway after the task order a pizza indicates that the customer actually waits for
two different events that could happen next: Either the pizza is delivered, as indicated with
the following message event, or there is no delivery for 60 minutes, i.e., after one hour the
customer skips waiting and calls the vendor, asking for the pizza. We now assume that the
clerk promises the pizza to be delivered soon, and the customers waits for the pizza
again, asking again after the next 60 minutes, and so on. Let's have a closer look at the
vendor process now. It is triggered by the order of the customer, as shown with the
message start event and the message flow going from order a pizza to that event. After
baking the pizza, the delivery boy will deliver the pizza and receive the payment, which
includes giving a receipt to the customer.
In this example, we use message objects not only for informational objects, as the pizza
order, but also for physical objects, like the pizza or the money. We can do this, because
those physical objects actually act as informational objects
inherently: When the pizza arrives at the customer's door, she will recognize this arrival
and therefore know that the pizza has arrived, which is exactly the purpose of the
accordant message event in the customer's pool. Of course, we can only use the model in
that way because this example is not meant to be executed by a process engine.

Ordering and delivering pizza