Sketching the BPMN Process

Business processes are created in pools. There is always at least one default pool. The default pool is automatically created when you model a process in the Process Composer.

A pool acts as a container for the sequence flow between activities. A sequence flow can cross the boundaries of lanes within a pool, but cannot cross the boundaries of the pool itself. The interaction between pools is managed through the message flow.

A pool represents a single process and is a part of a cross-organization or cross-company business process. Each single process has its own pool within the larger business process, which can contain many pools. Only one pool can be active at any time. Processes are modeled in the active pool.

A passive pool contains external activities that are relevant to the process in the active pool but are not an end-to-end process. External activities are a subset of an end-to-end process.

A pool is divided into lanes and is automatically created when you create a new process. A lane is a partition within a pool and is used for structuring and organizing activities. Lanes define the process roles that responsible for completing the activities in a process. Each process role is assigned to a particular lane and can represent internal roles, such as an account manager, or systems, like an enterprise application or an internal department.

This example in the figure, Business Trip Approval Process, shows a process that is modeled in one pool. The activities and events in the process are organized in two lanes named Employee and Manager. The activities and events are connected within and across lanes by a sequence flow.

There are nine elements of events available for modeling a business processes:

Start Event

A start event is an event that does not need or require a specific trigger, for example when designing a draft of a process model. When the process is finally designed, this event can be set by a message trigger to start the process. 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.

Intermediate Timer Event

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

Intermediate Message Event

An intermediate message event shows where the process pauses and waits for a WSDL message from outside the process before resuming. You cannot use intermediate message events in embedded subprocesses.

Error Boundary Event

A boundary event is a specific intermediate event that you place on the boundary of an activity but not in the process flow. You use boundary events for exception handling, which are triggered by an error or escalation. The boundary event handles an exception that has occurred while the activity has been performed.

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, for example when designing a draft of a process model. You can add a result to an end event later on, for example a message or error. You can also use an end event without a trigger in an embedded subprocess.

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. You assign a message trigger created from a service interface and an operation to the message end event. You can assign the same WSDL file message trigger with a request and response to the message start and end event to model a synchronous process.

Termination

The termination event ends the process flow in a regular way. If a branch in the process reaches a termination event, all parallel flows in the process are also terminated. You can set all end events as terminating and make them behave as a termination event.

Escalation Boundary Event

A boundary event is a specific intermediate event that you place on the boundary of an activity but not in the process flow. You use boundary events for exception handling and thus they are triggered by an error or escalation. The boundary event handles an exception that has occurred while the activity has been performed.

For escalation boundary events, the following exception types may occur:

• Escalations in human activities
• Escalations that you model including errors and exceptions

Escalation End

The escalation end event represents an exception that occurs inside the process, for example, when a task is not completed until the defined deadline. The escalation is internal for the BPM system and is not visible for other systems. There can be more than one escalation end event in a process. You need to set an escalation type for the escalation end event and have the option of making an escalation critical. The escalation is thrown from an inner subprocess to the next outer process until the exception can be handled by an exception handler. If no exception handling is possible for a critical escalation, the process is suspended. You can analyze the exception in the SAP NetWeaver Administrator.

Error End

You use error end events to model an error that occurs in the process. This error triggers a WSDL fault, which can be defined in the service interface of the message trigger you assign to a message start event. Since the error is defined in the service interface, it is visible outside the BPM system and can be used to communicate with other systems.

There are eight categories of activities available for modeling a business processes.

A human activity is an activity in the process that is performed by a person. Human activities require assigned tasks. When the process reaches a human activity, the assigned task must be completed by a person before the process can continue. Tasks require input and output data mappings.

An automated activity is an activity that is performed by a system. Automated activities require a service interface definition and an assigned operation. In addition, automated activities require input and output data mappings.

A referenced subprocess is an activity in the process that is a graphical representation of another independent process. When the process flow reaches the referenced subprocess, the other independent process is called. The parent process and the referenced subprocess communicate through input and output data mappings.

An embedded subprocess is dependent on the parent process and cannot be executed independently like the referenced subprocess. The embedded subprocess has the local process context of data objects, which is not visible to the parent and root processes.

