Business Process Model And Notation Avatar
  1. OMG Specification

Business Process Model And Notation — Closed Issues

  • Acronym: BPMN
  • Issues Count: 35
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
BPMN-30 Reference Subprocess BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-29 Time intervals modeling is imprecise BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-27 Section 12 of the specification should be moved as is to an appendix BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-28 Section 4.3.3 Reference to "missing" shape BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-26 Diagram with an "Invisible Pool" BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-23 optional description attribute BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-25 Clarify why BPMN separates data and sequence BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-22 BPMN Adopted Spec issue - Clarify behavior of Error intermediate event BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-21 Section: 4.6 BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-24 restriction to be placed on the number of tokens BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-20 Is it really the Complete Set? BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-17 unclear what Figure 13 on p. 71 represents BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-18 Which is it, (OR-Join) or (XOR) Gateway? BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-16 complicated notation BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-19 Are there 3 or are there 4 Standard Artifacts? BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-14 Unclear semantics of Group BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-15 Ambiguous notations for OR BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-12 No means to define Categories BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-13 Ambiguous notations for Association BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-10 BPEL over-pervasive in document BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-11 BPEL mapping hard to follow BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-9 compliance level to cover core elements/simple business modeling BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-7 Unclear whether BPEL is part of Conformance BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-8 Irrelevant conformance point BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-6 Mapping to BPEL should be moved to the appendix BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-5 Section 6 of the current specification should be moved as an appendix BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-2 BPMN comment: additional artifacts BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-4 BPMN comment BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-3 Sec. 6.16 BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-1 Business Process Diagrams BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-34 Start Events with triggers on a subprocess BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-35 SubProcessRef BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-33 Role association to subprocesses BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-32 Performers BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-31 Definition of "Expression" BPMN 1.0b1 BPMN 1.0 Resolved closed

Issues Descriptions

Reference Subprocess

  • Key: BPMN-30
  • Legacy Issue Number: 9564
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Reference Subprocess defines Input/OutputPropertyMaps attributes to
    define actual parameters, while there is no clean way to define formal
    parameters of the process.

  • Reported: BPMN 1.0b1 — Thu, 13 Apr 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

Time intervals modeling is imprecise

  • Key: BPMN-29
  • Legacy Issue Number: 9562
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Time intervals modeling is imprecise. Specification lists related
    field as TimeDate:Date and TimeCycle:String. In fact, modelers typically
    need to specify time interval since some event (e.g. starting the
    enclosing process). Enumerated cycle values (daily/weekly/monthly) or
    cycle interval and number of cycles would also be handy. Consider the
    way Outlook calendars handles regular meeting appointments. It would be
    nice to model advance reminder as separate entity (timer event occurring
    before another scheduled event).

  • Reported: BPMN 1.0b1 — Thu, 13 Apr 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

Section 12 of the specification should be moved as is to an appendix

  • Key: BPMN-27
  • Legacy Issue Number: 9411
  • Status: closed  
  • Source: Department of Veterans Affairs ( Stephen White)
  • Summary:

    Section 12 of the specification should be moved as is to an appendix, based on its focus on mapping to BPEL. In addition, the text from that section that does not deal with BPEL mapping should be copied and placed within the Overview section (Section 7).

  • Reported: BPMN 1.0b1 — Fri, 3 Mar 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

Section 4.3.3 Reference to "missing" shape

  • Key: BPMN-28
  • Legacy Issue Number: 9412
  • Status: closed  
  • Source: Embarcadero Technologies ( Michelle Vanchu-Orosco)
  • Summary:

    I am not sure what shape the following information is referring to as no reference to a figure and no shape appear to be provided. I am also not certain how this relates to End Events.

    Section 4.3.3. End (p. 52)

    This shape is OPTIONAL: a given Process level—a top-level Process or an expanded Sub-Process—MAY (is not required to) have this shape:

  • Reported: BPMN 1.0b1 — Wed, 8 Mar 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

