Table 10.7 – ResourceParameterBinding model associations

10.3.2 Performer

The Performer class defines the resource that will perform or will be responsible for an Activity. The performer can be specified in the form of a specific individual, a group, an organization role or position, or an organization.

The Performer element inherits the attributes and model associations of BaseElement (see Table 8.5) through its relationship to ResourceRole, but does not have any additional attributes or model associations.

10.3.3 Tasks

A Task is an atomic Activity within a Process flow. A Task is used when the work in the Process cannot be broken down to a finer level of detail. Generally, an end-user and/or applications are used to perform the Task when it is executed.

A Task object shares the same shape as the Sub-Process, which is a rectangle that has rounded corners (see Figure 10.8).

A Task is a rounded corner rectangle that MUST be drawn with a single thin line.

The use of text, color, size, and lines for a Task MUST follow the rules defined in “Use of Text, Color, Size, and Lines in a Diagram” on page 39.

A boundary drawn with a thick line SHALL be reserved for Call Activity (Global Tasks) (see page 186).

A boundary drawn with a dotted line SHALL be reserved for Event Sub-Processes (see page 174) and thus are not allowed for Tasks.

A boundary drawn with a double line SHALL be reserved for Transaction Sub-Processes (see page 176) and thus are not allowed for Tasks.

Figure 10.8 – A Task object

BPMN specifies three types of markers for Task: a Loop marker or a Multi-Instance marker and a Compensation marker. A Task MAY have one or two of these markers (see Figure 10.9).

The marker for a Task that is a standard loop MUST be a small line with an arrowhead that curls back upon itself. See page 188 for more information on loop Activities.

The loop Marker MAY be used in combination with the compensation marker.

The marker for a Task that is a multi-instance MUST be a set of three vertical lines. See page 190 for more information on multi-instance Activities.

If the multi-instance instances are set to be performed in sequence rather than parallel, then the marker will be rotated 90 degrees (see Figure 10.49 ).

The multi-instance marker MAY be used in combination with the compensation marker.

The marker for a Task that is used for compensation MUST be a pair of left facing triangles (like a tape player “rewind” button). See page 301 for more information on compensation.

The Compensation Marker MAY be used in combination with the loop marker or the multi-instance marker.

All the markers that are present MUST be grouped and the whole group centered at the bottom of the shape.

Figure 10.9 – Task markers

Figure 10.10 displays the class diagram for the Task element.

Figure 10.10 – The Task class diagram

The Task inherits the attributes and model associations of Activity (see Table 10.3). There are no further attributes or model associations of the Task.

10.3.3.1 Types of Tasks

There are different types of Tasks identified within BPMN to separate the types of inherent behavior that Tasks might represent. The list of Task types MAY be extended along with any corresponding indicators. A Task which is not further specified is called Abstract Task (this was referred to as the None Task in BPMN 1.2). The notation of the Abstract Task is shown in Figure 10.8.

Service Task

A Service Task is a Task that uses some sort of service, which could be a Web service or an automated application.

A Service Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Service Task (see Figure 10.11).

A Service Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a marker that distinguishes the shape from other Task types (as shown in Figure 10.11).

Figure 10.11 – A Service Task Object

The Service Task inherits the attributes and model associations of Activity (see Table 10.3). In addition the following constraints are introduced when the Service Task references an Operation: The Service Task has exactly one inputSet and at most one outputSet. It has a single Data Input with an ItemDefinition equivalent to the one defined by the Message referenced by the inMessageRef attribute of the associated Operation. If the Operation defines output Messages, the Service Task has a single Data Output that has an ItemDefinition equivalent to the one defined by the Message referenced by the outMessageRef attribute of the associated

Operation.

The actual Participant whose service is used can be identified by connecting the Service Task to a Participant using a Message Flows within the definitional Collaboration of the Process – see Table 10.1.

A Send Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a filled envelope marker that distinguishes the shape from other Task types (as shown in Figure 10.13).

Figure 10.13 – A Send Task Object

Figure 10.14 – The Send Task and Receive Task class diagram

The Send Task inherits the attributes and model associations of Activity (see Table 10.3). In addition the following constraints apply when the Send Task references a Message: The Send Task has at most one inputSet and one Data Input. If the Data Input is present, it MUST have an ItemDefinition equivalent to the one defined by the associated Message. At execution time, when the Send Task is executed, the data automatically moves from the Data Input on the Send Task into the Message to be sent. If the Data Input is not present, the Message will not be populated with data from the Process.

Table 10.9 presents the additional model associations of the Send Task.