A reporting activity is used to collect data from the process context so that process data can be analyzed. The reporting activity references a reporting data source and indicates where in the process data is gathered for reporting. Input mapping is required for the reporting activity to specify which process context data is to be collected by the reporting activity.

A notification is used to send eMail updates from the process. You must specify the recipients of the eMail updates. You can also customize the subject and message texts that are sent.

A mapping activity is used to take complex data from data objects in the process context and convert it to a format that is easier to use. Rule sets can be used to convert data through a mapping activity. Mapping is required between the data objects in the process context to convert data.

Looping activities enable embedded subprocesses and simple activities to be executed multiple times in parallel based on a list in the process context.

With this activity you can extend a BPM process with a workflow running in Workflow Management. Such a workflow could be embedded into a BPM process by the means of a Cloud Activity, which provides the required level of decoupling (ie. the SAP BPM starts a Workflow Management process and continues without waiting its completion). The Workflow Management runs in its own scope allowing you to define data mappings on start and end of the Cloud Activity

There are five elements for notating gateways available for modeling a business processes:

The exclusive choice gateway controls the sequence flow between activities. It is a question that is asked at a specific point in the process and has predefined set of answers to choose from. These answers are the gates. Each gate is assigned a predefined condition that is based on a boolean expression. The boolean expressions use values in the process data to determine which path has to be taken. Each gate has an outgoing sequence flow.

The parallel split gateway lets you create parallel work flow. Although you do not need to use the parallel split gateway for parallel flow, with this gateway you can clarify the behavior of complex situations where a parallel flow is required. Each gate of the parallel split gateway has an associated sequence flow. No conditions are assigned to this gateway.

The parallel join gateway merges a set of parallel sequence flows that were generated earlier in the process. The parallel split gateway and the parallel join gateway should always be used together.

The event-based choice controls the sequence flow by choosing an outgoing gate based on events that occur at a specific point in the process. Unlike the exclusive choice where the gate is chosen based on an evaluation of expressions, the event-based choice is used to determine the outgoing gate based on a specific event, like receiving a message. In the Process Composer, the event-based choice is always followed by an intermediate event that either waits for the receipt of the message or waits for a certain amount of time to pass before continuing the process flow.

The uncontrolled merge gateway is used to merge alternative sequence flows. There are a few special situations where you need an uncontrolled merge gateway. The most common use of an uncontrolled merge gateway is to join two alternative sequence flows that were generated by a decision earlier in the process. The alternative sequence flows are merged in preparation for a parallel join gateway that synchronizes a set of parallel sequence flows generated later.

Without the uncontrolled merge gateway, any number of sequence flows more than three (for example, four sequence flows) might arrive at the parallel join gateway at the same time. Only three of the four sequence flows can pass a token at one time. The parallel join gateway would wait for the fourth token, which would never arrive. The process would be stuck at the point of the parallel join gateway.

There are four elements of connection objects available for modeling a business processes:

Sequence Flow

The sequence flow element connects flow objects and defines the sequence of a business process. A flow has only one source and one target which is an element of the category Flow Objects.

Message Flow

The message flow element shows the interaction between two or more services. The Sequence Flow element is used for connecting the flow object and to define the sequence of business processes. The Message Flow object is used to show the interaction between multiple business processes. In this sense, a business process is just a service, which is invoked by other processes and do exchange data among each other.

Data Flow

A data flow element displays input and output data from and to an activity.

Association

The association element is used to attach notes, information, and other documentation to an activity. An association is either unidirectional or it has no direction. When an association is unidirectional, it is classified as a data flow connection object within SAP BPM. When an association has no direction, it allows users to add documentation to a flow object.

The figure illustrates, how orchestration and choreography is noted and displayed in a process.

As well as the modeling of a process flow, BPMN allows you to add artifacts to your process model. Artifacts include the following objects:

• Annotations – Purely descriptive objects, used for providing comments during process modeling.

• Data objects – Artifacts that store process context and are accessible during the entire process.

Data objects are usually forms that record the output information of an activity. The output of one activity is the input information for a subsequent activity in the process. Data objects manage the process context. The process context enables the sharing of data throughout a business process and makes that data available to all flow objects.

Artifacts are managed by the Process Modeler.