Diagram with an "Invisible Pool"

  • Key: BPMN-26
  • Legacy Issue Number: 9409
  • Status: closed  
  • Source: Embarcadero Technologies ( Michelle Vanchu-Orosco)
  • Summary:

    We have a couple of questions relating to the notion of a diagram with an “invisible pool”.

    Per p. 42 “A BPD SHALL contain one or more Pools. The boundary of one of the Pools MAY be invisible (especially if there is only one Pool in the Diagram).”

    How would an “invisibly-bordered” pool be represented in the diagram? Or would this be implicit when creating the diagram?
    Would you be able to add lanes to an “invisibly-bordered” pool? We should propose the user is not able to add lanes to an “invisibly-bordered” pool as it could become a diagram containing pools…

  • Reported: BPMN 1.0b1 — Thu, 2 Mar 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

optional description attribute

  • Key: BPMN-23
  • Legacy Issue Number: 9377
  • Status: closed  
  • Source: me.com ( Frank McCabe)
  • Summary:

    Every element in a diagram should have an optional description attribute. This is in addition to the name and properties' attributes. One issue to decide is whether a description attribute should have structure - whether it refers to a machine-processable description or a human oriented description. Essentially both are important

  • Reported: BPMN 1.0b1 — Thu, 23 Feb 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

Clarify why BPMN separates data and sequence

  • Key: BPMN-25
  • Legacy Issue Number: 9408
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Clarify why BPMN separates data and sequence, for example, in Figure 10.11. The proposed resolution to http://www.bpmn.org/FTF/Issues/Issue%209113.htm should respond to this issue, rather than 9113, which is about how to bind sequence and data flow.

  • Reported: BPMN 1.0b1 — Thu, 2 Mar 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

BPMN Adopted Spec issue - Clarify behavior of Error intermediate event

  • Key: BPMN-22
  • Legacy Issue Number: 9367
  • Status: closed  
  • Source: iGrafx ( Rob Bartel)
  • Summary:

    I feel that the definition of the behavior of the Error intermediate Event is unclear in the BPMN Adopted Specification. We implemented its behavior to closely model the <throw>/<catch> in BPEL, but upon discussion with one of our customers and then with Steve it appears that our interpretation of the spec is not what was intended by its authors.

    Error intermediate Events are discussed with any detail in the following places in the spec:

    --------------------------

    Table 9.6 (p. 41) describes the End event and says - "This type of End indicates that a named Error should be generated. This Error will be caught by an Intermediate Event within the Event Context."

    Table 9.8 (p. 45) describes the Error intermediate event - "This is used for error handling--both to set (throw) and to react to (catch) errors. It sets (throws) an error if the Event is part of a Normal Flow. It reacts to (catches) a named error, or to any error if a name is not specified, when attached to the boundary of an activity."

    Table 9.9 (p. 46, 47) has Error intermediate event attributes described. The behavior described there relates to the ErrorCode.

    Text on p 59-60 describes its role in modeling a Hazard in a Business Transaction.

    Text on p 76 mentions it can be a target of an Event-based Gateway, although on p. 78 under "Changes since the 1.0 draft version" it says that Error was removed as a possible target. I believe the text on p

    76 is an editing error.

    Text on page 130-131 describes the "Event Context", mentioned in table 9.6. Text on that page in the last paragraph explicitly compares Error to the BPEL4WS fault, and goes on in that paragraph to describe the role of the ErrorCode.

    Table 11.5 (p. 141) mentions that Error end events map to BPEL throw elements, again tying it to the notion of faults.

    Table 11.10 (p. 145) describes the mapping to BPEL for intermediate Error event, which proposes that a boundary event be mapped to a <catch> within a <scope> that encompasses the activity.

    ------------------------

    From this somewhat limited description, we chose to implement Error as a strictly hierarchical faulting mechanism, as it is in BPEL as well as most programming languages, and which seems a direct consequence of the mapping in Table 11.10. However, in subsequent discussion I have learned it was the intention of the authors that Errors be "subscribed" to in a global scope, and that they will be responded to from any activie location in the process, but that the highest "parent" activity in a subprocess hierarchy will supersede (and terminate) any lower-level Error intermediate events. (This is my interpretation of an email thread with Steve on this subject that is not crisp enough to include verbatim in this issue. I may have interpreted it wrongly, however.)

    If the intention of BPMN is to allow Error to be used as a parallel- thread signaling mechanism (supporting a "first one done wins" pattern, for example) as well as a hierarchical faulting mechanism (where the scope in which a thrown Error can be caught is limited to the hierarchy of parents of the activity that causes it, including the activity itself) then the behavior of a number of ambiguous topologies need to be clarified in the spec. Also, I believe the mapping to BPEL is incorrect for the signaling use, and that for some configurations a correct mapping may not exist.

    In any event, clarifying the scope of the Event Context with respect to the behavior of the Error event seems necessary.

    -------------------------

    My proposed resolution will be for the text to make it clear that Error can only be caught by the activity that causes it or one of its parents. There are several other alternatives to use for signaling between parallel sequence flows, including our suggestion to our customers that the Rule event be used.

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

    No Data Available

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

