Business Process Model And Notation Avatar
  1. OMG Specification

Business Process Model And Notation — Open Issues

  • Acronym: BPMN
  • Issues Count: 35
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
BPMN21-427 Please clarify if the usage of a XOR Join is not redundant BPMN 2.0.2 open
BPMN21-426 Is there a definite reason to exist for a XOR join gateway? BPMN 2.0.2 open
BPMN2-317 Event list seems to be not complete BPMN 2.0.2 open
BPMN2-316 Misprint in call activity view BPMN 2.0.2 open
BPMN2-315 Different explanation and example. BPMN 2.0.2 open
BPMN21-425 Example uses invalid DI attributes and wrong namespaces BPMN 2.0.2 open
BPMN21-421 "Flow Object" should be "Flow Node" BPMN 2.0.2 open
BPMN21-420 Typo: BPMN 2.0.2 open
BPMN21-419 Typo in example BPMN 2.0.2 open
BPMN21-418 Diagram 8.1 looks amateurish BPMN 2.0.2 open
BPMN21-417 Wrong sub-section reference numbers BPMN 2.0.2 open
BPMN21-415 Inconsistent BPMNShape Attributes in tables BPMN 2.0.2 open
BPMN21-413 Inconsistent semantics of multiple none start events BPMN 2.0.2 open
BPMN21-412 Attribute called BPMN 2.0.2 open
BPMN21-411 Relationship relates CMOF::Element, not Artifact BPMN 2.0.2 open
BPMN21-410 Unclear how to add new Artifact Types BPMN 2.0.2 open
BPMN21-409 Derivation of categorizedFlowElements is only given by visual nesting BPMN 2.0.2 open
BPMN21-408 Some of the descriptions in the bpmnElement column of the table are incorrect BPMN 2.0.2 open
BPMN21-406 Add start and intermediate events of type "User" BPMN 2.0.2 open
BPMN21-405 Outgoing sequence flows from event gateways should allow conditional expressions BPMN 2.0.2 open
BPMN21-403 Probable contradiction: Implicit compensation and Throwing Compensation Events BPMN 2.0.2 open
BPMN21-404 Define "Cancellation" more precisely BPMN 2.0.2 open
BPMN21-402 Intermediate Compensation Events can have outgoing Sequence Flows BPMN 2.0.2 open
BPMN12-35 Execution semantics of Activity with conditional outgoing Sequence Flows BPMN 2.0.2 open
BPMN21-400 p.172 Reference pointing to wrong figure, p.174/175 Event marker missing in figure BPMN 2.0.2 open
BPMN21-399 Inconsistent default value of dataStore/@isUnlimited BPMN 2.0.2 open
BPMN21-398 Clarification needed regarding converging exclusive gateway and slash marker BPMN 2.0.2 open
BPMN21-397 Task Description -- Internal Conflict BPMN 2.0.2 open
BPMN21-394 data storage element is missing in overview BPMN 2.0.2 open
BPMN21-393 Confusion over dataOutput attributes BPMN 2.0.2 open
BPMN21-389 Wrong table reference number BPMN 2.0.2 open
BPMN21-369 Missing event marker in Figure 10.30 BPMN 2.0.2 open
BPMN21-366 Section 10.3.4 Human Performer is not peorperly defined for implementation interpretation BPMN 2.0.2 open
BPMN21-374 Second occurance of sequential Multi-Instances should be parallel BPMN 2.0.2 open
BPMN21-373 Use of per mille symbol unclear (‰) BPMN 2.0.2 open

Issues Descriptions

Please clarify if the usage of a XOR Join is not redundant

  • Key: BPMN21-427
  • Status: open  
  • Source: Blume ( Steffen)
  • Summary:

    Software vendors seem to implement it as a mandatory step to close every XOR Gateway with a XOR Join.
    It seems that even the majority of users which can be found in the internet, assume or state that the XOR Join element has to used everytime a XOR Gateway is opened.
    Just a few sources state that the usage of the XOR Join gateway is optional.

    Since i don't see a definitie logical reason, to use the XOR Join gateway at all, i was researching the OMG BPNPs specifications, which seem not to clrarly state how to handle XOR Joins either.
    Therefore i open up this issue. Could you please state:

    1. is there really an imgainable situation, in which the XOR Join makes sense? Is this element really needed?
    2. What is your recommendation in usage?

    Thank you very much for any clarification

  • Reported: BPMN 2.0.2 — Mon, 2 Mar 2020 10:56 GMT
  • Updated: Mon, 2 Mar 2020 15:58 GMT

