Issue 9115: BPMN comment: additional artifacts
Issue 9116: Sec. 6.16
Issue 9318: Attributes not explained with respect to Notation
Issue 9328: Sequence Flow is not a Flow Object
Issue 9329: Unclear what complete syntax is for an Attribute
Issue 9342: Semantical difference between activity models and BPMN
Issue 9355: Which is it, Core Elements, or Flow Objects?.
Issue 9357: Need consistent terminology for Categories, Core Elements
Issue 9363: shared collaboration
Issue 9364: differentiate a business message from a business signal
Issue 9376: fundamental semantic model of token flows
Issue 9410: Update definition of merging behavior of Exclusive Data-Based Gateway
Issue 9558: BPEL mapping definition is imprecise
Issue 9561: Message Flow ordering along Pool (abst process) is modeled only graphically
Issue 9563: Message/Property/Assignment relations are too complex
Issue 9565: Reference Task does not define any way to pass parameters and values
Issue 9566: BPEL/WSDL specific properties
Issue 9567: BPEL->BPMN mapping problem correlation set
Issue 9568: correlation set
Issue 9569: partner links are not modeled in BPMN explicitly.
Issue 9570: BPMN spec doesn't include join condition
Issue 9571: BPEL faults
Issue 9572: enhance BPMN to provide 'resource modeling'.
Issue 9573: Specify persistent format
Issue 9615: BPMN Issue: Exclusive Gateway Merging
Issue 9917: Multiple Triggers with 'and' semantics
Issue 9925: BPMN: Complex triggers
Issue 10084: Extending activities with execution time (traversal time) attributes?
Issue 10096: Inclusive Event-Based Decision
Issue 10139: Message flows in and out of independent sub-processes
Issue 10150: Implicit State Machine for Activities
Issue 10152: Is it valid to have a pool nested within a Lane,
Issue 10339: Do artifact flows affect execution
Issue 10341: Where are tokens queued?
Issue 10372: The Reference Task and Reference Subprocess should be removed
Issue 10375: Section: 10.1.3
Issue 10384: no way to graphically differentiate an Embedded Subprocess
Issue 10518: Move Sequence Flow Conditions to Gates
Issue 10527: Add Project Management dependencies for activities (FF, FS, SF, SS)
Issue 10932: Section: 9.3.4 Intermediate [Events]
Issue 10933: Section: 10:2.1 Normal Flow
Issue 11150: Page: Page 1 (PDF page 25)
Issue 11151: Page 19 (PDF page 43) Table 8.2, definitionof "Pool".
Issue 11241: confusion regarding diagram 10.25
Issue 11277: BPMN does not explicitly identify a model element for "approval."
Issue 11278: BPMN does not have a symbol for a physical storage facility
Issue 11634: Section: 9.4, 9.4.1, 9.4.2
Issue 12243: Why in paragraph 7.1.1 Uses of BPMN, definition of Collaboration (Global)
Issue 9115: BPMN comment: additional artifacts (bpmn-ftf)
Click here for this issue's archive.
Source: National TeleConsultants (Dr. Ugo Corda, ugo.corda@ntc.com)
Nature: Uncategorized Issue
Severity:
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.
Discussion: While the Issue is valid, it represents a part of a larger issue reviewing and repairing a lot BPEL mapping issues. Thus, this Issue will be deferred and handled by a later version of BPMN. The work could be done as part of the BPDM RFP or as part of a new RFP or RTF. Thus, the Issue will be deferred, but a minor text revision will be included in the specification Revised Text: Section 11 (this section will probably be moved to an appendix), page 137, append the paragraph in that section: "Note that there are known issues with the mapping as specified. Fixes to these issues will be incorporated in a later revision of the specification." Disposition: Deferred
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).
Discussion: While the Issue is valid, it represents a part of a larger issue reviewing and repairing a lot BPEL mapping issues. Thus, this Issue will be deferred and handled by a later version of BPMN. The work could be done as part of the BPDM RFP or as part of a new RFP or RTF. Disposition: Deferred
Most elements have a section called 'attributes' - but nowhere is it explained how these are related to the Notation being specified. Is it expected that each shape will have a 'property sheet' allowing these attributes to be viewed and edited? The end of Section 7.1.1 states "Thus, the graphic elements of BPMN will be supported by attributes that will supply the additional information required". In many cases though the attributes described include information that is redundant with the diagrammatic representation e.g. Name (in several places including 9.6.1) and ParentPool and ParentLane for Lane in section 9.6.3. In general Appendix B has more of the flavor of a metamodel or an interchange definition than a Notation.
Defer: The OMG roadmap for BPMN and BPDM indicates that the two specifications will be consolidated for a BPMN/BPDM 2.0. When this occurs all issues regarding notation vs. metamodel will no longer be problematic. Since this issue involves a discussion of the notational aspects vs. an underlying metamodel for BPMN, we can defer this issue to version 2.0.
It seems a bit odd that a Sequence Flow is not a Flow Object as its name would appear otherwise: actually the term Flow Object is probably the one that misleads
Discussion: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN. Disposition: Deferred
6.1.1 should show the complete syntax for an attribute e.g. as BNF.
Discussion: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN. Disposition: Deferred
I do not see what exactly is the semantical difference between activity models and BPMN, besides its syntactic constituents. Secondly, BPMN does not address the objects or nouns which activitiy diagrams do. Process with objects provide complete meaning, process without objects is typeless and thus meaningless.
Discussion: The FTF agrees that there is a problem that needs fixing or addressing (Activity Diagrams and BPMN), but could not agree on a resolution and deferred its resolution to future work on BPMN. Disposition: Deferred
Note: This issue is vaguely related to 9321 See section 8.1 "BPD Core Element Set" starting on page 15 of 06-01-01 The text presentation is organized according to four "basic categories" and gives the impresion that some semantic or syntactic commonality underlies each of the four categories. The category Flow Objects are listed on page 15 as bullet items. . but the table 8.1 repeats the same list, but now calling them "Core Modelng Elements", and the category "Flow Objects" has been forgotten. This is confusing. It is additionally confusing to have separate lists of "Core Modeling Elements", "Core
While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN. Disposition: Deferred
Issue summary: Need consistent terminology for Categories, Core Elements aka Graphical Objects Details: Note: This issue is related to the one above ???3 under the summary: Which is it, Core Elements, or Flow Objects?. The text presentation on page 15 of 06-01-01 (section 8.1) introduces four "basic categories" of Core Modeling Elements. compare that with Section 9.1, the text preceding Table 9.1, which reads in part >>>> "BPMN graphical objects (Flow Objects, Swimlanes, Artifacts and Connecting Objects)" These same four were earlier said to be the basic Categories aka the Core Modeling Elements. Now they are said to be the four "graphical objects". It seems likely that authors of different parts of the text were agreed that this list of four was speciallly important, but that they did not use the same terminology for them. They should consistently be termed "categories", "core elements" or "the BPMN Graphical Objects", but not a mix of all 3 terminologies. Since these four categories turn up in so many contexts, they invite close study, and their seemng importance -- at least in the view of the authors of the spec -- suggests that the metamodel of the BPMN domain should recognize them as important metaclasses. If this implication is not intended, then the text should get rid of these "categories".
Discussion: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN. Disposition: Deferred
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).
Discussion: The FTF agrees that there is a problem that needs fixing or addressing, but considers the resolution to be too complex for a FTF and defers its resolution to future work on BPMN. Disposition: Deferred
Comment to BPMN FTF: * Currently there is no standard way to differentiate a business message from a business signal, which have fundamental different characteristics. ======== During the ebBP-BPMN discussions last week, I was asked to summarize what business signals are and how they function. There has been some initial discussion on the bpmn@omg.org list re: signals in general. I'd like to make a necessary distinction about the similarities and differences. * What is a business signal? [1] o "Business signals have a specific business purpose and are separate from lower protocol and transport signals. One or more Business Signals can be exchanged as part of a Business Transaction to ensure state alignment between both parties. Evaluation of business signals enable the state of a Business Collaboration to be explicitly calculated at run time. The ebBP technical specification provides both the structure and choreography of Business Signals, including allowing for user defined signals.... A Business Signal is computable. This provides the collaborating parties with a mutual understanding of the business activity. This function allows the parties to know if their expectations in a Business Transaction are realized. This is state alignment, and is important in order for the ebBP specification to have commercial viability. The ebBP specification provides the ability to conduct intended transactions if that is the intent of the collaborating parties." * Where does the business signal fit in eBusiness and business messaging? [2] o State alignment: (almost quoting from our specification for specifics) The process of exchanging signals and state changes of a Business Transaction enables state alignment between the parties involved. If the standard signals are used, the structures of ebXML Business Signals are ‘universal’ and do not vary from transaction to transaction. Business signal schema can be found at: http://www.oasis-open.org/committees/document.php?document_id=16460&wg_abbrev=ebxml-bp (detailed schema documentation also exists on this public page). The ebBP technical specification provides both the structure and choreography of Business Signals. The ebXML Message Service Specification (and other evolving technologies) provides a reliable messaging infrastructure. This is the basis upon which the ebBP technical specification builds its protocol for business state alignment using Business Signals. The Business Signal payload structures are optional and normative and are intended to provide business semantics to the Business Signals. o Part of process definition: Defined in the BT pattern and bounded by partner expectations. Map back to business transaction activity. Map back to service and action context for agreement (such as CPP/A). o Transition and determination of several types of successes and failures: Condition guards exist on transition in process steps and activities. Business signals are integral here. In ebBP and in business collaboration, there is protocol and business success whereby one supports the other. Reference: http://www.oasis-open.org/committees/document.php?document_id=16457&wg_abbrev=ebxml-bp (See Section 3.6.3) * What happens if you don't model these signals? o In configuration: Business and messaging signals are explicitly modeled in configuration. o In understanding the partner agreement: The partners may mutually expect these be used and therefore set criteria associated with the progress and outcomes of the business process (and its activities). o In managing state transitions: See previous comment. o In seeking to generate computable artifacts: Without the definition of such signals, the artifacts either have to be defined out of band or in a potentially proprietary way. We allow user-defined signals, although they are still related, included and part of the business process. * Links to the business process [3] o Standard signals: Defined structure and semantics related to the pattern, activity and transitions o User defined signals: Allowed pointers to user-defined structure o BT patterns + Template: See patterns matrices in the specification (sections 3.4.9 and 3.4.9.1) that specify how these signals infer content validation, succesful syntactic validation and also allow the business process to proceed (or not). + Profile: Partners identify their expectations using the patterns and the selectable criteria to support not only the business messages received but the business signals that support them. o Relevance to model + Business Transactions and the Business Service View [4. See Chapter 9]. + Business significance # Involves timing parameters, implication to business partner expectations, etc. Several important criteria are defined around the use of the business signals. [4. See Chapter 8. State notations and their relevance to partner expectations are found in Chapter 9.] You can see how signals are used in the process definitions found on our public web site at: (ePV, Netherlands example) http://www.oasis-open.org/committees/document.php?document_id=16436&wg_abbrev=ebxml-bp Facts * Properties such as line width or color could be used but can't be seen if printed on black and white. * Properties such as message and (add) signal could be used. The latter would have to be added. There would also possibly need to be a way to differentiate whether or not business signals were used as the implementation and runtime results may differ given that assumption (different semantics). * In order to maintain the focus of generation of software artifacts, business signals should be considered for modeling in a standard way (preferred to a tool specific option). Additional note: We have seen tools that actually use the properties of messages to delineate a signal (such as a stereotype). * Business signals differ from underlying messaging infrastructure acknowledgements. Several communities including UK Bristol government and ePV have indicated the value of the use of business signals. Supports monitoring framework as well. Business example Two partners agree to engage in a Commercial Transaction pattern and use the BT from the pattern. A BTA is developed in a Business Collaboration to support these expectations. The partners will use reliable messaging and they use the business signals. An intelligibility (syntactic) check is made on the business message before the Receipt Acknowledgement business signal is sent, and successful business processing is required on the business document before an Acceptance Acknowledgement business signal is generated. Both carry timing expectations with them (in support of the BTA). For example, an Order Management system would validate a business document meets the partner expectations before initiating a sales order and sending a Response from a Purchase Order Request. Prior to the Response being sent these signals are used. They also allow the partners to optimize where required. The Buyer (Requesting Role) can understand that the Request was received and then whether or not it was successfully business processed (i.e. alleviating the potential need to query another Seller). Let's assume the Purchase Order doesn't muster in validation processing, then a Negative Acceptance Acknowledgement is sent. The Buyer (Requesting Role) may have an early indication and then can send a Cancel Transaction. Both parties are able to react more quickly to current conditions. In addition the business signals give clear indication of state alignment (the parties have a shared understanding of their condition and state of the business expectations). Example business signals found at: http://www.oasis-open.org/committees/download.php/16652/ebxmlbp-v2.0.2-cd-ExampleSignals.txt [1] From our FAQ found at: http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/download.php/16540/ebBPv2.FAQ.html [2] Not transport level or HTTP acknowledgements. [3] Business signals defined in Section 3.4.9.3 at: http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/ (in technical specification) [4] This reference was provided on the public bpmn@omg list late last week - N090 UNCEFACT Modeling Methodolgy R10 [1]. The business signals occur in the Business Service View (which is different than a transport level component), see: http://www.ifs.univie.ac.at/untmg/ (UMM_N090R10_2001-11_01.zip) - See chapters 8-9.
Currently there is no description of the fundamental semantic model of token flows in the spec. Clearly it is based on a variety of petri net; however a description of the particular semantics assumed in BPMN could be very useful in reading the spec. Such a description should be formal in the sense that it should be mathematically clear what the procedural semantics of BPMN is
Discussion: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN. Disposition: Deferred
Update the definition of the merging behavior of the Exclusive Data-Based Gateway. Currently, the Gateway just passes all Tokens through. The behavior should be changed to be exclusive in that it will allow the first Token to arrive through the Gateway, but ignore/consume all other Tokens from the same Token family.
Discussion:
This issue will be resolved during the next BPMN FTF.
Disposition: Deferred Defer: The potential complications of resolving this issue, particularly surrounding the formal
definition of Token flow, requires that this issue be deferred so that it can be handled in a
better way in BPMN 2.0. However, a couple of modifications to the specification are required to
correct an error in how the Exclusive Data-Based Gateway was applied in an example.
Revised Text:
Section 10.2 "Sequence Flow Mechanisms," page 119:
a) Second paragraph on the page: replace paragraph with the following paragraph:
"Another merging situation is the Workflow Pattern Discriminator. In this situation, the
multiple incoming Sequence Flow are parallel instead of alternative (see Figure 10.32).
Thus, there will be two Tokens arriving (at different times) at the Complex Gateway
preceding activity “D.” To satisfy the Discriminator pattern, the Complex Gateway must
accept the first Token and immediately pass it on through to the activity. When the second
Token arrives, it will be excluded from the remainder of the flow. This means that the Token
will not be passed on to the activity, but will be consumed." (Note: there is a footnote
included with the "Workflow Pattern Discriminator." text)
b) Figure 10.33 ("Workflow Pattern #8 -- Discriminator"): Replace figure with the following
Figure:
Disposition:BPEL mapping section suggests mapping of flow graph to structural BPEL construct which calls for the complex flow analysis (e.g. to define bounds of the switch construct). With this complexity, BPEL mapping definition is imprecise. Some constructs, like exception handling, don't map to BPEL constructs suggested by the spec due to the difference in behavior. I would suggest to redefine mapping using approach described in article "An Example of Using BPMN to Model a BPEL Process" http://www.bpmn.org/Documents/Mapping%20BPMN%20to%20BPEL%20Example.pdf
Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN.
Message Flow ordering along Pool (abstract process) is modeled only graphically. A specification of in/out indices to message flows is a solution. Otherwise it's impossible to tell from the model order of message receive/send for certain pool
Discussion: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN. Disposition: Deferred
Message/Property/Assignment relations are too complex. It's not easy to model values sent along the message flow. Probably Message loaded with Assignments would help. Also. there is no easy way to model BPEL construct where full message is assigned to variable. It looks like there is duplication between Property set and Message. It's not clear whether it's possible to use Property Set or Message definition as Property type. Probably BPMN needs better type modeling.
Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN.
Reference Task does not define any way to pass parameters and values
Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN.
Borland found we had to add some BPEL/WSDL specific properties like 'target namespace' and 'wsdl path' to Participant for BPEL generation
Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN.
variables having 'message' type are imported as property sets,
reference to message type is lost
- it is hard to model variable as input and assign result of
<invoke> to variable. If passing arguments can be modeled as sequence of
assignments, receive part is impossible to model clearly--assignment is
not symmetric, from is expected to be an expression and there is no way
to define reference to service call result in expression as BPEL don't
need it
Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN.
BPEL model may use correlation set as a way to establish 'session' BPMN does not have similar construct. One could model a reference to correlation set in invoke as set of assignments. There should be a way to mark such set of assignments with a boolean "initiate" flag
Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN.
partner links are not modeled in BPMN explicitly. so some of related features are impossible to represent (e.g. dynamic partner links)
Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN.
each action may contain join condition and have associated 'suppressJoinFailure' flag. BPMN spec doesn't include join condition at all and puts suppressJoinFailure to the Process level only. Borland created complex structures to reflect behavior of related BPEL elements to enable generation.
Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN.
BPEL faults are more complex than simple error name and handler may be selected basing on fault name and type of the related data. BPMN supports only error handler selection by name. A way of specifying the faults at sufficient detail to enable generation of BPEL faults is needed, by means of some text annotation property perhaps.
Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN.
It would be nice to enhance BPMN to provide 'resource modeling'. For example, a way to model working time available to the process, for participant. Maybe a clear way to define resources used by activities, number of available resource items, competition for resources.
A persistent format (XMI?) should be specified, to create possibility of vendor-independent models
Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN.
The BPMN 1.0 version of the Exclusive Gateway merging (either data or event Gateways) acts as a "pass through" for any Tokens that arrive. This means that there is no "exclusiveness" to the merging as the name of the Gateway would imply. A "discriminator" merging that allows the first Token through and stops any further (parallel) Tokens is a business pattern that cannot be currently modeled. This functionality should either replace the current merging behavior or be added to the behavior.
In BPMN 1.0, you can create an Event with Multiple triggers. But these triggers are treated as alternatives ... i.e., they have 'or' semantics. It is very common to require multiple triggers with 'and' semantics. That is, all of the triggers must be satisfied before the process will start. A possible graphical notation is to to use the '+' symbol inside of the event circle. This would then be consistent with the notation used to designate 'and' semantics in gateways.
Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN.
It's common to have models with complex triggering conditions. For example, start this process upon arrival of Message A and Message B or arrival of Message A and Message C. A new trigger type, "Complex", would facilitate creation of such models. The trigger would be represented as an Expression in this case. A possible graphical notation would be to apply the same icon that is used in Complex Gateways.
Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN.
Is there a plan for extending activities with execution time (traversal time) attribute??? I mean is to put time on the activities which show how long they will take to finish. Maybe two attributes for the best and worst case (minimum and maximum traversal time). I can imagine a system, which allows displaying accumulated time for every sub process and task, for every separate flow path with minimum and maximum traversal time. It is more or less easy to find out estimated time for primitive tasks but it is really hard work to calculate possible execution time for whole process for synchronization purposes. So when you simulate the whole process at the end you will see how long the process will take in best and worst case. It is an excellent feature for process estimation. I realize the problems of implementing of such functionality because of merging of sequence flows but anyway it could be great feature. Unfortunately process execution time (traversal time) is still not supported by BPMN specification but you don’t need to be an oracle to predict that the idea will come through in the closest future.
Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN.
We may need a way to model more general logic patterns for incoming events. For example, in response to an RFQ, a supplier may send either a decline, or a quote and (as a separate message) terms & conditions. The logic pattern for this use case is
Decline XOR ( Quote AND Terms )
If the Decline is accompanied by a memo giving reasons, then the logic becomes
( Decline AND Memo ) XOR ( Quote AND Terms )
We want to open up three event receivers initially (four in the second case). Then, as a Quote arrives for example, we want to close the receives for Decline and Memo --- since we don't expect those any longer --- but keep the receive for Terms & Conditions open. When those have arrived as well, the inclusive event-based gateway is complete.
Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN.
Where an activity represents an invocation of an independent subprocess, the spec does not state how to bin any incoming and outgoing message flows to the sub-process. It does state how to bind information (input and output sets) but not messages.
Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN. Any changes made for this version may potentially conflict with later modifications.
What are the states that an activity can transition to? Are these the values of the Status attribute of an Activity? (None, Ready, Active, Cancelled, Aborting, Aborted, Completing, Completed) What, if anything, causes a transition of an Activity from None to Ready? Can you transition from Completed to None? to Ready? And so forth. In what ways can these transitions occur? I think this is mainly a matter of what effects events have, but also involves the flows (and gateways, and tokens) [See the summary of start event types and their triggers (Table 9.5) and end events and process “endings” (Table 9.6) that has some info on effects on state, though some additional values appear to be mentioned.] If there are other states (“armed” “ready”, “listening”, “waiting” “dormant”, “inactive” and so on) list them along with basic ones such as “started” (“instantiated” “activated”) and completed. Are some states synonymous? Which ones? Is singly/multiply instantiated a state (so that an instantiated count could be tracked by numbers of copies active in the system?) How would the above states, if they exist, be related to the value in LoopType, StartQuantity, etc. Bonus: Link the state machine transistions to the token flow behaviors and when and how Activities after a Merge GW change state. How is a Start or Intermediate Event state with a None trigger different from a transfer of flow control by means of a token? There are connections between state transitions and “flow” as stated, for example, in the ConditionType Attribute where token flow is said to occur when the (source) Activity State goes to Completed. Are there rules relating the generation or consumption of tokens to the state transitions?
Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN.
Is it valid to have a pool nested within a Lane,
Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN.
Do artifact flows affect execution? Table 8.2 (BPD Core Element) says: Data Objects are considered Artifacts because they do not have any direct effect on the Sequence Flow or Message Flow of the Process, but they do provide information about what activities require to be performed and/or what they produce. Not sure, but the above seems to imply that artifact flows do not affect execution (it does not affect sequencing or messaging). Compare Table 9.10 (Common Activity Attributes): [Input: for InputSets only] Inputs (1-n) : Artifact One or more Inputs MUST be defined for each InputSet. An Input is an Artifact, usually a Document Object. InputSets (0-n) : Input The InputSets attribute defines the data requirements for input to the activity. Zero or more InputSets MAY be defined. uEach InputSet is sufficient to allow the activity to be performed (if it has first been instantiated by the appropriate signal arriving from an incoming Sequence Flow). which seems to imply an execution semantics ("Each InputSet is sufficient to allow the activity to be performed").
Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN.
In the following process, assume mulitple tokens are being fed to A
from upstream (<X> = exclusive OR split, <+> = AND Join):
|------|
----> A -- <X> <+> --> B
|------|
I assume two executions of A are required for each execution of B (if
not, correct the parts of the spec that imply this).
Where are tokens queued up that don't have a matching one to get
through the AND join? BPMN should indicate where the queuing happens,
because it affects execution. If queuing is at the the exclusive-OR
split, then conditions could change over time and the guard could
direct the token to a different path after the token as been queued a
while. Or token could queue at the join, and only be tested by the
guards once.Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN.
“The Reference Task and Reference Subprocess should be removed. With the resolution of issue 9559, containment issues no longer restrict the vendor from making any BPMN object reusable/referenced.”
After reading the following on BPMN - BPMN OMG Final Adopted Specification of March 6 2006, - Introduction to BPMN by Stephen A.WHite, IBM Corporation. In the latter paper are the following statements: "Pools are used to represent Participants in the process" "Message flow is defined as the mechansism to show the communication between two participants" "Lanes are often used to separate the activities associated with a company function or role" With the above three statements, I am having difficulty understanding the rationale for the below statement about BPMN "Sequence Flow may cross the boundaries of Lanes within a Pool, but Message Flow may not be used between FLow objects in Lanes of the same Pool". To model the process of how a Customer project is executed by a company, I want to model Organisation Units (e.g. Sales, Development) as Pools and roles inside those Units as Lanes (e.g. Project Manager, Team Leader, Architect, Developer etc), Message Flows can be used to represent the interactions between Sales and Development Units. But I am not allowed to use Message Flows to represent the interactions between an Architect and the Developer. WHy? Am I using the pools and lanes in a manner that is against the philosophy of BPMN? I tried to get an answer from BPMN OMG Final Adopted Specification of March 6 2006, but the rationale was not very clear. Please could I have a clarification for the rationale between not allowing message flows between lanes in the same pool.
Defer: The modification suggested by this issue is out of scope for the FTF. This will be handled through other OMG mechanisms, such as an RFP for the next version of BPMN.
There is currently no way to graphically differentiate an Embedded Subprocess vs. an Independent Subprocesses. Suggested resolution is to use the "go to" arrow instead of a "+" (plus sign) for the Independent Subproces, similar to the off-page connector. This would indicate that the Independent Subprocess "goes to" another diagram.
Deferred: While the Issue may be valid, it represents a challenge that could not be solved during the time frame of the Finalization Task Force. Thus, this Issue will be deferred and handled by work on a later version of BPMN.
Right now flow conditionality is maintained in the Sequence Flow. This should be moved to the Gates and then the Sequence Flow become purely a mechanism to advance the flow (Token).
Defer: The changes to the specification are too extensive to be handled by the FTF. They will be handled in the next version of BPMN.
Project management models define the start/finish relationships between activities. This is handled in four ways: Finish-Finish; Finish-Start; Start-Finish; and Start-Start. Current BPMN Flow handles two of the four. A sequential flow of activities is a Finish-Start; a parallel set of activities is a Start-Start. But the other two combinations are not definable. The solution may not require graphical canges to BPMN, but there should be some behavioral support for these situations.
Defer: The modification suggested by this issue is out of scope for the FTF. This will be handled through other OMG mechanisms, such as an RFP for the next version of BPMN.
All the next five numbered points are BPMN Specification descriptions for Cancel Intermediate Event possible uses. TO SUMMARIZE EXECUTIVELY , text in the table 46 states that Cancel Intermediate MUST NOT be used when the Event is attached to the boundary of a Transaction WHILE text on pages 45, 47 and 60 and figure on page 60 indicate that Cancel Intermediate Event can be ONLY USED attached to the boundary of Sub-Process. I BELIEVE this is CRITICAL issue, because it establishes the completely opposite views and can possibly lead for example to rejection of valid BPMN diagram. 1) Text in chapter 9.3.4 Intermediate [Events] in table 9.9 on page 46 in the first row "Trigger" [attribute] in column Description states that "The Cancel Trigger MUST NOT be used when the Event is attached to the boundary of a Transaction or if the Event is not contained within a Process that is a Transaction." THE CORRECT SENTENCE should be "The Cancel Trigger MAY only be used when Event is attached to the boundary of a Sub-Process that is a Transaction." Read on... 2) At the same time, in chapter 9.4.3 Intermediate [Events] in Table 9.8 on page 45 is stated for Cancel Intermediate Event that "This type of Intermediate Event is used within a Transaction Sub-Process. This type of Event MUST be attached to the boundary of a Sub-Process. It SHALL be triggered if a Cancel End Event is reached within the Transaction Sub-Process. It also SHALL be triggered if a Transaction Protocol “Cancel” message has been received while the Transaction is being performed." 3) Text in the same chapter right below the table 9.9 in section "Activity Boundary Connections" on page 47 says, that "An Intermediate Event with a Cancel Trigger MAY be attached to a Sub-Process boundary only if the Transaction attribute of the Sub-Process is set to TRUE." 4) Except that, also in chapter 9.4.2 Sub-process in section "Sub-Process Behavior as a Transaction" on page 60 the indicates that "A Cancel Intermediate Event, attached to the boundary of the activity, will direct the flow after the Transaction has been rolled back and all compensation has been completed. The Cancel Intermediate Event can only be used when attached to the boundary of a Transaction activity. It cannot be used in any Normal Flow and cannot be attached to a non-Transaction activity." 5) Also the figure 9.11 on page 60 shows Cancel Intermediate Event attached to the boundary of Transaction Sub-Process.
Section - Forking Flow, page 111 - there is a typo: "Even when not required as a “best practice,” there are situations were the Parallel Gateway provides a useful indicator of the behavior of the Process." ... The sentence should state: "... are situations WHERE [capitalization added] the ..."
Page 1 (PDF page 25) Section 1 includes the text: "Note – This version does provide a non-normative mapping from BPMN to WSBPEL, but the BPMN specification itself is known to be incomplete with respect to capturing all the required information for WSBPEL. So the mapping is insufficient, in any case." This says one can't make a mapping from WSBPEL to BPMN. It doesn't prevent a mapping from BPMN to WSBPEL.
Page 19 (PDF page 43) Table 8.2, definitionof "Pool". Should lanes within pools be referred to as "Lanes" or "Swimlane"? Both terms are used. It would be good to be consistent.
There is a confusion regarding diagram 10.25. The word Condition means that the condition has to be met before the Activity/Process is initiated. However, the word ‘Default Condition’ conveys a wrong meaning. It is the word ‘Condition’ in the ‘Default Condition’ that is causing the confusion. Instead of saying ‘Default Condition’ can rather call it ‘Default’ or ‘Mandatory’. OR, if it mandatory then it should not branch out of a decision box and rather branch out of the Original Process.
BPMN does not explicitly identify a model element for "approval." This is important to highlight for control issues and regulatory compliance concerns. An approval symbol is apparently common in management consultant diagrams. A equlateral triangle with one edge at the base has been used for this. (this issue intended for BPMN 2.0).
BPMN does not have a symbol for a physical storage facility. This is important to highlight for management process diagrams since such facilities that may be a source of signifant costs and delays. (This comment is intended for consideration in BPMN 2.0)
We have been puzzling over the meaning of the MultiIinstance Paralllel Marker and believe that there’s a conflict in the description. We saw this in the 1.0 specification and then checked to see if the 1.1 specification had changed in any way but found it to be the same. We believe there needs to be clarification around the MultipleInstance loop MI_Ordering attribute with regards to the task marker symbol that should be used. Here’s the basic description (we’re giving table/figure references from v 1.1 draft of BPMN spec).… BPMN spec says that Standard loop will look like Figure 9.15 Image 1 And Multi Instance loop will look like Figure 9.15 Image 2 However in Table 9.20 Multi-Instance Loop Activity Attributes in the MI_Ordering attribute description it clearly states that… If set to Parallel, the Parallel marker SHALL replace the Loop Marker at the bottom center of the activity shape (see Figure 9.9 and Table 9.18). This suggests that a Multi-Instance Loop task that is set to sequential would actually have the Standard Loop Marker. The question is, which statement is correct, the first… “Standard Loop activities will have a marker that is a circle with an arrow and Multi-Instance Loop activities will have a marker that is two parallel vertical lines” Or the second… “A Parallel Multi-Instance activity will have a marker that is two parallel vertical bars. Standard loops and sequential multi-instance activities will have a marker that is a circle with an arrow on it”. These statements made in the BPMN spec seem to be contradictory. Now, to us, whether the task instances are performed in parallel or sequential is the most significant thing to display visually on the diagram. And therefore we actually think that the second statement should be true. However, whether the condition is evaluated once or on each loop iteration could also be significant enough to be visible in the diagram. We actually think that there are 3 significant pieces of information that BPMN is trying to convey with only 2 markers and associated attributes. § Separate Task instances are run in parallel. § Separate Task instances are run sequentially, and if so… o The loop exit condition is a Boolean expression and is re-evaluated on each loop iteration. o The condition is a Numeric expression that is evaluated only once before loop begins and specifies a maximum value for LoopCounter. We think that there are 2 possibilities to overcome this problem and clarify the meaning… 1) Add a new value to the Standard Loop TestTime attribute – OnceBefore – this states that the expression is numeric and specifies the number of loop iterations. Then remove the MI_Ordering attribute i.e. all Multi-Instance loops are parallel. It may be useful to introduce a new marker symbol to distinguish between OneBefore and Before/After (if it is deemed significant enough to been seen at diagram level). 2) Leave all the attributers as they are but introduce a new marker symbol for “The condition is a Numeric expression that is evaluated only once before loop begins and specifies a maximum value for LoopCounter” (i.e. a Multi-Instance Loop with MI_Ordering set to sequential. In either case, if all three pieces of information are deemed significant enough to been seen at diagram level, here are our suggestions… Multi-Instance + Parallel - use parallel bar symbol Standard Loop Before/After (Evaluated On every iteration) … You could, also distinguish between before and after by say, turning the symbol upside down for evaluate-before… Because the circle as a break in it then it suggests (maybe?) that the process engine stops to re-evaluate things each time round the loop. Multi-Instance + Sequential (or new Standard Loop + OnceBefore… Use circle with no break Because the circle has no break in it then it suggests (maybe?) that the process engine already knows how many times to go around.
I am beginner in BPM but in order to understand the BPMN standard, I send these questions: 1) Why in paragraph 7.1.1 Uses of BPMN, the definition of Collaboration (Global) Process (page 14) says: The collaboration process can be shown as two or more abstract process communicating with each other (see figure 7.3).... But the Figure 7.3 looks like as "two or more private (internal) business processes communicating with each other", comparing the Figure 7.1 and Figure 7.2 For more emphasis what I saying In the Figure 7.3 both process (patient and Receptionist/Doctor), all activities for both process are shown, this is not agree with definition of Abstract (public) process (page 13), that says: ....All other "internal" activities of the private business process are not shown in the abstract process.... 2) if the difference between Private (internal) business processes and Collaboration (Global) processes is the number of business entities, this mean that : Private (internal) business processes for only one business entity or specific organization. Collaboration (Global) processes for two or more business entities. What about Abstract (Public) processes, how many entities are or can be involved? 3) The Abstract (public) Processes are "abstract" because the activities of the another process or participant are not shown ?, using words of the definition of the Abstract (public) Processes.