BPMN2 — Beta 1: Is a Message a DataInput for an Activity; Is Message Flow a Data Association

Is Message Flow another type of Data Association? This would mean that Messages can be mapped to the Data Inputs of Activities.
Is there another way to use Message as an Activity Input?

Comments:
From: conrad.bock created: Thu, 5 Feb 2009 08:54:23 -0600 (CST)
This would be a subtopic of <a href="http://www.osoa.org/jira/browse/BPMN-229" title="Reuse of processes in orchestration and choreography">BPMN-229</a>.

From: ings_osoa created: Tue, 10 Mar 2009 10:32:59 -0500 (CDT)
Steve notes that this issue may arise during our samples work and if so we can resolve it in that context. Otherwise he agrees it should be deferred.

Formatted versions are available here:
10_process-activities_updatedFor359_v2.doc
10_process-data_updatedFor359_v2.doc
10_process-events_updatedFor359_v3.doc
14_execsem_updatedFor359_v2.doc
(a) Replace the first paragraph after Figure 10.11 with the following:
"The Service Task inherits the attributes and model associations of Activity (see Table 103). In addition the following constraints are introduced when the Service Task
references an Operation: The Service Task has exactly one InputSet and at most one OutputSet. It has a single data input with an ItemDefinition equivalent to the one
defined by the Message referenced by the inMessageRef attribute of the associated operation. If the operation defines output Messages, the Service Task has a single
data output that has an ItemDefinition equivalent to the one defined by the Message referenced by the outMessageRef attribute of the associated operation."
(b) Add a new paragraph immediately after Figure 10.14 with the following:
"The Send Task inherits the attributes and model associations of Activity (see Table 10.1 ). In addition the following constraints apply when the Send Task references a
Message: The Send Task has at most one input set and one data input. If the data input is present, it must have an ItemDefinition equivalent to the one defined by the
associated Message. At execution time, when the Send Task is executed, the data automatically moves from the data input on the Send Task into the Message to be
sent. If the data input is not present, the Message will not be populated with data from the process."
(c) Add a new paragraph immediately after Figure 10.15 with the following:
"The Receive Task inherits the attributes and model associations of Activity (see Table 10.1 ). In addition the following constraints apply when the Receive Task
references a Message: The Receive Task must have at most one output 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. At execution time, when the Receive Task is executed, the data automatically moves from
the Message to the data output on the Receive Task. If the data output is not present, the payload within the Message will not flow out of the task and into the
process."
(d) Section 10.3.1, last paragraph on page 182 (212 pdf): delete ", Messages" from the last sentence.
(e) Table 10.52, attributes "dataInputs" and "dataOutputs": add "This is an ordered set" to their descriptions.
(f) First paragraph after Table 10.54, change "outputs to the specific Activity implementations" to "outputs to specific Activity and Event implementations"
(g) Section 10.3.1, Sub-Section Service Task Mapping: replace the two (2) paragraphs of the section with the following:
"If the Service Task is associated with an Operation there must be a single 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."
(h) Add a new Sub-Section after Sub-Section Service Task Mapping, with a title of "Send Task Mapping" and contents of the following:
"If the Send Task is associated with a Message, there must be at most one input 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."
Add a new Sub-Section after Sub-Section Service Task Mapping, with a title of "Receive Task Mapping" and contents of the following:
"If the Receive Task is associated with a Message, there must be at most one output 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 Event and into the process."
(j) Add a new Sub-Section after Sub-Section Script Task Mapping, with a title of "Events" and contents of the following:
If any of the EventDefinitions for the Event is associated with an element that has an Item Definition (such as a Message, Escalation, Error, Signal), the following
constraints apply:
[bullet] If the Event is associated with multiple Event Definitions, there must be one data input (in the case of Throw Events) or one data output (in the case of Catch
Events) for each Event Definition. The order of the Event Definitions and the order of the data inputs/outputs determine which input/output corresponds with which
Event Definition.
[bullet] For each Evant Definition and input/output pair, if the input/output is present, it must have an ItemDefinition equivalent to the one defined by the Message,
Signal, Error or Signal on the associated Event Definition. In the case of a ThrowEvent, if the data input is not present, the Message, Escalation, Error, or Signal will not
be populated with data. In the case of a CatchEvent, 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.
(k) Replace Figure 10.66: ThrowEvent.dataInputs and CatchEvent.dataOutputs to have multiplicity of 0..n
(l) Section 10.4.1, Sub-Section Data Modeling and Events: Replace the 2nd sentence of the 1st paragraph with the following:
"For such Events, the following constraints apply:
[bullet]If the Event is associated with multiple Event Definitions, there must be one data input (in the case of Throw Events) or one data output (in the case of Catch
Events) for each Event Definition. The order of the Event Definitions and the order of the data inputs/outputs determine which input/output corresponds with which
Event Definition.
[bullet]For each Evant Definition and input/output pair, if the input/output is present, it must have an ItemDefinition equivalent to the one defined by the Message,
Signal, Error or Signal on the associated Event Definition. In the case of a ThrowEvent, if the data input is not present, the Message, Escalation, Error, or Signal will not
be populated with data. In the case of a CatchEvent, 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.
The execution behavior is then as follows:
[bullet]For Throw Events: When the event is activated, the data in the data input is automatically assigned to the Message, Signal, Escalation or Error referenced by the
corresponding EventDefinition.
[bullet]For Catch Events: When the trigger of the event occurs (for example, the Message is received), the data is automatically assigned to the data output that
corresponds to the EventDefinition that described that trigger."
(m) Section 10.4.1: Delete Sub-Section "Catch Event Data Association" and delete Sub-Section "Throw Event Data Association"
Table 10.75, attributes "eventDefinitionRefs", "eventDefinitions", and "dataOutputs": add "This is an ordered set" to their descriptions.
(o) Table 10.76, attributes "eventDefinitionRefs", "eventDefinitions", and "dataInputs": add "This is an ordered set" to their descriptions.
(p) Section 14.2.3: Replace the description of the bullet for Service Task with the following: "Upon activation, the data in the inMessage of the Operation is assigned
from the data in the data input of the Service Task, and the Operation is invoked. On completion of the service, the data in the data output of the Service Task is
assigned from the data in the outMessage of the Operation, and the Service Task completes. If the invoked service returns a fault, that fault is treated as interrupting
error, and the Activity fails."
(q) Section 14.2.3: Replace the description of the bullet for Send Task with the following:
"Upon activation, the data in the associated Message is assigned from the data in the data input of the Send Task. The Message is sent and the Send Task completes."
(r) Section 14.2.3: Replace the description of the bullet for Receive Task with the following:
"Upon activation, the Receive Task begins waiting for the associated Message. When the Message arrives, the data in the data output of the Receive Task is assigned
from the data in the Message, and Receive Task completes."
(s) Section 14.2.3, Bullet for User Task: Replace "instantiation" with "activation"
(t) Section 14.2.3, Bullet for Manual Task: Replace "instantiation" with "activation"
(u) Section 14.2.3, Bullet for Business Rule Task: Replace "instantiation" with "activation"
(v) Section 14.2.3, Bullet for Script Task: Replace "instantiation" with "activation"
(w) Section 14.2.3, Bullet for Abstract Task: Replace "instantiation" with "activation"
Disposition: Resolved