Outlining Start and End Events for the PO Process

The events in the process have different triggers and results, and effect the flow of the process. You use events to indicate that a process has started or ended, or that the flow is delayed and is waiting for a certain time before resuming. You can also use events to represent the interaction between different processes.

To model events, perform the following high level procedure:

1. Create the event.

2. Assign a trigger to the event or configure the trigger time for intermediate timer events.

3. Use triggers to indicate the reason for an event to occur (for example, a message or an exception).

4. Define a start condition for a message event and a correlation condition for an intermediate message event.

Start conditions are defined for start message events to specify which messages can start a process. The start condition compares the payload of an incoming message to a predefined constant. For example, a start condition is configured to begin a process when an order for 10,000 units or more is received. When an order is received with a value of 10,000 or more, then the process begins. If the incoming order is less than 10,000 units, then the process does not start. You can also use the default value True, which means that any message can trigger the start event. Start conditions can be configured in great detail.

If you use intermediate message events in your process, you have to configure correlation conditions for them. A correlation condition matches an incoming message to the process context and evaluates which particular message the intermediate message event expects.

In contrast to other conditions, correlation conditions can only consist of equality predicates with the conjunction operator AND. The following example shows a correlation condition:

event/customerID = process/customerID AND event/orderItem = process/orderItem AND event/type = "ORDER".

Depending on the event type, an input or an output mapping may be required.

The figure shows the display of the Start and End event in an iflow. Further explanations:

Start Event

A start event creates a new process instance or indicates the start of a referenced sub-process. A start event is an event that does not need or require a specific trigger. A message start event indicates that the process start is triggered when the event receives a Web Services Description Language (WSDL) message. You assign a message trigger that is created from a service interface and an operation to the message start event.

End Event

An end event is an event that has no specific result. You can use it when the exact result of an end event is not important. A result, such as a message or error, can be configured at any time, but is not required.

You can configure the following attributes for an end event:

• Name

• Trigger Type

• Description

An end event can be used without a trigger in an embedded sub-process.

Message End Event

A message end event ends a process and sends a WSDL message as a result. A process can have only one end event whose result is a message. A message trigger is created from a service interface and an operation and assigned to the message end event. The same message trigger created from a WSDL file with a request and response is assigned to the message start and end events to model a synchronous process.

An intermediate event pauses a process and has no specific trigger to continue. Use an intermediate event when the exact trigger of an event is not important. You can set a trigger, for example a message or timer, to an intermediate event at any time, but it is not required.

An intermediate timer event shows where the process pauses and waits for a certain time to pass before resuming

An intermediate message event shows where the process pauses and waits for a WSDL message from outside the process before resuming. Intermediate message events cannot be used in embedded sub-processes.

An error boundary event is a specific intermediate event that you place on the boundary of an activity, but it is not in the actual process flow. Error boundary events handle exceptions that occur during an activity and are triggered by an error or escalation. A sequence flow connection starting at a boundary event shows the process flow after an exception.

Exceptions can occur in the following areas within a process:

• 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 behave in the following ways:

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

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

The figure shows the display of the Error End event, the Escalation End event and the Termination event in an iFlow.

Further explanations:

Error End Event

An error end event terminates a process that has reached an error state. An error end event is used to model an error that occurs in a process. This error triggers a WSDL fault, which can be defined in the service interface of the message trigger assigned to a message start event. Since the error is defined in the service interface, it is visible outside the Business Process Management (BPM) system and can be used to communicate with other systems.

There can be as many error end events in a process as the number of faults defined, but a synchronous process ending with an error end event cannot be modeled because a WSDL fault response is not supported. Error end events cannot be used in embedded sub-processes.

An error that occurs in a referenced sub-process is handled by an error boundary event, which is placed on the boundary of the sub-process flow object in your process.

Escalation End Event

The escalation end event represents a business error that has occurred and needs to be processed (for example, when a task is not completed by the defined deadline). The escalation is internal to the BPM system and is not visible to other systems. There can be more than one escalation end events in a process. The escalation type and importance of the event can be configured in the process.

An escalation is thrown from an inner sub-process to an outer external process until the exception can be handled by an exception handler. If exception handling is not possible for a critical escalation, the process is suspended. Exceptions are analyzed in the SAP NetWeaver Administrator.

Termination

