Adding Activities to a Business Process

The figure illustrates, which event references to a subprocess.

The referenced subprocess is a type of activity in the business process model. Use referenced subprocesses to reference another independent process by the parent process. You can reference processes contained in the same development component (DC) as the parent processes or in a different DC. When you reference a process in a different DC, you have to define the DC dependencies. A process used as a subprocess must contain its own process context.

The referenced subprocess has a start event and end event containing the same event trigger. When a subprocess is created, the start event and end event for that subprocess can be created from a selected trigger.

When modeling referenced subprocesses, choose between a top-down or a bottom-up approach. The difference between these approaches is the sequence in which the steps are executed to model the referenced subprocess.

In a top-down approach, a referenced subprocess activity is created in the parent process being modeled. A new process is modeled containing events, activities, and connections and then assigned to the referenced subprocess activity created in the parent process.

In a bottom-up approach, the new process is created separately from the parent process being modeled. A referenced subprocess activity is created in the parent process and the new process is assigned to the referenced subprocess activity created in the parent process. As a result, the subprocess activity references the process you have modeled and assigned to it.

When modeling referenced subprocesses, data mappings can be defined to show how the referenced subprocesses use data for input and output communications with the parent process.

An embedded subprocess is a compound activity that is defined as a flow of other activities. The compound activity can be expanded to show the contained flow of activities and collapsed to make the parent process easier to view. The embedded subprocess is dependent on the parent process and cannot be executed independently like a referenced subprocess. The embedded subprocess has a local process context of data objects that is not visible to the parent and root processes. However, the process context of the parent and root processes is visible for the embedded sub-process.

A subprocess can be embedded in another embedded subprocess and then embedded in another one to create a hierarchy. As a result, there can be multiple parent processes but only one root process at the top. An embedded subprocess in a hierarchy has access to the process contexts of all its parent processes and the root process. There is no data mapping between a parent process and an embedded subprocess.

Because the embedded subprocess depends on other processes, it does not have all the features of an independent business process. There are no participants and roles in an embedded subprocess, which means there are no pools and lanes.

The embedded subprocess can only contain a subset of the events available in the Process Composer.

The following events and event triggers can be used in an embedded subprocess:

• Start Events – 1 None (without a trigger).

• Intermediate Events – 0..n Timer.

• End Events – 1..1, 0..n Escalation.

Use an embedded subprocess and its local context to model exceptions and exception handling. Exceptions are a type of escalation and are handled by boundary events. Boundary events are placed on the boundary of an embedded subprocess where an escalation is thrown or on the boundary of a parent process higher up in the hierarchy.

All activity types can be configured to be looped over multiple times. Looping is controlled by a bound list in the process context. For each item in the list, the activity is executed. The item in the collection being looped over can be accessed for input mapping from the currentCollectionItem node.

To model multiple, parallel instances of an activity in a process model, create a looping activity. All activity types in a process model can be configured in the Process Composer to loop multiple times. At runtime, a dynamic number of activity instances can run in parallel. The exact number of instances to be executed at runtime with a loop context is defined in the Process Composer. To define the loop context, select a specific data object with an XSD element, which is a list from the process context, or use an expression, which evaluates a list of elements. The number of elements in the list defines how many instances are executed.

All the instances of an activity are executed in parallel. The process flow continues after all of the parallel instances of the activity have been completed.

The following additional loop-specific data objects are automatically created when using the Parallel for Each loop option:

1. NumberOfCompletedIterations – This data object contains the number of completed loop instances.

2. CurrentCollectionItem – This data object contains the list element assigned to each loop instance.

These two data objects are only relevant for loops and are part of the local context of the activity with the multi-instance loop. Loop-specific data objects can be used when input and output data mappings are defined for this activity, but the two loop-specific data objects cannot be used for data mappings of other activities in the process.

The loop-specific data objects can only be used as a source when defining data mappings, but they cannot be used as a target. To transport information from within the loop context to a data object outside the loop context, the corresponding output mapping must be defined and appended.

Mapping activities are simple activities that allow you to map the context itself, while calling rules and functions.

The mapping activity is a type of flow object in the process. Use a mapping activity to transform complex data from data objects in the process context into simpler data. When working with mapping activities, a mapping activity is created as a flow object in your process. Mappings are defined between the data objects in the process context.