BPMN 2.0 FTF Avatar
  1. OMG Issue

BPMN2 — Multiple properties / keys clarification

  • 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,
    -Matthias

    From: 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.

  • 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