I rarely get comments on my obscure techie BPMN 2.0 posts, but this one seems to have legs. Kris Verlaenen of jBPM has a thoughtful response, posted both as a comment to mine and on his own site (to show a diagram). He says,
It seems to me, from reading the specification, that data input and output associations are meant to be "local", by which I mean they are not intended to be referenced from outside the element in which they are defined. On top of that, it also seems to me that they are intended to be "immediate" or "instantaneous"... meaning they are "executed" when they are reached, but they don't exist anymore after that. Therefore, I would agree with your statement that process data inputs should not be the source of a data input association, as the process data input association only exists when the process is invoked and at that point, that data input association is executed.... I think the ioSpecification of the process, that contains these process data inputs, should also contain data output associations that map these data inputs to more persistent (as opposed to immediate or instantaneous) item-aware elements like a property or a data object. These can then serve as the source of other data input associations.Intuitively I agree with Kris. Also, this is the way Oracle said their BPMN 2.0 engine works. And it is different from the proposal from Falko Menge of Camunda/Activiti. Pictures may be helpful.
Here is a diagram showing a process data input directly feeding an activity data input, as favored by Falko Menge:
And here is the alternative suggested by Kris Verlaenen, in which the process data input is first stored in a data object, which then feeds the activity data input:
In a way, both these diagrams imply that the input data just shows up magically, but that is not the case. There are only two ways, in reality, that the input data can arrive at the process data input, either from the start event trigger (such as a message) or from a call activity in a "parent" BPMN process. The BPMN spec allows a message start event to have a dataOutputAssociation to the process data input. So in this case, I believe Falko's picture would look like this:
And I think Kris's picture (also that of Oracle) would look like this:
Here the process data input just serves invocation by call activity. When triggered by a message, the data flow is from the message start event to a data object to the activity data input.
OK, so what? Two things: First, whichever approach is correct, clarification in the BPMN 2.0 (2.1?) spec is needed. Falko proposed some language that allows direct data association from process data input to activity data input, where the question of whether that is allowed is ambiguous in the spec as is. But I think that language would allow all four of these diagrams, and this might limit interoperability of BPMN models where vendors of executable BPMN 2.0 make different assumptions about what a process data input means. For that reason, I think it is important that all interested parties weigh in, so that any clarifying language in the spec makes things better not worse.