The core elements of a process are activities which are created and executed as activity instances during process execution. An activity is an atomic piece of work forming one logical step, which contributes to the overall realization of the process.

The chapter covers the following:

For details on using activities in the Eclipse modeler and the Portal Modeling perspective, please refer to chapter Working with Activities in the Eclipse Modeling Guide and chapter Working with Activities in the Business Process Modeling Handbook respectively.

Interactive and Non-interactive Activities

Activities may be of different types. Some activities may be performed interactively (interactive activities) in contrast to automated activities (non-interactive activities).

The differences in activity types are reflected in the implementation of these activities.

Non-interactive activities are used to

For each interactive activity a so-called participant is specified as a performer of this activity. A participant can be a role or an organization. At runtime, it is evaluated whether a particular user is assigned to this role or organization.

For all activities - interactive and non-interactive - the way data is accessed by this activity also belongs to the activity definition.

Activity Implementation Types

Activities are also categorized by their implementation type as

Route Activity

Route activities are basically doing nothing. They are used for technical reasons, e.g. to join control flow. However, in the context of event handling they can serve as synchronization points for events and executing event actions.

Application Activity

Application activities are executing application logic, which is specified in an associated application. This application can either be interactive or non-interactive.

Sub-process Activity - Synchronous/Asynchronous

Sub-process activities are associated with a process definition and are executing an instance of this process definition (sub-process) at runtime. Sub-processes are defined mainly for the purpose of cohesiveness and re-usability. There are three different types of sub-processes - synchronous with shared data, asynchronous and synchronous with separate data. The synchronous with shared data sub-process shares the same workflow data scope (shared data) at runtime. This is done by linking activity instances not only to the owning process instance but also to the scope process instance, which is on top of the process instance hierarchy defined by sub-process relationships. The asynchronous sub-process gets a copy of the data as separate data. Whereas the synchronous with separate data sub-process offers the option to determine, if the data should be handled as separate data or if the passing of data should be explicitly performed by the means of data mappings.

Manual Activity

Manual activities are interactive activities with no associated application. They are used mainly in embedded programming where they provide an appropriate means to handle interactive activities from the point of view of embedded programming. See the Programming Guide for further details. Manual activities also serve the purpose of rapid prototyping because the Workflow Execution Perspective automatically generates default panels for manual applications.

You have the option to convert a manual activity to a JSF application activity, like described in chapter Converting Manual Activities to JSF Application Activities.

The following table summarizes the possible categorizations of activities:

interactive non-interactive
Route - +
Application + +
Sub-process - +
Manual + -

Categorization of Activities

To summarize an activity, it formally contains the following definitions:

As a model element an activity has the following properties:

Activity Instances

During process execution, activities are instantiated. An instance of an interactive activity represents a work item in the worklist of a user or user group according to the participant specified as performer of the activity in the process model.

Activity instances have a persistent representation in the audit trail.

Activity Instance States

During its lifetime, an activity instance undergoes several states. It is created in state created and turns to state application after it starts its work. When the activity instance is regularly finished it turns to state completed. There is the possibility for the execution of an activity instance to block its execution, which results in hibernated state or in suspended state. This happens in the following situations:

There are other special states for exceptional situations:

The completed state and the aborted state for activity instances which have the scope to start the abort from the root process, are final states. In those cases, the activity instance can never show any subsequent activity after going to one of these states. They are referred to as terminated activity instances. Initialization of abort may result in aborting state (an intermediate state) if the activity does not get aborted successfully or the time span is large before abort. If it gets aborted successfully then it achieves the aborted state else it remains in aborting state.

Figure: Possible Activity Instance State Changes

Aborting Activity Instances

Activity Instances Behavior after an Abort

Generally it has to be distinguished between an abort starting from the root hierarchy and an abort starting from the sub-process.

Abort starting from the root hierarchy

In case an abort is determined to start from the root hierarchy, an abortion causes the denoted activity instance to be aborted at the next possible commit points, e.g. as soon as synchronous activity threads are terminated. If the denoted activity instance is a sub-process activity, the corresponding sub-process is terminated likewise.

Abort starting from the sub-process

If the activity instance is determined to be aborted starting from the sub-process, the sub-process termination is performed similar to an abortion of a process instance. The difference is that the calling super process instance will continue to be processed normally after a sub-process abortion, like as if the sub-process activity had been completed regularly. Thus an abortion of the process instance will not propagate upwards in the process hierarchy.

Out Data Mapping Behavior of Aborted Activity Instances

Please note that Out data mappings of aborted activity instances will not be evaluated. The following activity instances using In data mappings from those data have to be aware that the data values may not be initialized or can contain incorrect data.

Handling of Activities following an Aborted Activity Instance

You can handle activities following an aborted activity instance by using the engine access point activityInstance in a transition condition. Please refer to the section Using Information of an Activity Instance in the Condition of the chapter Working with Transitions for information on how to use this access point.

Activity Criticality

You can set activity criticality on model level to prioritize the worklist entries based on a JavaScript formula using process priority and other possible parameters and variables. Refer to chapter Activity Criticality for details on the activity criticality concept.