A termination event stops the process or sub-process immediately. A termination event, by default, is triggered by a message, but also can be triggered by an error or escalation. A termination event ends a process flow by design. If a branch in the process reaches a termination event, all parallel flows in the process are also terminated. Termination events can be configured in detail.

Exceptions indicate problems that have occurred or changes from the normal flow of the process. When an exception occurs in the process, the process execution stops at that point. There are the following two types of exceptions in the process composer, differentiated by their triggers:

• Errors

• Escalations

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

• Error end event

• Escalation end event

• Boundary event

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

The following are exception types for human activities:

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

• Noncritical escalation

  A noncritical escalation does not cancel the task execution and you can work on the task and complete it at runtime. The noncritical 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.

To use exceptions, perform the following high level procedure:

1. Create the necessary events.

2. Define the input mapping

   Input mapping defines the information that the exception needs.

3. Define the output mapping.

   The output mapping for boundary events shows how information about the exception is used in the process

You create service interface definitions or WSDL files to use them in your business process model so you can execute it. You define operations for the service interface definitions you use in your process. The operation is an abstract description of an action supported by the service. The WSDL files are included in a Service Group to be able to configure upon deployment.

The figure shows the place, where new reusable event triggers can be assigned to an iFlow.

Creating reusable event triggers enables you to model events more easily and quickly. You make the necessary settings once and then assign the trigger to more than one event in your process. The event trigger represents the Web service endpoint of the process at runtime.

You can also use one and the same event trigger in multiple processes that are contained in the same project. Note that assigning the same message trigger to start events of multiple processes may result in starting all these processes together when the service interface is invoked. You have to specify different start conditions if this behavior is undesired.

You can create the following types of reusable event triggers:

• Message Trigger

  You use message triggers for modeling message start, intermediate message, and message end events. You create the message trigger from an operation of a service interface. To make service interfaces available, you can either import or create service interface definitions or WSDL files in your project. When there is a WSDL fault defined for an operation in the service interface definition, an error trigger is automatically created together with the message trigger. You cannot create a separate error trigger manually, but you can add a fault in the WSDL file and then create message and error triggers. You can use the error trigger to model error end events in your process.

• Escalation Trigger

  You use escalation triggers to model escalation end events in the process. Escalation end events represent a business error that occurs in the process, for example, an item runs out of stock in a purchase order process. All the deadlines you define in a task can also trigger escalations when they are reached. When you create escalation triggers, you define the escalation type, which is a XSD type. In this way you define which data the escalation transports from the place it is thrown to the place where it is handled. You have the option of marking an escalation as critical. Error and escalation end events can be handled by a respective boundary event. When you have created your event triggers, you can assign them to the events you model. You can also create start and end events directly from event triggers when you drag and drop them on the modeling surface, or intermediate events when you drop a trigger on a sequence flow connection. When you drop an event trigger on an already modeled event, the trigger is updated with the one you dropped on the event.

Intermediate event messages in BPM are used to receive asynchronous messages. The process instance stops until the message is received.

Correlation conditions are used to determine to which process instance the incoming message belongs. If the comparison of a key value(s) from the incoming message to a key value(s) in the process instance context match, then the message belongs to the process instance. At this point the process instance continues to the next step.

Any unique data value could be used as a key value, for example, a product ID, an order ID or a business partner ID. In general, key values must uniquely identify the process instance.

Intermediate event messages are bound to the event message. Event messages are in turn bound to service interfaces. When the BPM project is deployed, the service interface is exposed as a Web service. Clients make call to this Web service, which is turn executes the BPMN intermediate message step.

Flow objects are grouped into 3 different groups:

• Events

• Tasks

• Activities

And each group consists of various different objects.

Start Message Events (WS Provider)

The Start Message Event can be created as follows:

• WSDL abstract (ESR)

• WSDL concrete (WS Provider)

• WSDL self created

A message start event can receive only one message.

The figure, Data Flow of a Start Message Event, shows the process flow for a start message event.

Intermediate Message Event (WS Provider)

The Intermediate Message Event can be created as follows:

• WSDL abstract (ESR)

• WSDL concrete (WS Provider)

• WSDL self created

An intermediate message event can receive any number of messages.

The figure, Data Flow of an Intermediate Message Event, shows the process flow for an intermediate message event.