Section: 4.6

  • Key: BPMN-21
  • Legacy Issue Number: 9361
  • Status: closed  
  • Source: CA Technologies ( Donna Burbank)
  • Summary:

    The spec mandates that "if there is only one lane, then that lane shares the name of the POOL, and only the POOL name is displayed. If there is more than one lane, then each lane has to have its own name and all names are displayed". Request is to remove the requirement making lane name dependent upon pool name. Suggested text "If there is only one lane, only the pool name is displayed. If there is more than one lane, the name of the individual lanes must be displayed as well as the name of the pool." With this change, if there is only one lane, the lane name is not shown, but the user is free to rename the name of the lane, if desired.

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

    No Data Available

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

restriction to be placed on the number of tokens

  • Key: BPMN-24
  • Legacy Issue Number: 9378
  • Status: closed  
  • Source: me.com ( Frank McCabe)
  • Summary:

    I believe that there should be a restriction placed on the number of tokens that may be present on a given wire. If a situation arises where there are several tokens on a given wire coming into a merge gateway then there is a correlation problem between the multiple incoming tokens on one wire and tokens arriving on other wires. Such correlation becomes a serious business problem when documents are associated with token flows. E.g. if there are two tokens on one wire and two tokens on another wire then there are two different ways of correlating the merging tokens. Proposed resolution: restrict the number of tokens on a given wire in a single instance of a process to zero or one.

  • Reported: BPMN 1.0b1 — Thu, 23 Feb 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

Is it really the Complete Set?

  • Key: BPMN-20
  • Legacy Issue Number: 9356
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Details:
    Section 8.2 is entitled "BPD Complete Set", and Table 8.3 is "BPD Complete Element Set", but the text says that that what the table displays is just "... a more extensive list" showing what "...could be depicted through a business process modeling notation". If it is really the complete set, it is misleading to describe it in this way. I guess the topic is not what could be depicted with a business process modeling notation, but rather the full extent of what is provided for with the BPMN notation as specified in this document.

    This issue suggest that the provision for extending the notation should not be scattered (as it is now) throughout the document, so that better clarity can be achieved between the notation provided in the spec, and the possiblity of user extensions of that notation. The problem now is that the possiblilty of adding new notations is getting mixed in with the purported presentation of the COMPLETE SET.

  • Reported: BPMN 1.0b1 — Thu, 2 Feb 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

