BPMN 2.0 FTF Avatar
  1. OMG Issue

BPMN2 — Data Inputs/Outputs on Subprocesses

  • Key: BPMN2-218
  • Legacy Issue Number: 14817
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    The spec isn't clear on the relationship between visual Data Inputs/Outputs and embedded subprocesses.

    Pg 191 states that "DataInput elements may appear in a Process diagram to show the inputs the Process as a whole ...". There's a similar statement on pg. 193 for Data Outputs.

    The phrase "the Process as a whole" almost reads like visualized Data Inputs/Outputs are only applicable to Processes (and not to embedded subprocesses).

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Modify/include the following text to chapter 10.3 - "Data Input and Output", directly before Figure 10.8:
    Not every Activity type defines inputs and outputs, only Tasks, CallableElements (Global Tasks and Processes) MAY define their data requirements. Embedded
    MUST NOT define Data Inputs and Data Outputs directly, however they MAY define them indirectly via Multi Instance Loop Characteristics.
    Modify/include the following text to chapter 10.2.8 - "Multi-Instance Characteristics":
    Table 10.3 - MultiInstanceLoopCharacteristics attributes and model associations
    loopDataInputRef: ItemAwareElement [0..1]
    This ItemAwareElement is used to determine the number of Activity instances, one Activity instance per item in the collection of data stored in that ItemAwareElement
    element.
    For Tasks it is a reference to a DataInput which is part of the Activity's InputOutputSpecification.
    For Sub Processes it is a reference to a collection-valued DataObject in the context that is visible to the Sub Process.
    In order to initialize a valid multi-instance, either the loopCardinality Expression or the loopDataInput MUST be specified.
    loopDataOutputRef: ItemAwareElement [0..1]
    This ItemAwareElement specifies the collection of data, which will be produced by the multi-instance.
    For Tasks it is a reference to a DataOutput which is part of the Activity's InputOutputSpecification.
    For Sub Processes it is a reference to a collection-valued DataObject in the context that is visible to the Sub Process.
    inputDataItem: DataInput [0..1]
    A DataInput, representing for every Activity instance the single item of the collection stored in the loopDataInput. This DataInput can be the source of
    DataInputAssociation to a data input of the Activity's InputOutputSpecification. The type of this DataInput MUST the scalar of the type defined for the loopDataInput.
    outputDataItem: DataOutput [0..1]
    A DataOutput, representing for every Activity instance the single item of the collection stored in the loopDataOutput. This DataOutput can be the target of
    DataOutputAssociation to a data output of the Activity's InputOutputSpecification. The type of this DataOutput MUST the scalar of the type defined for the
    loopDataOutput.
    Table 10.37 - MultiInstanceLoopCharacteristics XML schema
    (change loopDataInput to loopDataInputRef with new type QName; change loopDataOutput to loopDataOutputRef with new type QName; change of inputDataItem
    to type tDataInput; change of outputDataItem to type tDataOutput)
    <xsd:complexType name="tMultiInstanceLoopCharacteristics">
    <xsd:complexContent>
    <xsd:extension base="tLoopCharacteristics">
    <xsd:sequence>
    <xsd:element name="loopCardinality" type="tExpression" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="loopDataInputRef" type="xsd:QName" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="loopDataOutputRef" type="xsd:QName" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="inputDataItem" type="tDataInput" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="outputDataItem" type="tDataOutput" minOccurs="0" maxOccurs="1"/>
    <xsd:element ref="complexBehaviorDefinition" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element name="completionCondition" type="tExpression" minOccurs="0" maxOccurs="1"/>
    </xsd:sequence>
    <xsd:attribute name="isSequential" type="xsd:boolean" default="false"/>
    <xsd:attribute name="behavior" type="tMultiInstanceFlowCondition" default="all"/>
    <xsd:attribute name="oneBehaviorEventRef" type="xsd:QName" use="optional"/>
    <xsd:attribute name="noneBehaviorEventRef" type="xsd:QName" use="optional"/>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>
    Note: The attached diff from Tammo is not complete, so better use the schema above.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT