Show TOC

Procedure documentationModeling Exceptions and Exceptions Handling Locate this document in the navigation structure

 

Exceptions in process modeling indicate a problem that occurs and changes 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.

Exception Occurrences

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 branch which created the exception in the sub-process ends and processing continues from the boundary event. If no boundary event can be found, the sub-process remains suspended and the root process is also suspended. The default handler handles the exception and an administrator can inspect the process.

  • 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 Caution

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

    End of the caution.

An exception can also occur in a branch of a parallel process or 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.

Exception Types in Human Activities

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.

Steps to Make Exceptions Work

To make exceptions work, you do the following:

  • 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.

Prerequisites

  • You have opened the Process Development perspective in the SAP NetWeaver Developer Studio and have expanded your project in the Project Explorer view.

  • You have created the necessary triggers for the error end or escalation end events. For more information, see Creating Reusable Event Triggers

Procedure

Modeling an Exception in a Process with an Error End or Escalation End Event
  1. Expand Process Modeling, then expand Processes.

  2. In the context menu of a process, choose Open.

  3. Expand Flow Objects from Palette.

  4. Select Error End or Escalation End from the end events dropdown list and click the modeling surface to place the end event in the process.

    Alternatively, you can drag a fault or an escalation trigger from the Project Explorer view to the modeling surface, to create an end event with the respective trigger assigned to it.

  5. On the General tab page in the Properties view, specify a name for the error end or escalation end event in the Name field.

  6. (Optional) Specify a description of the error end or escalation end event in the Documentation field.

  7. On the Event Trigger tab page in the Properties view, select an event trigger from the Trigger dropdown list to change the default trigger that is assigned.

    The trigger type is preselected depending on whether you model an error end or an escalation end event.

  8. On the Input Mapping tab page in the Properties view, define the input mapping for the error end or escalation end event.

Creating a Boundary Event to Handle an Exception
  1. Expand Process Modeling, then expand Processes.

  2. In the context menu of a process, choose Open.

  3. Select an activity (automated activity, human activity, or sub-process) in the modeling surface and open the Properties view of the activity.

  4. On the Boundary Events tab page, choose the Add... pushbutton.

  5. In the dialog box that appears, select the exception for the boundary event to handle. Choose the OK pushbutton.

    The boundary event appears on the boundary of the activity you selected.

    Note Note

    You can select more than one exception from the list. For each exception a separate boundary event appears on the boundary of the activity. Boundary events have different graphical representations, depending on whether they catch an error end event or an escalation end event.

    End of the note.
  6. On the General tab page in the Properties view of the boundary event, specify a name for the boundary event in the Name field.

  7. (Optional) Specify a description of the boundary event in the Documentation field.

  8. On the Output Mapping tab page in the Properties view, define the output mapping for the boundary event.

After creating the boundary event, you create an outgoing sequence flow connection from it to show how the process continues when an exception occurs. For more information about sequence flows, see Connecting Flow Objects in a Process.