Is there a definite reason to exist for a XOR join gateway?

  • Key: BPMN21-426
  • Status: open  
  • Source: Blume ( Steffen)
  • Summary:

    Please excuse that i ask this question by opening this bug report. SInce i wasn't able to find a definite answer to the given question in the specification, it may more be a bug in terms of an missing clarification, which seem to lead to the situation, that certain software providers handle the use of a XOR Join Gateway in a way, that seem to be redundant, from a strictly logical perspective, by stating the use of a XOR Gateway without the following mandatory use of a XOR Join Gateway as an error.

    There seem to be two different understandings of the handling of the XOR Join gateway. The Majority seems to state, that using this in general would be the best practise, whereas I think, that the logical aspect should be paramount. (Form follows function). That is why I was starting to research for an official explanation.

    So, could the OMG point out:
    A: Which possible Situation could logically justify the existance of this element?
    B: What a desired best practice in the use of this element would be?

    Thank you very much for your help
    sincerly yours

  • Reported: BPMN 2.0.2 — Wed, 26 Feb 2020 09:28 GMT
  • Updated: Wed, 26 Feb 2020 17:34 GMT

Event list seems to be not complete

  • Key: BPMN2-317
  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    On p. 241 is written:

    A Start Event can also initiate an inline Event Sub-Process (see page 174). In that case, the same Event types as for
    boundary Events are allowed (see Table 10.86), namely: Message, Timer, Escalation, Error, Compensation,
    Conditional, Signal, Multiple, and Parallel.

    and on p. 174:

    The Start Event trigger (EventDefinition) MUST be from the following types: Message, Error,
    Escalation, Compensation, Conditional, Signal, and Multiple (see page 259 for more details).

    It seems that Timer and Parallel are missing the list on p. 174.

  • Reported: BPMN 2.0.2 — Thu, 16 Jan 2020 17:50 GMT
  • Updated: Fri, 17 Jan 2020 20:32 GMT

Misprint in call activity view

  • Key: BPMN2-316
  • Status: open  
  • Source: Kyiv ( Yevhen Mazhuha)
  • Summary:

    “Call activity” in the table looks like “None” (not market in bold).

  • Reported: BPMN 2.0.2 — Wed, 15 Jan 2020 14:12 GMT
  • Updated: Fri, 17 Jan 2020 20:32 GMT

