Figure 10.38 – An Ad-Hoc Sub-Process with data and sequence dependencies

The Data Objects as inputs into the Tasks act as an additional constraint for the performance of those Tasks. The performers still determine when the Tasks will be performed, but they are now constrained in that they cannot start the Task without the appropriate input. The addition of Sequence Flows between the Tasks (e.g., between “Generate Graphics” and “Include Graphics in Text”) creates a dependency where the performance of the first Task MUST be followed by a performance of the second Task. This does not mean that the second Task is to be performed immediately, but there MUST be a performance of the second Task after the performance of the first Task.

It is a challenge for a BPM engine to monitor the status of Ad-Hoc Sub-Processes, usually these kind of Processes are handled through groupware applications (such as e-mail), but BPMN allows modeling of Processes that are not necessarily executable, although there are some process engines that can follow an Ad-Hoc Sub-Process. Given this, at some point the Ad-Hoc Sub-Process will have complete and this can be determined by evaluating a completionCondition that evaluates Process attributes that will have been updated by an Activity in the

Process.

10.3.6 Call Activity

A Call Activity identifies a point in the Process where a global Process or a Global Task is used. The Call Activity acts as a ‘wrapper’ for the invocation of a global Process or Global Task within the execution. The activation of a call Activity results in the transfer of control to the called global Process or Global Task.

The BPMN 2.0 Call Activity corresponds to the Reusable Sub-Process of BPMN 1.2. A BPMN 2.0 Sub-Process corresponds to the Embedded Sub-Process of BPMN 1.2 (see the previous sub clause).

A Call Activity object shares the same shape as the Task and Sub-Process, which is a rectangle that has rounded corners. However, the target of what the Activity calls will determine the details of its shape.

If the Call Activity calls a Global Task, then the shape will be the same as a Task, but the boundary of the shape will MUST have a thick line (see Figure 10.39).

The Call Activity MUST display the marker of the type of Global Task (e.g., the Call Activity would display the User Task marker if calling a Global User Task).

If the Call Activity calls a Process, then there are two options:

The details of the called Process can be hidden and the shape of the Call Activity will be the same as a collapsed Sub-Process, but the boundary of the shape MUST have a thick line (see Figure 10.40).

Figure 10.39 – A Call Activity object calling a Global Task

Figure 10.40 – A Call Activity object calling a Process (Collapsed)

Figure 10.41 – A Call Activity object calling a Process (Expanded)

When a Process with a definitional Collaboration, calls a Process that also has a definitional Collaboration, the

Participants of the two Collaborations can be matched to each other using ParticipantAssociations of the

Collaboration of the calling Process.

A Call Activity MUST fulfill the data requirements, as well as return the data produced by the CallableElement being invoked (see Figure 10.41). This means that the elements contained in the Call Activity’s InputOutputSpecification MUST exactly match the elements contained in the referenced CallableElement. This includes DataInputs, DataOutputs, InputSets, and OutputSets.

Figure 10.42 –The Call Activity class diagram

A Call Activity can override properties and attributes of the element being called, potentially changing the behavior of the called element based on the calling context. For example, when the Call Activity defines one or more ResourceRole elements, the elements defined by the CallableElement are ignored and the elements defined in the Call Activity are used instead. Also, Events that are propagated along the hierarchy (errors and escalations) are propagated from the called element to the Call Activity (and can be handled on its boundary).

The Call Activity inherits the attributes and model associations of Activity (see Table 10.3). Table 10.23 presents the additional model associations of the Call Activity.

Table 10.23 – CallActivity model associations

Callable Element

CallableElement is the abstract super class of all Activities that have been defined outside of a Process or Choreography but which can be called (or reused), by a Call Activity, from within a Process or Choreography. It MAY reference Interfaces that define the service operations that it provides. The BPMN elements that can be called by Call Activities (i.e., are CallableElements) are: Process and GlobalTask (see Figure 10.43). CallableElements are RootElements, which can be imported and used in other Definitions. When CallableElements (e.g., Process) are defined, they are contained within Definitions.

Figure 10.43 – CallableElement class diagram

The CallableElement inherits the attributes and model associations of BaseElement (see Table 8.5) through its relationship to RootElement. Table 10.24 presents the additional attributes and model associations of the

CallableElement.