Modeling Exceptions and Exceptions Handling

Exceptions in process modeling indicate a problem has occurred and change the normal flow of the process. When an exception occurs in the process, the process execution stops at that point. There are two types of exceptions in the process composer: An error and an escalation. They are differentiated by their trigger.

To model exceptions and exceptions handling you create the following event types:

• Error end event, which you create in the process.

  The error end event triggers a WSDL fault that is defined in a service interface definition you have in your project.

• Escalation end event, which you create in the process.

  The escalation end event represents a business error that occurs in the process, for example an item runs out of stock in a purchase order process. The escalation end event has an escalation trigger which is associated with an XSD type. With the XSD type you define which information does the escalation end event transport from the place it is thrown to the place where it is handled.

• Boundary event, which you place on the boundary of an activity (automated activity, human activity, or sub-process) in your process model.

  The boundary event handles an exception that has occurred while the activity has been performed. A sequence flow connection starting from the boundary event shows how the process branches after the exception.

  With a special boundary event type, you can model technical errors for automated activities. A technical error is, for example, a system timeout, connectivity problem, program error, or misconfiguration.

An exception may occur on the following levels:

• Root process

  If the exception occurs in the root process, it is handled by a default handler at runtime and you model only the exception in your process. When the exception occurs, the whole process is suspended and an administrator can inspect the process.

• Referenced sub-process

  If the exception occurs in a referenced sub-process, it can be handled by a boundary event in the referencing process. In this case you model both the exception and the exception handling. You place the boundary event on the boundary of the sub-process flow object in the referencing process. The sub-process flow object represents the referenced sub-process.

  When the exception occurs, the whole process is suspended. Depending on the type of exception, the sub-process and the process may have the following behavior:

  • Critical exception

    If a boundary event can handle the exception, the sub-process is canceled and process execution continues from the boundary event. If no boundary event is available, the exception is handled by the default handler and the sub-process remains suspended. The root process is also suspended and an administrator can inspect it.

  • Non-critical exception

    If a boundary event can be found, the execution of the sub-process and of the root process continues. In addition, the processing of the root process continues from the boundary event. If no boundary event can be found, the execution of the sub-process and the root process also continues. In this case, the business log contains information that an exception has been thrown. There is no information about whether the exception has been caught or not.

• Embedded sub-process

  If an exception occurs in an embedded sub-process, it can be handled by a boundary event in the parent or root process. The embedded sub-process depends on the parent process and cannot be suspended alone but together with the surrounding process. Only an escalation exception type can occur in an embedded sub-process. You model both the exception and the exception handling. You place the boundary event on the boundary of the embedded sub-process, or on the boundary of a parent process up in the hierarchy.

• Activity

  If the exception occurs within an activity, you model only the exception handling because the exception is not visible outside the activity. You can place a boundary event on the boundary of a human and automated activity to show how the exception that has occurred while the activity was being performed is handled.

  Caution

  You can create a boundary event only for human and automated activities for which an exception or respectively WSDL fault has been defined.

An exception can also occur in a branch of a parallel process, during execution of a parallel for each loop or a sub-process. In this case the whole process instance is suspended until the exception is handled by a boundary event or by the default handler. If the exception is handled by the default handler, the process instance remains suspended and an administrator can inspect it.

An exception that occurs in the inner flow of a task is of type escalation and can be critical or non-critical. Depending on the type of the escalation in the inner task flow, you can create a critical or non-critical boundary event for the human activity to which the task is assigned. Critical and non-critical boundary events have different graphical representations on the boundary of the human activity. Exception types in human activities are the following:

• Critical escalation

  When the escalation occurs, the task execution is canceled and the critical boundary event handles the exception. The process continues from the critical boundary event and does not follow the regular flow out of the human activity.

• Non-critical escalation

  A non-critical escalation does not cancel the task execution and you can work on the task and complete it at runtime. The non-critical boundary event handles the escalation and the process continues from the boundary event. When the task is completed, another token of the process continues independently following the regular flow out of the human activity.

• Create the necessary events.

• Define the input mapping.

  Input mapping defines the information that the exception sends. For more information about mappings, see Defining Data Mappings .

• Define the output mapping.

  To make boundary events work, you define output mapping for them to show how information about the exception handled is used in the process.