unclear what Figure 13 on p. 71 represents

  • Key: BPMN-17
  • Legacy Issue Number: 9345
  • Status: closed  
  • Source: CA Technologies ( Donna Burbank)
  • Summary:

    I am unclear what Figure 13 on p. 71 represents. The bottom part of the diagram appears to show multiple pools joined together(Employee, Retail, etc.), showing lanes without labels. Is this a single poole or multiple pools?

  • Reported: BPMN 1.0b1 — Wed, 1 Feb 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

Which is it, (OR-Join) or (XOR) Gateway?

  • Key: BPMN-18
  • Legacy Issue Number: 9353
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Issue summary: Which is it, (OR-Join) or (XOR) Gateway?

    Note: This issue is closely related to 9327

    Details:
    See page 24, adopted spec 06-01-01
    Table 8.3, BPD Complete Element Set
    row for "Merging (OR-Join)"
    Text tells how to use "A Merging (XOR) Gateway", but the name of the model element is given as "Merging (OR-Join)".
    Then in row "Gateway control types" on page 20 it bives the names as 'XOR' and 'OR' as names of distinct types of control
    It seems to me that the author of the text in the row for "Merging (OR-Join)" was thinking of xor as being a sort of specialization of inclusive or, and so mixed a discussion of the OR and XOR together, but this is inconsistent with defining OR as meaning inclusive or. This needs to be rewritten to be consistent.

  • Reported: BPMN 1.0b1 — Thu, 2 Feb 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

complicated notation

  • Key: BPMN-16
  • Legacy Issue Number: 9343
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Sometimes It is too complicated notation.
    Can I use standard defacto notation like UML, DSL or others ?
    We have limited time to learn the new one to adapt new notation and give
    training to other parties.
    Maybe you should give more choice for the notation like you can use class
    diagram (in UML of course) with stereotypes with limited features, or you
    can use pure BPMN notation with full feature; or maybe you can use some
    translation or search some equal diagram from BPMN to other diagram
    to make the beginners understand.

    I suggest you create a templates to plug into MS Visio, Rational Rose
    Petal or other CASE tool to make users adapt the notation quickly.
    Perhaps you can build the beta version until the release

  • Reported: BPMN 1.0b1 — Tue, 31 Jan 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

Are there 3 or are there 4 Standard Artifacts?

  • Key: BPMN-19
  • Legacy Issue Number: 9354
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    See page 23, text just preceding table 8.1, adopted spec 06-01-01
    States "There are four standardized Artifacts" but then lists only three, followinng the text: "The current set of Artifacts include..."
    The use of "include" suggests there are more and the list is just some "for instance" examples of standardized artifacts."
    If their are four, please let us know which four they are.

  • Reported: BPMN 1.0b1 — Thu, 2 Feb 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

Unclear semantics of Group

  • Key: BPMN-14
  • Legacy Issue Number: 9326
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    Table 8.1: unclear if a Group groups Activities or objects in general. Can it have a name?

  • Reported: BPMN 1.0b1 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

Ambiguous notations for OR

  • Key: BPMN-15
  • Legacy Issue Number: 9327
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    Why 2 notations for Data based XOR
    Why not data and event options for inclusive OR?

  • Reported: BPMN 1.0b1 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

No means to define Categories

  • Key: BPMN-12
  • Legacy Issue Number: 9324
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    Several elements can have Categories attached. This is documented in Table 8-7 as "the Modeler may add one or more defined Categories"...However there is no mechanism for creating the 'defined categories' (as opposed to using them).

  • Reported: BPMN 1.0b1 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

Ambiguous notations for Association

  • Key: BPMN-13
  • Legacy Issue Number: 9325
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    Table 8.1: does not explain the difference between the 2 depictions of Associations given (one with an arrow)

  • Reported: BPMN 1.0b1 — Sun, 29 Jan 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

