Table 10.135 – Lane attributes and model associations

10.9 Process Instances, Unmodeled Activities, and Public Processes

A Process can be executed or performed many times, but each time is expected to follow the steps laid out in the Process model. For example, the Process in Figure 10.1 will occur every Friday, but each instance is expected to perform Task “Receive Issue List,” then Task “Review Issue List,” and so on, as specified in the model. Each instance of a Process is expected to be valid for the model, but some instances might not, for example if the Process has manual Activities, and the performers have not had proper instruction on how to carry out the Process.

In some applications it is useful to allow more Activities and Events to occur when a Process is executed or performed than are contained in the Process model. This enables other steps to be taken as needed without changing the Process. For example, instances of the Process in Figure 10.1 might execute or perform an extra Activity between Task “Receive Issue List” and Task “Review Issue List.” These instances are still valid for the Process model in Figure 10.1, because the instances still execute or perform the Activities in the Process, in the order they are modeled and under conditions specified for them.

There are two ways to specify whether unmodeled Activities are allowed to occur in Process instances:

•If the isClosed attribute of a Process has a value of false or no value, then interactions, such as sending and receiving Messages and Events, MAY occur in an instance without additional flow elements in the Process. Unmodeled interactions can still be restricted on particular Sequence Flow in the Process (see next bullet). If the isClosed attribute of a Process has a value of true, then interactions, such as sending and receiving Messages and Events, MAY NOT occur without additional flow elements in the Process. This restriction overrides any unmodeled interactions allowed by Sequence Flows in the next bullet.

•If the isImmediate attribute of a Sequence Flow in a Process has a value of false, then other Activities and interactions not modeled in the Process MAY be executed or performed during the Sequence Flow. If the isImmediate attribute has a value of true, then Activities and interactions not modeled in the Process MAY NOT be executed or performed during Sequence Flow. In non-executable Processes (isExecutable attribute has value false, or defaults to false), Sequence Flows with no value for isImmediate are treated as if the

value were false. In executable Processes (isExecutable attribute has value true, or defaults to true), Sequence Flows with no value for isImmediate are treated as if the value were true. Executable Processes cannot have a false value for the isImmediate attribute.

Restrictions on unmodeled Activities specified with isClosed and isImmediate apply only under executions or performances (instances) of the Process containing the restriction. These Activities MAY occur in instances of other

Processes.

When a Process allows Activities to occur that the Process does not model, those Activities might appear in other Process models. The executions or performances (instances) of these other Processes might be valid for the original Process. For example, a Process might be defined similar to the one in Figure 10.1 that adds an extra Activity between Task “Receive Issue List” and Task “Review Issue List.” The Process in Figure 10.1 might use isClosed or isImmediate to allow other Activities to occur in between Task “Receive Issue List” and Task “Review Issue List.” When the Process is executed or performed, then instances of the other Process (the one with the extra step in between Task “Receive Issue List” and Task “Review Issue List”) will be valid for the Process in Figure 10.1. Modelers can declare that they intend all instances of one Process will be valid for another Process using the supports association between the Processes. During development of these Processes, support might not actually hold, because the association just expresses modeler intent.

A common use for model support is between private and public Processes, see “Overview” (page 21). A public Process contains Activities visible to external parties, such as Participants in a Collaboration, while a private Process includes other Activities that are not visible to external parties. The hidden Activities in a private Process are not modeled in the public Process. However, it is expected that instances of the private Process will appear to external parties as if they could be instances of the public Process. This means the private Process supports the public Process (it is expected that all instances of the private Process will be valid for the public one).

A Process that supports another, as a private Process can to a public Process, does not need to be entirely similar to the other Process. It is only REQUIRED that instances of the Process appear as if they could be instance of the other Process. For example Figure 10.127 shows a public Process at the top with a Send Task and Receive Task. A supporting private Process is shown at the bottom. The private Process sends and receives the same Messages, but using Events instead of Tasks. It also introduces Activities not modeled in the public Process. However all instances of the private Process will appear as if they could be instances of the public one, because the Messages are sent and received in the order REQUIRED by the public Process, and the public Process allows unmodeled Activities to occur.

X

A

B

Figure 10.127 – One Process supporting to another

In practice, a public Process looks like an underspecified private Process. Anything not specified in the public Process is determined by the private one. For example, if none of the outgoing Sequence Flows for an Exclusive Gateway have conditionExpressions, the private Process will determine which one of the Activities targeted by the Sequence Flows will occur. Another example is a Timer Event with no EventDefinition. The private Process will determine when the timer goes off.

