Explaining Boundary Events in the Delivery and Purchase Order Process

In Business Process Modeling Notation (BPMN) 2.0, there are special types of events called boundary events. These types of events are triggered from outside the process or when something does not go according to the plan of the process while performing a human or automatic activity. When an exception is thrown by an activity, the process flow stops the normal process execution and follows an alternative path, as defined by the outgoing sequence flow of that particular boundary event. The boundary event and an end event are both represented with a thick-lined circle.

With a boundary event, you can define how to deal (that is, catch the exception) with exceptional situations when they arise at runtime in the process flow. Boundary events are a must have when using automated activities in your business processes. They allow you to perform exception handling after an application or technical exception has occurred. You can configure a boundary event to automatically handle exceptions thrown by automatic activities. You can do this by binding boundary events to fault message types defined in your web services definition.

Typical examples of application exceptions are functional errors and wrong input or output inside business rules. Technical exceptions, on other hand, are timeouts, authentication issues, network-related issues, and so on. For those of you with a software programming background in Java or C#, you can compare it with a TRY/CATCH exception block.

A boundary event has a single outbound sequence flow and is connected to the boundary of an activity. The outbound sequence flow of a boundary event indicates how the process should continue or recover after an exception has been detected.

In the figure, Boundary Event Types, an escalation event is triggered if the employee does not complete his task by the set deadline. The outgoing sequence flow of this boundary event goes into a notification task, which sends a reminder email to the employee. In a real-life scenario, we recommend that you add a condition (for example, a max of three reminders, and then exit the loop) that prevents an endless loop situation like the one in this example.

When looking at boundary events from a specific human task context, they represent situations in which the execution of a human task can fail or terminate in error. The exceptions are generally generated as a result of one of the constraints set by the task’s attribute settings (such as start deadline, activation time and so on) not being met. The exceptional or erroneous situation in a human task can be categorized as follows:

• Critical Exceptions

  The task processing is canceled, and the corresponding boundary event should catch and handle the exception.

• Noncritical Exceptions


  The task processing is not canceled and carries on its processing normally from the noncritical boundary event.

These are the possible exception types:

In the purchase order process, you can use two boundary events as follows:

1. An escalation boundary event

2. Error boundary event

In the exercise, Assign the Procurement Process to the Purchase Order Process and Assign Boundary Events, you will use boundary events to ensure, that only one branch is performed by the Advance Adapter Engine Extended (AEX). To use boundary events, you choose a referenced process object and from the properties tab, you choose the Boundary Events Editor.

With this editor you can add a boundary event. You will add two boundary events. An escalation one and an error boundary event. The Escalation boundary event is used, to start the activities to inform a customer about a late delivery. In the error case, the activities to inform the customer, that no delivery is possible are started.