Different explanation and example.

  • Key: BPMN2-315
  • Status: open  
  • Source: Kyiv ( Yevhen Mazhuha)
  • Summary:

    Example about figure 6.52 shows not about driver`s story

  • Reported: BPMN 2.0.2 — Wed, 15 Jan 2020 14:11 GMT
  • Updated: Fri, 17 Jan 2020 20:31 GMT

Example uses invalid DI attributes and wrong namespaces

  • Key: BPMN21-425
  • Status: open  
  • Source: Camunda Services GmbH ( Falko Menge)
  • Summary:

    The example in section 15.3.1 Document Structure on page 475 (PDF 505) uses invalid Diagram Interchange (DI) attributes and fails XML schema validation. The example seems to use an older DI version than the one published with BPMN 2.0. This is also visible in the different namespace URLs used.

    diagram1.bpmn:7: element BPMNDiagram: Schemas validity error : Element '{http://www.omg.org/spec/BPMN/20100524/DI}BPMNDiagram', attribute 'scale': The attribute 'scale' is not allowed.
    diagram1.bpmn:7: element BPMNDiagram: Schemas validity error : Element '{http://www.omg.org/spec/BPMN/20100524/DI}BPMNDiagram', attribute 'unit': The attribute 'unit' is not allowed.diagram1.bpmn:8: element BPMNPlane: Schemas validity error : Element '{http://www.omg.org/spec/BPMN/20100524/DI}BPMNPlane', attribute 'element': The attribute 'element' is not allowed.
    diagram1.bpmn fails to validate
    

    A fixed version that passes XML schema validation is available at:
    https://github.com/bpmn-miwg/bpmn-miwg-demos/tree/master/2020-06-omg-technical-meeting-boston/discussion/BPMN%202.0.2%20Section%2015.3.1%20Document%20Structure%20Example

  • Reported: BPMN 2.0.2 — Thu, 7 Nov 2019 08:46 GMT
  • Updated: Mon, 11 Nov 2019 19:57 GMT

"Flow Object" should be "Flow Node"

  • Key: BPMN21-421
  • Status: open  
  • Source: oose Innovative Informatik eG ( Axel Scheithauer)
  • Summary:

    The specification says in the (non normative) glossary:

    Flow Object - A graphical object that can be connected to or from a Sequence Flow. In a Process, Flow Objects are Events, Activities, and Gateways. In a Choreography, Flow Objects are Events, Choreography Activities, and Gateways.

    In the metamodel, the common superclass of Event, Activity, Choreography Activity, and Gateway is FlowNode. Does that mean, Flow Object and Flow Node are synonyms? Or is Flow Object the graphical object and Flow Node the model element? Both words are used throughout the specification, e.g.

    Table 7.3 displays the BPMN Flow Objects and shows how these objects can connect to one another through Sequence Flows.

    Of the types of Flow Node, only Activities, Gateways, and Events can be the target [of a Sequence Flow].

    Does it serve any purpose to have different names for the two? I find it confusing.

    Suggestion
    Replace all occurrences of "Flow Object" with "Flow Node".

  • Reported: BPMN 2.0.2 — Wed, 14 Nov 2018 17:22 GMT
  • Updated: Tue, 27 Nov 2018 20:46 GMT

Typo:

  • Key: BPMN21-420
  • Status: open  
  • Source: DAQRI ( Paul Chen)
  • Summary:

    Section 12.1.1 includes the text "miss-interpretations"

    The correct spelling is "misinterpretations"

  • Reported: BPMN 2.0.2 — Thu, 1 Nov 2018 23:40 GMT
  • Updated: Fri, 2 Nov 2018 14:01 GMT

Typo in example

  • Key: BPMN21-419
  • Status: open  
  • Source: DAQRI ( Paul Chen)
  • Summary:

    Section 6.1.1 includes this bullet point on conventions:

    • The cardinality of any content part is specified using the following operators:
    • <none> — exactly once

    I don't know whether this should be:
    • <1> — exactly once
    or
    • <one> — exactly once

    I could not find any examples of this syntax in the standard.

  • Reported: BPMN 2.0.2 — Thu, 1 Nov 2018 23:36 GMT
  • Updated: Fri, 2 Nov 2018 14:01 GMT

Diagram 8.1 looks amateurish

  • Key: BPMN21-418
  • Status: open  
  • Source: DAQRI ( Paul Chen)
  • Summary:

    Diagram 8.1 looks amateurish: the non-horizontal text labels are not aligned linearly, nor are the letters spaced evenly. The circular rings look like they were cut out of construction paper. This diagram doesn't have the quality one would expect to see in a formal international standard published by the OMG.

  • Reported: BPMN 2.0.2 — Thu, 1 Nov 2018 23:20 GMT
  • Updated: Fri, 2 Nov 2018 14:00 GMT

Wrong sub-section reference numbers

  • Key: BPMN21-417
  • Status: open  
  • Source: DAQRI ( Paul Chen)
  • Summary:

    The third paragraph of section 2.1 says:

    "The implementation claiming conformance to the Process Modeling Conformance type SHALL comply with all of the requirements set forth in sub clause 2.1. The implementation claiming conformance to the Process Execution Conformance type SHALL comply with all of the requirements set forth in sub clause 2.2. The implementation claiming conformance to the BPEL Process Execution Semantics Conformance type SHALL comply with all of the 2 Business Process Model and Notation (BPMN), v2.0.2 requirements set forth in sub clause 2.3. The implementation claiming conformance to the Choreography Conformance type SHALL comply with all of the requirements set forth in sub clause 2.4. The implementation is said to have BPMN Complete Conformance if it complies with all of the requirements stated in sub clauses 2.1, 2.2, 2.3, and 2.4."

    Each of the sub-section numbers referenced is off by 1. The correct paragraph text should be:

    "The implementation claiming conformance to the Process Modeling Conformance type SHALL comply with all of the requirements set forth in sub clause 2.2. The implementation claiming conformance to the Process Execution Conformance type SHALL comply with all of the requirements set forth in sub clause 2.3. The implementation claiming conformance to the BPEL Process Execution Semantics Conformance type SHALL comply with all of the 2 Business Process Model and Notation (BPMN), v2.0.2 requirements set forth in sub clause 2.4. The implementation claiming conformance to the Choreography Conformance type SHALL comply with all of the requirements set forth in sub clause 2.5. The implementation is said to have BPMN Complete Conformance if it complies with all of the requirements stated in sub clauses 2.2, 2.3, 2.4, and 2.5."

  • Reported: BPMN 2.0.2 — Thu, 1 Nov 2018 21:16 GMT
  • Updated: Fri, 2 Nov 2018 14:00 GMT

Inconsistent BPMNShape Attributes in tables

  • Key: BPMN21-415
  • Status: open  
  • Source: PragmaDev ( Mihal Brumbulli)
  • Summary:

    Collapsed activities have "None or isExpanded is false" as BPMNShape Attributes, while their corresponding Expanded form have "None or isExpanded is true".
    "None" should not appear in both forms as it creates confusion.
    This issue is present in the tables of Ad Hoc Sub-Process, Transaction, and Call Activity, but not in those of Sub-Process, Event Sub-Process, and Call Choreography Activity.
    Hence, the former group of tables should be corrected based on the later.

  • Reported: BPMN 2.0.2 — Thu, 19 Jul 2018 09:59 GMT
  • Updated: Tue, 7 Aug 2018 14:09 GMT

Inconsistent semantics of multiple none start events

  • Key: BPMN21-413
  • Status: open  
  • Source: oose Innovative Informatik eG ( Axel Scheithauer)
  • Summary:

    The specification says:

    10.5.2 Start Event All Flow Objects that do not have an incoming Sequence Flow SHALL be instantiated when the Process is instantiated.

    There are some exceptions to this rule, but they don't touch the following discussion. Since Events are Flow Objects, this applies also to Start Events: When the process with multiple Start Events is instantiated, all Start Events of this instance are instantiated (i.e. they get a token).

    Further down it says however:

    There MAY be multiple Start Events for a given Process level. Each Start Event is an independent Event. That is, a Process instance SHALL be generated when the Start Event is triggered.

    That means on instantiating a process, each Start Event gets instantiated, which in turn instantiates a new process. I don't think this was intended.

    In the same section the semantics for calling global processes is defined differently (without mentioning it as an exception to the above rule):

    If the Process is used as a global Process and there are multiple None Start Events, then when flow is transferred from the parent Process to the global Process, only one of the global Process’s Start Events will be triggered.

    So called global Processes are treated differently from Subprocesses (I know, somewhere else it is stated, that a Subprocess can only have a unique Start Event - a rule that is contradicted in the immediately following sentence). I think this is confusing.

    Suggestion
    Change the above sentence

    All Flow Objects that could have but do not have an incoming Sequence Flow SHALL be instantiated when the Process is instantiated.

    This way, multiple Start Events are always alternative. This would be in line with many other sections of the specification:

    13.2 Process Instantiation and Termination A Process is instantiated when one of its Start Events occurs. Each occurrence of a Start Event creates a new Process Instance [...] Note that two Start Events are alternative [...]

    and

    13.3.4 Sub-Process/Call Activity If the Sub-Process does not have incoming Sequence Flows but Start Events that are target of Sequence Flows from outside the Sub-Process, the Sub-Process is instantiated when one of these Start Events is reached by a token. Multiple such Start Events are alternative. [...]

  • Reported: BPMN 2.0.2 — Thu, 28 Jun 2018 18:01 GMT
  • Updated: Tue, 7 Aug 2018 14:03 GMT

Attribute called

  • Key: BPMN21-412
  • Status: open  
  • Source: Salient Process ( Neil Kolban)
  • Summary:

    The text today reads:

    An ItemAwareElement MAY be underspecified, meaning that the structure attribute of its ItemDefinition is optional if the modeler does
    not wish to define the structure of the associated data.

    I believe it should be:

    An ItemAwareElement MAY be underspecified, meaning that the structureRef attribute of its ItemDefinition is optional if the modeler does
    not wish to define the structure of the associated data.

    The ItemDefininition doesn't have an attribute called "structure".

  • Reported: BPMN 2.0.2 — Thu, 7 Jun 2018 19:15 GMT
  • Updated: Tue, 12 Jun 2018 15:11 GMT

Relationship relates CMOF::Element, not Artifact

  • Key: BPMN21-411
  • Status: open  
  • Source: oose Innovative Informatik eG ( Axel Scheithauer)
  • Summary:

    The specification says about External Relationships:

    These extensions’ intention is to extend the semantics of a given BPMN Artifact.

    The following text then refers consistently to BPMN Artifacts.

    The metamodel however specifies that a Relationship links all kinds of CMOF::Elements, not just BPMN::Artifacts.

    My guess is, that "BPMN Artifacts" was meant to read "BPMN elements", e.g.

    typed relationships that enable BPMN and non-BPMN Artifacts to be related

    should probably read

    typed relationships that enable BPMN and non-BPMN Artifacts elements to be related

  • Reported: BPMN 2.0.2 — Thu, 31 May 2018 12:33 GMT
  • Updated: Tue, 12 Jun 2018 15:11 GMT

Unclear how to add new Artifact Types

  • Key: BPMN21-410
  • Status: open  
  • Source: oose Innovative Informatik eG ( Axel Scheithauer)
  • Summary:

    The specification says about Extension:

    It provides a set of extension elements, which allows BPMN adopters to attach additional attributes and elements to standard and existing BPMN elements.

    In other words, extension can only add something to existing elements, but not create new element types.
    However about Artifacts it says:

    A modeler or modeling tool MAY extend a BPMN diagram and add new types of Artifacts to a Diagram.

    Given the extension mechanism, it is unclear, how new types of Artifacts can be added. And since the Metaclass Artifact is abstract, it is not possible to use the generic Artifact and extend it to create something resembling a new type. A modeler would always need to specify the concrete subclass, such as Group or TextAnnotation and thus inherit attributes and semantics he probably doesn't need.
    So either the sentence is wrong, or there is another extension mechanism, that needs some explanation here.

  • Reported: BPMN 2.0.2 — Thu, 31 May 2018 12:20 GMT
  • Updated: Tue, 12 Jun 2018 15:11 GMT

Derivation of categorizedFlowElements is only given by visual nesting

  • Key: BPMN21-409
  • Status: open  
  • Source: oose Innovative Informatik eG ( Axel Scheithauer)
  • Summary:

    The specification says:

    categorizedFlowElements:FlowElement [0..*] - The FlowElements attribute identifies all of the elements (e.g., Events, Activities, Gateways, and Artifacts) that are within the boundaries of the Group.

    This attribute is derived and the elements are found by looking at the diagram and determining, which elements are within the boundaries of the dashed box representing the Group. As far as I know, this is the only place in the specification, where the location of an element in the diagram is relevant for the semantics. I think there should be a more formal way.
    Further down the specification says:

    Groups are one way in which Categories of objects can be visually displayed on the diagram.

    If the only way to define a group is to show it in the diagram (as the first sentence implies), this sentence is wrong.

  • Reported: BPMN 2.0.2 — Wed, 30 May 2018 13:24 GMT
  • Updated: Tue, 12 Jun 2018 15:10 GMT

Some of the descriptions in the bpmnElement column of the table are incorrect

  • Key: BPMN21-408
  • Status: open  
  • Source: PragmaDev ( Mihal Brumbulli)
  • Summary:

    The description in the bpmnElement column of the table for the Sequence Flow, Conditional Sequence Flow, and Default Sequence Flow elements is incorrect. default neither is an attribute of the listed elements, nor it is of type boolean. It belongs to the element referenced by the sourceRef attribute, and can either reference an element or be undefined (it cannot be false).

  • Reported: BPMN 2.0.2 — Tue, 20 Mar 2018 16:36 GMT
  • Updated: Fri, 6 Apr 2018 19:33 GMT

Add start and intermediate events of type "User"

  • Key: BPMN21-406
  • Status: open  
  • Source: Atom Software Pty Ltd ( Paul Hopkins)
  • Summary:

    Introduce start and intermediate events of type “User”. Events of type User can be used to identify user initiated actions for example pressing a door-bell or selecting a menu item on a computer. At the moment the BPMN specification only allows these events to be modelled as conditional events or alternatively through the BPMN extension mechanism. Unfortunately the majority of vendors do not support the extension mechanism, they only support the main specification. Adding this to the main specification would greatly improve the BPMN's applicability and usability.

  • Reported: BPMN 2.0.2 — Mon, 19 Mar 2018 11:57 GMT
  • Updated: Fri, 6 Apr 2018 19:29 GMT

Outgoing sequence flows from event gateways should allow conditional expressions

  • Key: BPMN21-405
  • Status: open  
  • Source: Atom Software Pty Ltd ( Paul Hopkins)
  • Summary:

    Allow event-based gateways to have outgoing conditional flows. Section 10.6.6 of the BPMN specification v2.0.2 states that “The outgoing sequence flows of the event gateway must not have a conditional expression”. I suggest that this clause be changed because an initiating event-based gateway is an excellent way to model, for example, a menu, where not all items on a menu are available all the time (as they might depend upon user roles or the application’s state). With outgoing conditional flows from the event-based gateway this situation can be modelled easily. Of course modelling a menu is only one such scenario, and I appreciate that the conditions to be applied to the conditional flows could instead be applied to the events following the event-based gateway, but the use of conditional flows is simply a cleaner implementation.

  • Reported: BPMN 2.0.2 — Mon, 19 Mar 2018 11:52 GMT
  • Updated: Fri, 6 Apr 2018 19:28 GMT

Probable contradiction: Implicit compensation and Throwing Compensation Events

  • Key: BPMN21-403
  • Status: open  
  • Source: omninet.de ( Frank Munkert)
  • Summary:

    In table 10.88 "End Event Types", the table row with header "Compensation" contains this statement:
    "To be compensated, an Activity MUST have a boundary Compensation Event or contain a Compensation Event Sub-Process."
    The same applies to Table 10.89 "Intermediate Event Types in Normal Flow" on page 251.

    On page 234, however, there is this statement: "The compensation handler is either user defined or implicit."

    The two statements, taken together, would mean that an implicit compensation handler cannot be called by a Throwing Compensation Event.

    This probably is not intended.

    Either the concept of implicit compensation should be removed alltogether (which is not my preference), or alternatively the sentence
    "To be compensated, an Activity MUST have a boundary Compensation Event or contain a Compensation Event Sub-Process."
    should be changed like this:
    "To be compensated, an Activity MUST have a boundary Compensation Event or contain a Compensation Event Sub-Process, or the Activity must be a Sub-Process or a Call Activity calling a Process."
    because sub-processes and called processes always are implicitly compensable (unless the compensable attribute is set to false).

  • Reported: BPMN 2.0.2 — Thu, 5 Oct 2017 09:46 GMT
  • Updated: Wed, 18 Oct 2017 06:09 GMT

Define "Cancellation" more precisely

  • Key: BPMN21-404
  • Status: open  
  • Source: omninet.de ( Frank Munkert)
  • Summary:

    Chapter "10.5.1 Concepts" contains the following statement on page 234:
    "Cancellation will terminate all running Activities and compensate all successfully completed Activities in the Sub-
    Process it is applied to. If the Sub-Process is a Transaction, the Transaction is rolled back."

    The standard, however, is a little bit vague about what actually triggers cancellation.
    Here are just a few examples of scenarios in whose descriptions the standard applies the term "cancel":

    • Throwing Cancel Event
    • 'cancelRemainingInstances' attribute of Ad-Hoc Sub-Processes
    • 'completionCondition' attribute of Multi-Instance Activities
    • 'condition' attribute of ComplexBehaviorDefinitions
    • 'isInterrupting' attribute of Start Events in Event Sub-Processes
    • 'cancelActivity' attribute of boundary events

    Do all these scenarios trigger a cancellation in the sense of the above mentioned statement?
    This should be explained more precisely in the standard.

    Furthermore, on page 301, there is this statement:
    "Cancellation in turn can result in compensation of already successfully completed
    portions of an active Activity, in case of a Sub-Process."

    Why does the statement use "can result" instead of e.g. "always results"?
    The standard should describe precisely under which circumstances cancellation results in compensation, and the circumstances under which cancellation does not result in compensation.

  • Reported: BPMN 2.0.2 — Thu, 5 Oct 2017 12:47 GMT
  • Updated: Wed, 18 Oct 2017 05:55 GMT

Intermediate Compensation Events can have outgoing Sequence Flows

  • Key: BPMN21-402
  • Status: open  
  • Source: omninet.de ( Frank Munkert)
  • Summary:

    In chapter 10.5.4 "Intermediate Event", on page 258, there is the following sentence:
    "An exception to this: an Intermediate Event with a Compensation trigger MUST NOT have an outgoing Sequence Flow (it MAY have an outgoing Association)."

    This statement seems to be wrong. For example, figure 10.32 on page 176 shows several throwing Intermediate Events with outgoing sequence flows.

  • Reported: BPMN 2.0.2 — Wed, 4 Oct 2017 08:45 GMT
  • Updated: Wed, 4 Oct 2017 20:13 GMT

Execution semantics of Activity with conditional outgoing Sequence Flows

  • Key: BPMN12-35
  • Status: open  
  • Source: Munkert Software Consulting ( Frank Munkert)
  • Summary:

    In chapter "13.3.2 Activity", on page 429, there is the following bullet point:

    "* After all completion dependencies have been fulfilled, the state of the Activity changes to Completed. The outgoing
    Sequence Flows becomes active and a number of tokens, indicated by the attribute CompletionQuantity, is
    placed on it. If there is more than one outbound Sequence Flows for an Activity, it behaves like an implicit
    Parallel Gateway."

    The last cited sentence does not take into consideration that the outgoing sequence flows might have conditions. Therefore, the statement "behaves like an implicit Parallel Gateway" is not entirely correct.

    Suggestion for a revised version of the last sentence:
    If there is more than one outbound Sequence Flows for an Activity, and if all outbound sequence flows are unconditional, the Activity behaves like an implicit Parallel Gateway. If there conditional outgoing sequence flows, the behavior is as described in "13.3.1 Sequence Flow Considerations".

  • Reported: BPMN 2.0.2 — Mon, 29 May 2017 08:38 GMT
  • Updated: Tue, 27 Jun 2017 15:16 GMT

p.172 Reference pointing to wrong figure, p.174/175 Event marker missing in figure

  • Key: BPMN21-400
  • Status: open  
  • Source: Combitech Systems AB ( Hakan Davidsson)
  • Summary:

    p.172: "... Sub-Process marker, seen in Figure 10.24 ..." Should be Figure 10.25

    p.174/175: p.174, "... its Start Event will be used as a marker in the upper left corner of the shape (see Figure 10.30)." There is no marker in Figure 10.30 (I suppose it should be the Message Event from Figure 10.31).

  • Reported: BPMN 2.0.2 — Thu, 3 Nov 2016 11:35 GMT
  • Updated: Fri, 4 Nov 2016 20:55 GMT

Inconsistent default value of dataStore/@isUnlimited

  • Key: BPMN21-399
  • Status: open  
  • Source: Camunda Services GmbH ( Falko Menge)
  • Summary:

    Table 10.55 (Data Store attributes) defines the default value of isUnlimited as false whereas the XML Schema says:

    <xsd:attribute name="isUnlimited" type="xsd:boolean" default="true"/>
    

    Proposal:
    In Table 10.55 (Data Store attributes) on page 208 (PDF 238) replace:
    > isUnlimited: boolean = false
    with:
    > isUnlimited: boolean = false

  • Reported: BPMN 2.0.2 — Tue, 13 Sep 2016 17:55 GMT
  • Updated: Tue, 27 Sep 2016 20:16 GMT

Clarification needed regarding converging exclusive gateway and slash marker

  • Key: BPMN21-398
  • Status: open  
  • Source: Munkert Software Consulting ( Frank Munkert)
  • Summary:

    On page 290, in section "10.6.2 Exclusive Gateway", there is the following text:
    "A converging Exclusive Gateway is used to merge alternative paths. Each incoming Sequence Flow token is routed
    to the outgoing Sequence Flow without synchronization."

    On page 435, in section "13.4.2 Exclusive Gateway (Exclusive Decision (data-based) and Exclusive Merge)", there is the following text in the table:
    "Exception Issues - The exclusive gateway throws an exception in case all conditions evaluate to false and a default flow has not been specified."

    I.e. according to the table, in order not to throw an exception, a converging exclusive gateway would need to have a default flow marker on its single outgoing sequence flow. This seems to be a contradiction to the description in section 10.6.2. Therefore, this should be clarified in both sections, e.g. using a sentence like this: "The single outgoing sequence flow of a merging exclusive gateway is implicitly assumed to be the default sequence flow. A slash marker MAY be shown in diagrams for such sequence flows."

    Without such a clarification, BPMN process diagrams where an outgoing sequence flow of a converging exclusive gateway has no slash marker would be wrong. Since those diagrams are very common (e.g. OMG's "BPMN 2.0 by Example", v1.0, page 36), it should be explicitly mentioned that omitting the slash marker is allowed.

  • Reported: BPMN 2.0.2 — Tue, 16 Aug 2016 06:35 GMT
  • Updated: Fri, 19 Aug 2016 13:25 GMT

Task Description -- Internal Conflict

  • Key: BPMN21-397
  • Status: open  
  • Source: US Army ( Michael Gilsdorf)
  • Summary:

    Sect 10.3.3 states, "A Task is used when the work in the Process cannot be broken down to a finer level of detail."

    However, the task definition in the glossary states, "A Task is used when the work in the Process is not broken down to a finer level of Process Model detail."

    The phrase, "cannot be broken down" is much different than the phrase, " is not broken down". The latter suggests that an activity could be broken down further, but was not.

    The glossary definition is correct since a task can often be broken down into tiny actions (e.g., Click the left mouse button), but a person modeling the process may choose not to model to that low a level. Thus, a task is the lowest level shown on a diagram, but may not necessarily be the lowest possible level.

    Recommend that the sentence in Sect 10.3.3 be changed to be consistent with the one in the glossary. As an option, you also may wish to make that statement, "Any conflicts between the glossary and other parts of the specification, the glossary takes precedence."

  • Reported: BPMN 2.0.2 — Sat, 6 Aug 2016 18:49 GMT
  • Updated: Wed, 10 Aug 2016 14:06 GMT

data storage element is missing in overview

  • Key: BPMN21-394
  • Status: open  
  • Source: Diartis AG ( Daniel Canonica)
  • Summary:

    In the overview 'Basic BPMN Modeling Elements', table 7.1, the data storage element (hard disk Symbol) is missing. (Refer to section 10.4.1, Figure 10.54).

  • Reported: BPMN 2.0.2 — Wed, 13 Apr 2016 13:13 GMT
  • Updated: Wed, 13 Apr 2016 15:36 GMT

Confusion over dataOutput attributes

  • Key: BPMN21-393
  • Status: open  
  • Source: Cognitect ( David Chelimsky)
  • Summary:

    Table 10.60, which describes the attributes of DataOutput objects, describes "outputSetwithOptional" with "Each OutputSet that uses this DataOutput can determine if the Activity can complete executing without producing this DataInput. This attribute lists those OutputSets." I believe that "DataInput" should be replaced with "DataOutput".

    Similarly, the same table describes the "outputSetWithWhileExecuting" attribute with "Each OutputSet that uses this DataInput can determine if the Activity can produce this DataOutput while executing. This attribute lists those OutputSets." Same correction applies.

  • Reported: BPMN 2.0.2 — Mon, 29 Feb 2016 21:57 GMT
  • Updated: Wed, 2 Mar 2016 07:12 GMT

Wrong table reference number

  • Key: BPMN21-389
  • Legacy Issue Number: 19766
  • Status: open  
  • Source: ERP Bulgaria Ltd. ( Ivan Argentinski)
  • Summary:

    There are actually 2 errors (wrong Table numbers) in the last 2 sentences on the page:

    "The DataObject element inherits the attributes and model associations of FlowElement (see Table 8.44) and
    ItemAwareElement (Table 10.52). Table 10.54 presents the additional attributes of the DataObject element."

    The correct Table numbers should be:

    • ItemAwareElement (Table 10.51)
    • DataObject (Table 10.52)
  • Reported: BPMN 2.0.2 — Sun, 31 May 2015 04:00 GMT
  • Updated: Mon, 22 Jun 2015 06:12 GMT

Missing event marker in Figure 10.30

  • Key: BPMN21-369
  • Legacy Issue Number: 19473
  • Status: open  
  • Source: omninet.de ( Frank Munkert)
  • Summary:

    The specification says: "If the Event Sub-Process is collapsed, then its Start Event will be used as a marker in the upper left
    corner of the shape (see Figure 10.30)."

    But the referenced figure does not show any marker event. Therefore, either the text or the figure is wrong.

  • Reported: BPMN 2.0.2 — Mon, 16 Jun 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 10.3.4 Human Performer is not peorperly defined for implementation interpretation

  • Key: BPMN21-366
  • Legacy Issue Number: 19461
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    It is not specifically stated in the spec whether "HumaPerformer" is an abstract class.
    It seems to be, but then the meta model (fig 10.23) depicts only one specialization namely "PotentialOwner" leaving in question the need for this abstraction.
    Furthermore "PotentialOwner" only

  • Reported: BPMN 2.0.2 — Wed, 11 Jun 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Second occurance of sequential Multi-Instances should be parallel

  • Key: BPMN21-374
  • Legacy Issue Number: 19709
  • Status: open  
  • Source: Anonymous
  • Summary:

    In Table 7.2 the text for Multiple Instances says the three vertical lines mean sequential MI. I believe it nust be parallel, three horizontal lines mean sequential.

  • Reported: BPMN 2.0.2 — Wed, 14 Jan 2015 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Use of per mille symbol unclear (‰)

  • Key: BPMN21-373
  • Legacy Issue Number: 19708
  • Status: open  
  • Source: Anonymous
  • Summary:

    In table 7.3 the per mille (‰) sign is used in the third column. I suspect the arrow was meant.

  • Reported: BPMN 2.0.2 — Wed, 14 Jan 2015 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT