More on BPMN 2.0 Process Data Input

As result of some spirited back and forth on my previous post with FTF member Camunda, plus response from Oracle (original BPMN 2.0 Examples team member), I have a bit more information on the intent and usage of process dataInput in BPMN 2.0, and whether it can have incoming and/or outgoing data associations in BPMN 2.0.

To recap:

  1. The BPMN 2.0 metamodel (UML) allows dataAssociation between any item-aware elements, which include dataInput, dataOutput, dataObject, property, and dataStore. Camunda uses this to justify dataInput of a process as the source of dataInputAssociation to the dataInput of a process activity. However...
    • Metamodel UML is further constrained by statements in the narrative, such as a subprocess dataInput cannot have dataInputAssociation (although allowed by UML and XSD). Camunda says UML ("for implementers") overrides spec narrative ("for end users"). Hmmm... that last bit is doubtful.
  2. Scope of a data association was intended to be local to an activity or event, with the dataInput or dataOutput of the activity or event on one end, and a stored element - either a dataObject, dataStore, or property (or references to same) - at the other end. The statement allowing data association between "any" pair of item-aware elements was supposed to eliminate verbose enumeration of all the combinations in the narrative... although that has obviously introduced ambiguity.
  3. According to Oracle, dataInput of a process was intended only to support invocation by callActivity. If process instantiated by message start event, the data association should be from the start event to a dataObject and from there to an activity dataInput. But...
    • Spec p213 says: "If the Process is being called from a Call Activity, the Data Associations that target the Data Inputs of the Call Activity in the underlying model MAY be visualized such that they connect to the corresponding Data Inputs of the called Process, visually crossing the Call Activity boundary. But note that this is visualization only. In the underlying model, the Data Associations target the Data Inputs of the Call Activity and not the Data Inputs of the called Process." In other words, if you represent a called process using the expanded callActivity shape, you can draw a data association [e.g., from a dataObject in the calling process] to the dataInput shape of the called process, but in the XML the connection is actually to the dataInput of the callActivity, not the dataInput of the process.
    • And p218: "The DataInputs and DataOutputs of the Call Activity are mapped to the corresponding elements in the CallableElement [i.e., the process] without any explicit DataAssociation." In other words, the dataInputs of the callActivity and the dataInputs of the called process are identical, by definition.
Bottom line: Camunda/Activiti and Oracle don't do data flow the same way, and probably models including data flow could not be interchanged. This is not a BPMN-I issue, but a BPMN spec issue. Section 10.3 of the spec seems a bit of a mess, and they ought to clean it up. But I'm not sure there is a "they" any more...