Table 10.12 – Script Task attributes

10.3.4 Human Interactions

10.3.4.1 Tasks with Human involvement

In many business workflows, human involvement is needed to complete certain Tasks specified in the workflow model. BPMN specifies two different types of Tasks with human involvement, the Manual Task and the User Task.

A User Task is executed by and managed by a business process runtime. Attributes concerning the human involvement, like people assignments and UI rendering can be specified in great detail. A Manual Task is neither executed by nor managed by a business process runtime.

Notation

Both, the Manual Task and User Task share the same shape, which is a rectangle that has rounded corners. Manual Tasks and User Tasks have a Icons to indicate the human involvement is REQUIRED to complete the Task (see Figure 10.15 and Figure 10.17).

Manual Task

A Manual Task is a Task that is not managed by any business process engine. It can be considered as an unmanaged Task, unmanaged in the sense of that the business process engine doesn’t track the start and completion of such a Task. An example of this could be a paper based instruction for a telephone technician to install a telephone at a customer location.

Figure 10.21 – Manual Task class diagram

The User Task inherits the attributes and model associations of Activity (see Table 10.3), but does not have any additional attributes or model associations.

User Task

A User Task is a typical “workflow” Task where a human performer performs the Task with the assistance of a software application. The lifecycle of the Task is managed by a software component (called task manager) and is typically executed in the context of a Process.

Figure 10.22 – User Task class diagram

The User Task can be implemented using different technologies, specified by the implementation attribute. Besides the Web service technology, any technology can be used. A User Task for instance can be implemented using WSHumanTask by setting the implementation attribute to “http://docs.oasis-open.org/ns/bpel4people/ws-humantask/protocol/ 200803.”

The User Task inherits the attributes and model associations of Activity (see Table 10.3). Table 10.13 presents the additional attributes and model associations of the User Task. If implementations extend these attributes (e.g., to introduce subjects or descriptions with presentation parameters), they SHOULD use attributes defined by the OASIS WSHumanTask specification.

Table 10.13 – User Task attributes and model associations

The User Task inherits the instance attributes of Activity (see Table 8.49). Table 10.14 presents the instance attributes of the User Task element.

Table 10.14 – User Task instance attributes

Rendering of User Tasks

BPMN User Tasks need to be rendered on user interfaces like forms clients, portlets, etc. The Rendering element provides an extensible mechanism for specifying UI renderings for User Tasks (Task UI). The element is optional. One or more rendering methods can be provided in a Task definition. A User Task can be deployed on any compliant implementation, irrespective of the fact whether the implementation supports specified rendering methods or not. The Rendering element is the extension point for renderings. Things like language considerations are opaque for the Rendering element because the rendering applications typically provide Multilanguage support. Where this is not the case, providers of certain rendering types can decide to extend the rendering type in order to provide language information for a given rendering. The content of the rendering element is not defined by this International Standard.

Human Performers

People can be assigned to Activities in various roles (called “generic human roles” in WS-HumanTask). BPMN 1.2 traditionally only has the Performer role. In addition to supporting the Performer role, BPMN 2.0 defines a specific HumanPerformer element allowing specifying more specific human roles as specialization of HumanPerformer, such as

PotentialOwner.

Figure 10.23 – HumanPerformer class diagram

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

Potential Owners

Potential owners of a User Task are persons who can claim and work on it. A potential owner becomes the actual owner of a Task, usually by explicitly claiming it.

XML Schema for Human Interactions

Table 10.15 – ManualTask XML schema

<xsd:element name="manualTask" type="tManualTask" substitutionGroup="flowElement"/> <xsd:complexType name="tManualTask">

<xsd:complexContent> <xsd:extension base="tTask"/> </xsd:complexContent>

</xsd:complexType>

Table 10.16 – UserTask XML schema

<xsd:element name="userTask" type="tUserTask" substitutionGroup="flowElement"/> <xsd:complexType name="tUserTask">

<xsd:complexContent> <xsd:extension base="tTask">

<xsd:sequence>

<xsd:element ref="rendering" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence>

<xsd:attribute name="implementation" type="tImplementation" default="##unspecified"/>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:element name="rendering" type="tRendering"/> <xsd:complexType name="tRendering">

<xsd:complexContent>

<xsd:extension base="tBaseElement"/> </xsd:complexContent>

</xsd:complexType>

<xsd:simpleType name="tImplementation"> <xsd:union memberTypes="xsd:anyURI">

<xsd:simpleType>

<xsd:restriction base="xsd:token"> <xsd:enumeration value="##unspecified" /> <xsd:enumeration value="##WebService" />

</xsd:restriction>

</xsd:simpleType>

</xsd:union>

</xsd:simpleType>