BPEL over-pervasive in document

  • Key: BPMN-10
  • Legacy Issue Number: 9322
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    In general I found the BPEL mapping aspect over-pervasive within the document, and not restricted to section 11. The impression could be gained that nothing can be a business process unless it can be represented in BPEL. This will tend to be off-putting to the business users the spec claims to address (I have no objection to the BPEL Mapping section) - it's just the constant references to BPEL to explain process modeling concepts and the BPMN notation. For example in the definition of the concepts in section 7.1.1 of private, public and abstract business process. Again I'm surprised there is no conformance point related to BPEL mapping.

  • Reported: BPMN 1.0b1 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

BPEL mapping hard to follow

  • Key: BPMN-11
  • Legacy Issue Number: 9323
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    found the mapping to BPEL somewhat hard to follow. In particular the use of indentation in tables such as 11.4.1 is not clear.

  • Reported: BPMN 1.0b1 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

compliance level to cover core elements/simple business modeling

  • Key: BPMN-9
  • Legacy Issue Number: 9321
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    The start of section 8 has the following which suggests 2 levels of compliance; however this opportunity has been missed in the conformance section: "First, there is the list of core elements that will support the requirement of a simple notation. These are the elements that define the basic look-and-feel of BPMN. Most business processes will be modeled adequately with these elements. Second, there is the entire list of elements, including the core elements, which will help support requirement of a powerful notation to handle more advanced modeling situations."

  • Reported: BPMN 1.0b1 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

Unclear whether BPEL is part of Conformance

  • Key: BPMN-7
  • Legacy Issue Number: 9319
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    Issue B) Unclear whether BPEL is part of Conformance
    Section 6.2 states "The BPMN specification supports for the following specifications is a normative part of the BPMN specification: BPEL4WS."
    but BPEL is not mentioned in the Conformance section 2

  • Reported: BPMN 1.0b1 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

Irrelevant conformance point

  • Key: BPMN-8
  • Legacy Issue Number: 9320
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    The Conformance section (2) has 3 points: 3rd of these is somewhat inoperative since it refers to a to-be-defined interchange format.

  • Reported: BPMN 1.0b1 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

Mapping to BPEL should be moved to the appendix

  • Key: BPMN-6
  • Legacy Issue Number: 9240
  • Status: closed  
  • Source: Agile Enterprise Design ( Fred Cummins)
  • Summary:

    Since BPMN is considered to provide a business-level representation of processes (i.e., a PIM), it is appropriate that the mapping to BPEL be moved to the appendix. In addition, the BPEL mapping should not be defined as a normative part of the specification since BPEL is viewed as a platform/execution language. In other words, the transformation could be different depending on the particular implementation of BPEL. A normative mapping to WSDL and choreography (which might be expressed in BPEL) is needed, but should be a mapping from a normative BPMN metamodel rather than the graphical notation.

  • Reported: BPMN 1.0b1 — Thu, 12 Jan 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

Section 6 of the current specification should be moved as an appendix

  • Key: BPMN-5
  • Legacy Issue Number: 9139
  • Status: closed  
  • Source: MEGA International ( Antoine Lonjon)
  • Summary:

    BPMN1. Section 6 of the current specification should be moved as an appendix
    2. All attributes related to the BPEL mapping should be removed

  • Reported: BPMN 1.0b1 — Wed, 1 Mar 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    see below

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

BPMN comment: additional artifacts

  • Key: BPMN-2
  • Legacy Issue Number: 9115
  • Status: closed  
  • Source: National TeleConsultants ( Ugo Corda)
  • Summary:

    The spec should specify which additional artifacts (e.g. WSDL files) are required to successfully generate BPEL processes.

    For example, sec. 6.16, Message mapping, refers to the "type attribute of the part". In case the type is a complex one, it looks like a WSDL file would be required in order to have the complete type description for BPEL generation purposes, but that is not mentioned in the spec.

  • Reported: BPMN 1.0b1 — Tue, 25 Oct 2005 04:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • 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

