Professional Documents
Culture Documents
BPMN
Business Process Modelling Notations(BPMN) was
Event
Start Event
Intermediate Event
End Event
Start Event
None Start event
Activity
Sub Process
Task
Sub Process
Transaction
Call activity
Event Sub Process
Sub Process
Gateway
Exclusive Gateway
Complex Gateway
Event-based Gateway
Inclusive Gateway
Parallel Gateway
Connecting Objects
Sequence Flow
Message Flow
Association
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 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
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.
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.