Table 10.59 – DataInput attributes and model associations

Data Output

A Data Output is a declaration that a particular kind of data can be produced as output of the InputOutputSpecification. There MAY be multiple Data Outputs associated with a

InputOutputSpecification.

The Data Output is an item-aware element. Data Output are visually displayed on a top-level Process diagram to show the outputs of the Process (i.e., one that is referenced by a Call Activity, where the Call Activity has been expanded to show the called Process within the context of a calling Process).

Visualized Data Outputs have the same notation as Data Objects, except that they MUST contain a small, filled block arrow (see Figure 10.60).

Data Outputs MAY have outgoing DataAssociations.

If the Data Output is directly contained by the top-level Process, it MUST not be the source of Data Associations within the underlying model. Only Data Outputs that are contained by Activities or Events MAY be the target of Data Associations in the model.

If the Process is being called from a Call Activity, the Data Associations that target the Data Outputs of the Call Activity in the underlying model MAY be visualized such that they connect to the corresponding Data Outputs of the called Process, visually crossing the Call Activity boundary. But note that this is visualization only. In the underlying model, the Data Associations originate the Data Outputs of the Call Activity and not the Data Outputs of the called Process.

Figure 10.60 – A Data Output

States

DataOutput elements can optionally reference a DataState element, which is the state of the data contained in the DataOutput. The definition of these states, e.g., possible values, and any specific semantics are out of scope of this International Standard. Therefore, BPMN adopters can use the DataState element and the BPMN extensibility capabilities to define their states.

Figure 10.61 – Data Output class diagram

The DataOutput element inherits the attributes and model associations of BaseElement (see Table 8.5) and ItemAwareElement (Table 10.52). Table 10.60 presents the additional attributes and model associations of the

DataInput element.

Table 10.60 – DataOutput attributes and associations

The following describes the mapping of data inputs and outputs to the specific Activity and Event implementations.

Service Task Mapping

If the Service Task is associated with an Operation, there MUST be a Message Data Input on the Service Task and it MUST have an itemDefinition equivalent to the one defined by the Message referred to by the inMessageRef attribute of the operation. If the operation defines output Messages, there MUST be a single Data Output and it MUST have an itemDefinition equivalent to the one defined by Message referred to by the outMessageRef attribute of the Operation.

Send Task Mapping

If the Send Task is associated with a Message, there MUST be at most inputSet set and at most one Data Input on the Send Task. If the Data Input is present, it MUST have an itemDefinition equivalent to the one defined by the associated Message. If the Data Input is not present, the Message will not be populated with data at execution time.

Receive Task Mapping

If the Receive Task is associated with a Message, there MUST be at most outputSet set and at most one Data Output on the Receive Task. If the Data Output is present, it MUST have an itemDefinition equivalent to the one defined by the associated Message. If the Data Output is not present, the payload within the Message will not flow out of the Receive Task and into the Process.

User Task Mapping

User Tasks have access to the Data Input, Data Output and the data aware elements available in the scope of the

User Task.

Call Activity Mapping

The DataInputs and DataOutputs of the Call Activity are mapped to the corresponding elements in the

CallableElement without any explicit DataAssociation.

Script Task Mapping

Script Tasks have access to the Data Input, Data Output and the data aware elements available in the scope of the

Script Task.

Events

If any of the EventDefinitions for the Event is associated with an element that has an ItemDefinition (such as

aMessage, Escalation, Error, or Signal), the following constraints apply:

•If the Event is associated with multiple EventDefinitions, there MUST be one Data Input (in the case of throw Events) or one Data Output (in the case of catch Event) for each EventDefinition. The order of the

EventDefinitions and the order of the Data Inputs/Outputs determine which Data Input/Output corresponds with which EventDefinition.

•For each EventDefinition and Data Input/Output pair, if the Data Input/Output is present, it MUST have an

ItemDefinition equivalent to the one defined by the Message, Escalation, Error, or Signal on the associated EventDefinition. In the case of a throw Event, if the Data Input is not present, the Message, Escalation, Error, or Signal will not be populated with data. In the case of a catch Event, if the Data Output is not present, the payload within the Message, Escalation, Error, or Signal will not flow out of the Event and into the Process.

InputSet

An InputSet is a collection of DataInput elements that together define a valid set of data inputs for an

InputOutputSpecification. An InputOutputSpecification MUST have at least one InputSet element. An InputSet MAY reference zero or more DataInput elements. A single DataInput MAY be associated with multiple InputSet elements, but it MUST always be referenced by at least one InputSet.

An “empty” InputSet, one that references no DataInput elements, signifies that the Activity requires no data to start executing (this implies that either there are no data inputs or they are referenced by another input set).

InputSet elements are contained by InputOutputSpecification elements; the order in which these elements are included defines the order in which they will be evaluated.