BPMN comment

  • Key: BPMN-4
  • Legacy Issue Number: 9121
  • Status: closed  
  • Source: Anonymous
  • Summary:

    BPMNOne point that need more precision in the BPMN specification is Inclusive Gateways behavior.
    The rule "When the Inclusive Gateway is used as a Merge, it will wait for (synchronize) all Tokens that have been produced upstream" is not clear at all.
    It can be applied in very simple situations (when a token is divided in several tokens when going out of an Inclusive Gateway, and merge at another Inclusive Gateway for example), but as no sense in more complex cases. As BPMN is very flexible and allows modeling of business processes that are not "block-structured" as opposed to BPEL, a more precise rule is needed for Inclusive Gateways.
    A discussion was opened by Petko Chobantonov on BPMN forum about this problem. He proposed another rule to clarify the Inclusive Gateway behavior but that led to nothing.

    Here is another comment:

    In the last version of the BPMN specification (Version 1.1 - July 31, 2005), a new rule was added on gateways (p 88):

    "If two or more Signals (Tokens) arrive to their respective Gates at the exact same time, then the Signal..."

    "exact same time" does not mean anything, and a rule like this has nothing to do in a "Notation" specification.

  • Reported: BPMN 1.0b1 — Mon, 20 Feb 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

Sec. 6.16

  • Key: BPMN-3
  • Legacy Issue Number: 9116
  • Status: closed  
  • Source: National TeleConsultants ( Ugo Corda)
  • Summary:

    Sec. 6.16 states that "The Type attribute of the Property will map to the type attribute of the part". This seems to imply that WSDL parts are always defined with a type attribute, which is not the case (i.e. they can also be defined with an element attribute instead of a type attribute).

  • Reported: BPMN 1.0b1 — Tue, 25 Oct 2005 04:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • 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

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

Business Process Diagrams

  • Key: BPMN-1
  • Legacy Issue Number: 9113
  • Status: closed  
  • Source: IBM ( Hossam Badawi)
  • Summary:

    I've been checking the BPMN for the connections, My question/comment is that why the spcification didn't introduce a type of connections that compines both Message and Flow (A connection that does both functions at the same time, it models the sequence and also models that data/message is being passed from the source object to the target object). Without having that type of a connection a diagram will contain many objects connected by two connections (one for the sequence and the other for the message) which leads to complexity in the diagram layout.

  • Reported: BPMN 1.0b1 — Fri, 17 Feb 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

Start Events with triggers on a subprocess

  • Key: BPMN-34
  • Legacy Issue Number: 9905
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    What are the semantics of a Start Event with a Trigger in of a subprocess?
    When will the subprocess be instantiated ... when it's parent process sends
    it a token or when it receives the event trigger?

  • Reported: BPMN 1.0b1 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

SubProcessRef

  • Key: BPMN-35
  • Legacy Issue Number: 9907
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    The attribute "SubProcessRef" is of type Task (see page 82). Shouldn't it
    be of type "SubProcess"?

  • Reported: BPMN 1.0b1 — Fri, 7 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

Role association to subprocesses

  • Key: BPMN-33
  • Legacy Issue Number: 9897
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    Currently, roles can only be associated with tasks, via the "performers"
    attribute. However, it is common to associate roles with subprocesses. In
    the case of a subprocess, the meaning is one of responsibility for the
    subprocess rather than who performs the subprocess.

  • Reported: BPMN 1.0b1 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

Performers

  • Key: BPMN-32
  • Legacy Issue Number: 9896
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    Currently, only User Tasks and Manual Tasks can have performers. Suggest
    this be extended to other types of tasks, that is, allow association of
    performers with any kind of task.

  • Reported: BPMN 1.0b1 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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

Definition of "Expression"

  • Key: BPMN-31
  • Legacy Issue Number: 9893
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    The definition of "Expression", as given in section B.11.3, is ambiguous.
    More clarification is needed in the spec.

  • Reported: BPMN 1.0b1 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.0
  • Disposition Summary:

    No Data Available

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