One of the issues of using an XSD to check the validity of an XML file (as the BPMN2 specification provides), is that the XSD does not express all the constraints that a process must fulfill to be valid. A lot of constraints are expressed in the narrative sections of the specification. That’s why Bruce Silver is working on a profile for BPMN interoperability (BPMN-I) that could be used to check additional constraints, with the goal of achieving true interoperability between different vendors by making a lot of the “hidden” rules explicit.
During that work, Bruce (I hope he doesn’t mind me calling him Bruce, maybe I should say Mr. Silver based on my appreciation for the work he has done and is still doing in this area ;)) discovered some discrepancies (or at least some confusing statements) in the specification itself when it comes to the use of process data inputs in relation to data input associations. I’m not going to try and explain the issue in detail, I would like to refer the readers that might be interested in the details to his blog and the followup blog, as it contains all the details, including numerous references to the spec itself and a discussion on the topic. But to make a long story short:
Can a process data input be used as the source of a data input association of task that is contained inside the process?
Since Bruce is asking for input from other interested parties, and jBPM is offering a BPMN 2.0 engine, I thought I’d give it a try. But since I couldn’t find a way to put all this information and picture as a reply on his blog itself, I decided to write this blog entry and include my reply here (and to avoid splitting up the discussion I would suggest to add comments related to this topic on his blog as well). And at the same time I can invite other readers to give their 2 cents as well 😉 So here it goes:
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” (not sure this is the best term but I couldn’t come up with a better one at this point), 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 also believe that using a process data input when the process is actually started by a timer start event confusing, as it’s unclear where this information would come from, but that’s another issue.]
So how would you use your process data inputs in the remainder of your bpmn2 process then? 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. So you don’t directly use a process data input as the source of a data input association of (for example) a task, but you rather first map the process data input to a property using a data output association (as part of the process ioSpecification) and then use this property as the source of the data input association of the same task.
A screenshot of this in a real process is shown below (note that I deliberately chose a slightly different example to avoid using a start timer event in combination with a process data input as this makes it only more confusing):