-
Key: BPMN2-112
-
Legacy Issue Number: 14648
-
Status: closed
-
Source: NIST ( Mr. Conrad Bock)
-
Summary:
http://www.osoa.org/jira/browse/BPMN-585
Does the first message in an Conversation need to have values for all
the properties of a correlation key, or can some values appear in later
messages?When a conversation has multiple correlation keys, do all the properties
of all the keys need to match in each message, or just the properties
for one of the keys?Can a message later in a conversation send values for only some of the
properties in a key?Comments:
From: conrad.bock created: Tue, 4 Aug 2009 14:15:01 -0500 (CDT)
Conrad,I doubt the spec is precise enough on that yet - so here is my
personal take on what we want it to say:- All properties constituting a correlation key MUST (SHOULD?) be set
by a single message in a conversation (Rationale: We don't want a
partially set key.)
- Not all correlation keys of a given conversation need to be set at
any given time. (Rationale: Conversation keys could be added over
the lifetime of a conversation, no reason to prevent this.)
- When associating an (inbound) message with a conversation, all
properties of all correlation keys contained in that message must
match those already set for the conversation (instance). (Rationale:
We could relax that, having it strict simplifies the rules and
increases usability; I don't see why a message would ever contain
multiple correlation keys some of which do not match, but could be
convinced otherwise through scenarios. Of course a message does not
have to contain properties for all correlation keys that may be used
for a conversation, but those that it uses must match.)
With that the answers to your questions would be:
- Not all must be contained, some could be delivered later - for
those correlation happens based on the keys that were already set
by the first message.
- Yes, all must match - see rationale above, we could relax that if
we see a good reason.
Hopefully that makes sense - and hopefully I got the terminology
right, admittedly I didn't check back with the spec but answered from
memory.Viele Grüße/Kind regards,
-MatthiasFrom: conrad.bock created: Wed, 5 Aug 2009 08:40:28 -0500 (CDT)
These clarification affects the second paragraph of the Key-based
Correlation subsection of Section 8.3.3 (Correlation):At runtime the first Send Task or Receive Task in a Conversation
populates the CorrelationKey instance by extracting the values of the
CorrelationProperties according to the
CorrelationPropertyRetrievalExpression from the initially sent or
received Message. Later in the Conversation, this CorrelationKey
instance is used for the described matching procedure where from
incoming Messages a composite key is extracted and used to identify
the associated Conversation.New keys might appear during the converstion. For example, the initial
message from a customer placing an order might not include the order
number. This is assigned by a new process instance and used to
correlate messages later in the conversation. - All properties constituting a correlation key MUST (SHOULD?) be set
-
Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
-
Disposition: Resolved — BPMN 2.0
-
Disposition Summary:
under Section 8.3.3, replace the text of the first bullet with this text:
In plain, key-based correlation, Messages that are exchanged within a Conversation are logically correlated by means of one or more common CorrelationKeys. That
is, any Message that is sent or received within this Conversation needs to carry the value of at least one of these CorrelationKey instances within its payload. A
CorrelationKey basically defines a (composite) key. The first Message that is initially sent or received initializes one or more CorrelationKey instances associated with
the Conversation, i.e., assigns values to its CorrelationProperty instances which are the fields (partial keys) of the Correlation-Key. A CorrelationKey is only
considered valid for use, if the Message has resulted in all CorrelationProperty fields within the key being populated with a value. If a follow-up Message derives a
CorrelationKey instance, where that CorrelationKey had previously been initialized within the Conversation, then the CorrelationKey value in the Message and
Conversation MUST match. If the follow-up Message derives a CorrelationKey instance associated with the Conversation, that had not previously been initialized, then
the CorrelationKey value will become associated with the Conversation. As a Conversation may comprise different Messages that may be differently structured, each
CorrelationProperty comes with as many extraction rules (CorrelationPropertyRetrievalExpression) for the respective partial key as there are different Messages.
under section 8.3.3 Correlation, the under the title "Key-based Correlation", replace the second paragraph with this text:
At runtime the first Send Task or Receive Task in a Conversation MUST populate atleast one of the CorrelationKey instances by extracting the values of the
CorrelationProperties according to the CorrelationPropertyRetrievalExpression from the initially sent or received Message. Later in the Conversation, the populated
CorrelationKey instances are used for the described matching procedure where from incoming Messages a composite key is extracted and used to identify the
associated Conversation. Where these non-initiating Messages derive values for CorrelationKeys, associated with the Conversation but not yet populated, then the
derived value will be associated with the Conversation instance.
Disposition: Resolved -
Updated: Fri, 6 Mar 2015 20:57 GMT