10.10 Auditing

The Auditing element and its model associations allow defining attributes related to auditing. It leverages the BPMN extensibility mechanism. This element is used by FlowElements and Process. The actual definition of auditing attributes is out of scope of this International Standard. BPMN 2.0 implementations can define their own set of attributes and their intended semantics.

Figure 10.128 – Auditing Class Diagram

10.11 Monitoring

The Monitoring and its model associations allow defining attributes related to monitoring. It leverages the BPMN extensibility mechanism. This element is used by FlowElements and Process. The actual definition of monitoring attributes is out of scope of this International Standard. BPMN 2.0.2 implementations can define their own set of attributes and their intended semantics.

Figure 10.129 – Monitoring Class Diagram

10.12 Process Package XML Schemas

Table 10.136 – Process XML schema

<xsd:element name="process" type="tProcess" substitutionGroup="rootElement"/> <xsd:complexType name="tProcess">

<xsd:complexContent>

<xsd:extension base="tCallableElement"> <xsd:sequence>

<xsd:element ref="auditing" minOccurs="0" maxOccurs="1"/> <xsd:element ref="monitoring" minOccurs="0" maxOccurs="1"/>

<xsd:element ref="processRole" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="property" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="laneSet" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="flowElement" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="artifact" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="resourceRole" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element ref="correlationSubcription" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="supports" type="xsd:QName" minOccurs="0" maxOc-

curs="unbounded"/> </xsd:sequence>

<xsd:attribute name="processType" type="tProcessType" default="None"/> <xsd:attribute name="isExecutable" type="xsd:boolean"use="optional"/> <xsd:attribute name="isClosed" type="xsd:boolean" default="false"/>

<xsd:attribute name="definitionalCollaborationRef" type="xsd:QName" use="optional"/> </xsd:extension>

</xsd:complexContent> </xsd:complexType>

<xsd:simpleType name="tProcessType"> <xsd:restriction base="xsd:string">

<xsd:enumeration value="None"/> <xsd:enumeration value="Public"/> <xsd:enumeration value="Private"/>

</xsd:restriction>

</xsd:simpleType>

Table 10.137 – Auditing XML schema

<xsd:element name="auditing" type="tAuditing"/> <xsd:complexType name="tAuditing">

<xsd:complexContent>

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

</xsd:complexType>

Table 10.138 – GlobalTask XML schema

<xsd:element name="globalTask" type="tGlobalTask" substitutionGroup="rootElement"/> <xsd:complexType name="tGlobalTask">

<xsd:complexContent>

<xsd:extension base="tCallableElement"> <xsd:sequence>

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

</xsd:extension> </xsd:complexContent>

</xsd:complexType>

Table 10.139 – Lane XML schema

<xsd:element name="lane" type="tLane"/> <xsd:complexType name="tLane">

<xsd:complexContent>

<xsd:extension base="tBaseElement"> <xsd:sequence>

<xsd:element name="partitionElement" type="tBaseElement" minOccurs="0" maxOc-

curs="1"/>

<xsd:element name="flowNodeRef" type="xsd:IDREF" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element name="childLaneSet" type="tLaneSet" minOccurs="0" maxOccurs="1"/> </xsd:sequence>

<xsd:attribute name="name" type="xsd:string"/>

<xsd:attribute name="partitionElementRef" type="xsd:QName"/> </xsd:extension>

</xsd:complexContent> </xsd:complexType>

Table 10.140 – LaneSet XML schema

<xsd:element name="laneSet" type="tLaneSet"/> <xsd:complexType name="tLaneSet">

<xsd:complexContent>

<xsd:extension base="tBaseElement"> <xsd:sequence>

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

<xsd:attribute name="name" type="xsd:string"/> </xsd:extension>

</xsd:complexContent> </xsd:complexType>

Table 10.141– Monitoring XML schema

<xsd:element name="monitoring" type="tMonitoring"/> <xsd:complexType name="tMonitoring">

<xsd:complexContent>

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

</xsd:complexType>

Table 10.142 – Performer XML schema

<xsd:element name="performer" type="tPerformer" substitutionGroup="resourceRole"/> <xsd:complexType name="tPerformer">

<xsd:complexContent>

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

</xsd:complexType>