1. OMG Issue

BPMN11 — shared collaboration

  • Key: BPMN11-13
  • Legacy Issue Number: 9363
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This was submitted to BPMN members in addition to the OASIS ebBP list 13-14 February 2006. This is sent in an abbreviated fashion to FTF for comment inclusion.

    Diagram examples: http://www.oasis-open.org/committees/download.php/16684/ebxmlbp-v2.0.2-Document-pr-BPMN-r02-en.zip

    As a subsequent followup between BPMN and ebBP (discussions 7 and 9 February 2006), our team has begun to delve deeper into using (future) joint activity, associate the operation activities to business transaction activities, show the use of business signals and business signal exceptions (such as Negative Receipt Acknowledgement) and understand what questions remain.

    Initial thoughts of potential needs (current or future) for BPMN that may be relevant for shared collaboration [1]:

    1. Visibility of the BT pattern and its constraints and guidelines
    2. Business QoS aspects (guidance that may translate to technical
    mechanisms in the messaging infrastructure)
    3. More detailed modeling of the business document (this may be part
    of properties). This may be too granular for BPMN however.
    4. Need for end timers

    • Timers are not just for exceptions but may be for receipt of
      a business signal (Receipt or Acceptance Ack), and for the
      overall collaboration, activity, etc.
      5. Need to be able to model simply multiple internal processes to
      support different operations, or the same operation using
      different mechanisms.
      6. How to effectively show how a business partner may assume many
      roles in a pool.
    • For example, a Supplier (exposed in Business Collaboration)
      may assume the roles of Buyer, Distributor or Seller. These
      roles may be specific to the activities within a joint
      activity or be associated with the activities defined
      elsewhere but visible in a Complex Business Transaction
      Activity. Visibility and participation in this activity are different but may be associated.
      7. Last year we spoke to some of your team members about the use of inclusive OR gateway, and intermediate or end
      messages for representing that a response could be several different types of responses (cancel, change, accept for
      example). The current BPMN semantics preclude use of message flows into / out of a gateway. In addition, we couldn't
      determine how to indicate that multiple types of business messages (specifically) may occur. We originally used
      exclusive rather than an inclusive OR gateway notation object (per BPMN suggestion in September). With inclusive
      OR, parallelism could result. For example, in a decision, it is modeled that one path is taken. In order to represent the sequence flow into a gateway, and several possible paths out (termed end messages in BPMN), I opted
      to use the inclusive OR gateway as suggested. In ebBP, forks can be non-deterministic intentionally. Forks can
      resemble a non-deterministic OR or parallel ANDs or exclusive OR (like a Decision). This question arose outside of
      the option to use a future joint activity.

    What gateway control type is appropriate when you actually could
    have n potential paths on a fork or join,
    and either only one is actually performed or many could be
    performed, and business messages are sent? This is actually a conceptual difference in current BPMN v1.0 and
    collaboration whereby not all paths may be rendered executable or be used in execution (monitorable in ebBP context).

  • Reported: BPMN 1.0b1 — Tue, 14 Feb 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

  • Updated: Fri, 6 Mar 2015 20:57 GMT