I refer to BPMN Spec. Version 2.0.2.
I really miss the data storage element which is supported by all BPMN tools that I know:
in Spec. chapter 7.3.1 or 7.3.2.
What happened with this element ??
Textual description of the two Multiple Instance shape types (2nd column) describe both shapes as "Sequential", whereas one should be "Sequential", and the other "Parallel".
Text copied belowL
"A set of three horizontal lines will be displayed at the bottom-center of the activity for SEQUENTIAL Multi-Instances (see upper figure to the right).
"A set of three vertical lines will be displayed at the bottom-center of the activity for SEQUENTIAL Multi-Instances (see lower figure to the right)."
"Table 10.31 - ComplexBehaviorDefinition attributes and model associations" contains the following text: "This attribute defines a boolean Expression that when evaluated to true,
cancels the remaining Activity instances and produces a token."
In chapter "13.3.7 Multiple Instances Activity", where the execution semantics are described, however, there is no mentioning that multi-instance activities with complex behavior cancel instances as soon the ComplexBehaviorDefinition's condition becomes true.
Probably the text fragment "cancels the remaining Activity instances and" in the table is wrong and should be removed. Otherwise, the execution semantics chapter should be extended accordingly.
"Table 8.51 presents the additional model associations for the Resource element."
should be
"Table 8.49 presents the additional model associations for the Resource element."
"Table 8.51 presents the additional model associations for the
ResourceParameter element."
should be
"Table 8.50 presents the additional model associations for the
ResourceParameter element."
p.206 states:
Visual representations of Data Objects
Data Object can appear multiple times in a Process diagram. Each of these appearances references the same Data Object instance. Multiple occurrences of a Data Object in a diagram are allowed to simplify diagram connections.
p.368 states:
Multiple depictions of a specific BPMN element in a single diagram is NOT allowed, except for Participants in a choreography (i.e., Participant Bands). For example, it is not allowed to depict a Task twice in the same diagram, but it is allowed to depict the same Task in two different diagrams.
This seems like a contradiction. Only one of the above should be true.
"Table 10.60 presents the additional attributes and model associations of the
DataInput element."
should be:
"Table 10.60 presents the additional attributes and model associations of the
DataOutput element."
"Table
10.54 presents the additional attributes of the Property element."
should be:
"Table
10.57 presents the additional attributes of the Property element."
"Figure 10.54 presents the additional attributes and model associations of the
InputOutputSpecification element."
I believe, this should not even be a figure, but a Table, and with different number:
"Table 10.58 presents the additional attributes and model associations of the
InputOutputSpecification element."
"Table 10.54
presents the additional attributes and model associations of the DataObject element."
should be:
"Table 10.54
presents the additional attributes and model associations of the DataState element."
Table 10.96 states that there is attribute, called "error", while the XSD schema contains attribute "errorRef".
Figure 10.57 does not show that InputOutputSpecification derives from BaseElement.
The textual description and the related XSD schema correctly show that InputOutputSpecification derives from BaseElement. However, figure 10.57 does not have an arrow for this inheritance.
Table 10.55 defines the default value of DataStore.isUnlimited to be false:
isUnlimited : boolean = false
However, the XML Schema says:
<xsd:attribute name="isUnlimited" type="xsd:boolean" default="true"/>
Proposal:
Change the XML Schema to:
<xsd:attribute name="isUnlimited" type="xsd:boolean" default="false"/>
BPMN says that you use a parallel gateway (diamond with a plus in it) to start a sequence of parallel paths, and another AND gateway to end it. The behaviors of these two gateways are different, but they look the same. Suggestion is that the first AND gateway, that starts the parallel split have a thin line, while the gateway at the end which actually waits for multiple inputs will have a thick line. This corresponds to the thin and thick lines around start and end nodes.
A Task or Sub-Process may have multiple markers (e.g., looping, compensation, etc.). But the spec does not explicitly define how the markers should be ordered. The examples in the spec are not consistent in how they are presented.
Data associations need to be revisited and their use clarified.
Data association should have there own visual depiction. Using the look of association is misleading as data associations have a different meaning than associations.
A data association is an edge between flow elements (data objects(ref) and data stores(ref))as such they should not cross boundaries of pools or can they? This is not clear.
It is also not clear if data objects(ref) and data stores (ref) can be drwan outside lanesets or pools.
There is a proposal to add conformance levels to BPMN 2.0. The proposal for a Descriptive level should include Link Events.
It is possible that User Tasks may send and/or receive messages. Thus, the mechanisms built into Send, Receive, and Service Tasks should also apply to User Tasks.
Also, Message Flow can connect to any Task. Thus, there should be some restrictions on this or messaging should be applied at the Task level instead of the individual sub-types
Currently, send/receive/service/user/business rule tasks have an "implementation" attribute. Based on the information in the spec and from the process orchestration subgroup call, this attribute shall identify the technology to be used for interaction. This can be Web Service, WS-HT or any other protocol/coordination protocol.
While this makes sense for human tasks and business rule tasks, there are a couple of inconsistencies with Send/Receive/Service tasks. Here is why:
My proposed resolution is to remove the implementation attributes for send/receive/service tasks. We should discuss whether this information is really needed or whether it could be inferred by the implementationRef of the interface/operation tuple. The information might be needed to determine in which technology an interface/operation is implemented. See also http://www.osoa.org/jira/browse/BPMNFTF-519#action_15739
As an alternative, MessageEventDefinition would need such an attribute as well.
Filed for soaML: When multiple hexagons (conversation/communication) are
expanded, it isn't possible to tell which message flows go with which
hexagons, because the hexagons disappear. Should have a grouping
notation to show which message flow came from expanding which hexagons.
Table 10.1, definitionalCollaborationRef includes the phrase “For Processes that interact with other Participants,” which implies that Processes are Participants. In fact they are distinct elements in the metamodel.
More significantly it states “The definitional Collaboration specifies the Participants the Process interacts with, and more specifically, which individual service, Send or Receive Task, or Message Event, is connected to which Participant through Message Flow.” However a Process could be linked to Participants in many Collaborations and so the multiplicity of [0..1] seems over-limiting.
Most diagram elements carry a text label. The current version of the spec only allows to specify one string that is used as label.
Multi-national companies often document their business processes in multiple languages (English, German, Spanish..). BPMN should therefore allow to set multiple labels per element (+ default language for the diagram)
In section 10.4.1, Event Concepts, (page 211 -241 PDF) there are some confusing statements about Sequence Flow. For example, one statement reads: "The Data Association for a Throw Event is performed when the Sequence Flow arrives at the Throw Event."
Sequence Flow do not "arrive" in this context. The statements should be revised to refer to Tokens arriving at the Events to make consistent with the rest of the specification
The other Event Definitions have a brief description of what they are. The Error and Escalation do not have this description.
There is an obvious redundancy in defining data in BPMN 2.0 (data objects, item definitions, messages, import of schema,...). The current spec does not say what is mandatory to be specified in which situation. At least the most common scenarios should clarified in the spec, e.g. what must be specified in case a WSDL doc is already available and the message described in this document should be used by a service task; or what must be specified in case in incoming message (by a start event) should be copied to a data object.
I submitted a comprehensive document describing the situation to the issues@omg.org address, whithout any reaction since weeks. I am happy to send this document to the one assigned to this issue and discuss it.
BPMN uses temporal semantics currently in process abstraction, and token flow in process execution. It isn't currently clear which semantics should be used for what purposes, or if they are compatible. Temporal semantics should be highlighted as one of the semantics for sequence flow, especially in conjunction with definitional collaborations, and it should be related to the token semantics.
Filed for Alistar: Enforcability rules not complete.
The spec allows multiple choreography activities to share the same
message flow. Is that intended?
The word "list" is used a fair amount in describing attributes and model
associations. I think these are intended to be sets in most cases,
rather than lists (no ordering, no duplicates). In UML, the default is
sets, you need to add "
" "
{non-unique}" to get lists.
Some activities (or other elements) may have properties that would allow them to be placed in more than one lane. For example, a Task could be assigned multiple resources. Is there a way to display the activity in multiple lanes? If not, how is would the most appropriate lane be chosen?
Filed for Alistar: Conversations / communications sharing correlation
properties should be linked graphically.
Right now there is no clear separation on which graphical features (like line thickness, type of lines, color, etc) vendors are free to use as extensions, and which are restricted for the specification to use.
We should define which features we want to use in the spec and which ones vendors are free to use. The reason for this is that if a vendor chooses line thickness for some visual extension and in a revision we choose to use the same feature, the vendor is forced to change to adapt (most importantly end-users).
For example: it is clear that color is open for vendor extensions, and we should pick lines (thickness, dotted, etc) as restricted for our use.
Currently interface operations in BPMN follow a "Document" model where all the arguments are wrapped in a single "Message" in and out of the operation.
But in UML, interface operations follow the "RPC" model, where arguments are independent and each one has the "In, Out, InOut" classifier.
This difference creates several problems when trying to relate/map BPMN and UML operations. Another side effect of the BPMN message model is that you cannot use simple data associations to fill the arguments of a service call. Since the operation is a single type, we have to use transformations to target the arguments (in my case we hide this complexity from the end user, and probably every vendor will do the same.
So, if the FTF wants to have a reasonable integration with SoaML, we should fix this issue. The proposal is to adopt the UML model, with separate arguments instead of a single document in and out.
We understand this is a major change, and a migration path from the Beta spec to the final one is a mandatory requirement.
Description of issue: The description for Task needs revisiting
Proposal: Reword to make it clear that Task has a purpose and usage in itself, beyond being a superclass for specialized tasks.
##Source: Oracle (Vishal Saxena, vishal.saxena@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-118
##Original Info: (Severity: Minor - Nature: Revision)
On page 122 (152 in PDF) under fig 10-2 we describe process as a callable element. I think its a good idea to give small introduction.
Comments:
From: wstephe created: Fri, 11 Sep 2009 17:12:58 -0500 (CDT)
The page and section numbers were updated to match the Beta 1 spec
The metamodel seems to be missing relations between the correlation
information in multiple conversations of the same collaboration /
choreography. For example, in Figure 11.3 (Conversation diagram
depicting several conversations between Participants in a related
domain) how does the process internal to Consignee handling the
Consignee-Retailer conversation map its correlation information to the
correlation info in the Consignee-Supplier conversation? Without this
the Consignee conversations with the Retailer and Supplier will be
uncoordinated.
This is number 1 of 12 issues submitted by Bruce Silver:
Define explicit separation of "modeling" vs "implementation" attributes. The current "core" vs "extended" is nowhere close to this, since modeling needs much of the extended set. Modeling is about orchestration of "abstract" activities, abstract meaning they have a name (label), task type, perhaps markers like loop/MI/adhoc, and unique id of course, but not implementation properties. Abstract sequence flow has name, source and target refs; if conditional, the label is sufficient - you don't require a conditionExpression. Message flow or message event does not require a message attribute, timer event does not require TimeDate or TimeCycle (please rename it to Duration) attribute, error event does not require an error code attribute, etc. Those are for implementation; in modeling it's the diagram that counts, i.e. the label.
The term "pool" is used extensively in the specification yet the definition seems inconsistent and not tied to the meta model. Sometimes a pool seems to be the role of a participant in a process context. In other cases it seems to be the essential container of a process. It seems to be a graphical element but shows up on ends of associations and in definitions of the semantics. The term "pool" does not seem to have any semantic relevance to process.
Examples:
• While a normal Process exists within a Pool, a Choreography exists between Pools (or Participants).
• A Pool is the graphical representation of a Participant in a Collaboration (see page 235). It is also acts as a "swimlane" and a graphical container for partitioning a set of Activities from other Pools, usually in the context of B2B situations.
• Nor can Sequence Flow cross a Pool boundary.
• For message exchanges between pools, Conversations are used to group several Message Flow
• A Participant is a specific business entity (e.g., a company) or a more general business role (e.g., a buyer, seller, or manufacturer) responsible for the execution of the Process enclosed in a Pool.
The semantics behind of pool should be clarified and the spec should not use graphical elements to define semantics.
We need to document the changes from V1.1. For example, we removed two attributes from User Task, because the same functionality is being handled elsewhere. We need to document such changes to make it easier for the implementers that need to migrate.
Comments:
From: mariano.benitez created: Wed, 8 Oct 2008 15:57:52 -0500 (CDT)
We also dropped the concept of "streaming" data, so this should also be included in this section.
Assignments elements are also removed, converted to DataAssociations.
From: wstephe created: Sat, 12 Sep 2009 13:47:45 -0500 (CDT)
Spec Draft version removed to prepare for BPMN 2.0 FTF
Introduction of end type break within a loop construct (continue construct is already there, implemented by the terminate end type which can be used inside a loop (multi instance activity) to end the loop).”
This relates to what is e.g. said on page 407: “For a “terminate” End Event, the Sub-Process is abnormally terminated. In case of a multi-instance Activity, only the affected instance is terminated.”
So, differentation is required between the two modes of getting out of the loop.
We have created some guards around the use of unavailable data in expressions of Data Associations.
The issue I am raising is about the use case when a conditional sequence flow uses an expression, and the data objects used in that expression are unassigned.
Description of issue: The first three paragraphs in section 8.4 are duplicates of the same paragraphs in 8.3.10 where gateways are introduced.
Proposal: Replace paragraphs in 10.5 by a short paragraph and a reference to 8.3.10's gateway section.
The use of some gateways should be described by example, e.g. complex gateway, inclusive gateway, multiple instances
Decisions are prevented from being used Choreographies if not all
participants have access to the information on which the decision is
made. But if the activities following the gateway are all sent by the
same participant, only that participant needs to know how the decision
is made. Using an event-based gateway in this case is confusing, since
there is no waiting for events to proceed to the activities following
it. Some sided email below about this.
Steve,
> The Gateway would most likely be Event based. The Buyer is
> probably not going to be aware of the data that would be
> used to make the decision, particularly a change order.
> Thus, the Buyer is just going to be waiting for one of the
> three responses.
Makes sense for the buyer, but this isn't a model of the buyer (and the
Seller is making a regular decision, why isn't that shown?).
It's also odd to see an event-based gateway in a choreography since
choreography can't don't wait for events, the participants do. The
figure looks right according to the spec, but I think the spec is too
restrictive on regular decisions in choreogrpahies.
Conrad
Steve,
> The Seller is making a regular decision internally, but the
> rationale (i.e., data) used to make the decision is private
> for the Seller. A Choreography can only use Exclusive
> Gateways if the data used for them is public.
I understand that's the rule, but I'm not sure it make sense. In this
case, the activities following the gateway are all initiated by the
Seller. The rule should be that the seller has access to the decision
data.
> The Buyer does not know ahead of time, what the
> results of the decision will be since the Buyer has not seen the
> Seller's internal data.
And that's fine, because it isn't the Buyer who initiates any of the
activities after the gateway.
> All private Exclusive Gateways show up as Event Gateways in a
> Choreography.
This is too hard to explain, for example, who receives the event? The
choreography itself can't received an event, and there's no indication
that it's the Buyer (other than they Buyer is receiving in the
activities after the gateway).
For FTF discussion. 
Conrad
Section 12.6.4 (Parallel Gateway) says "They create parallel paths of
the Choreography that all Participants are aware of." Not all
participants, only those involved after the gateway.
An event-based gateway implies a message is being waited for, but
choreographies can't receive messages, they have no central controller.
One of the participants will have an event-based gateway internally, but
the other will have a exclusive gateway. The choreography can use an
exclusive gateway with no conditions, with the semantics is that exactly
one of the following messages will be sent.
Comments:
From: conrad.bock created: Mon, 13 Jul 2009 15:53:49 -0500 (CDT)
Email from Frank about conditions on exclusive gateways in choreographies:
Hello Conrad,
In my opinion there is no need to even have data as decision criteria.
There may be a button, that a user presses (request xy..). Of course you
can discuss, that the fact, that a button has been pressed is in itself
data in the system. But it is a different kind of.
So in the case of two senders there are two users and two buttons.
Whoever presses first sends first.
Whoever sends second is in a different branch of the choreography.
That's how I understand it.
Page 453. The first sentance of the section states:
"The following table displays the mapping of an embedded Sub-Process with Adhoc="False" to a WS-BPEL scope. (This extends the mappings that are defined for all Activities--see page 450):"
However, the table is not there.
The general description of Complex Gateways needs improving. An example or two would be good.
Comments:
From: wstephe created: Sun, 13 Sep 2009 23:49:07 -0500 (CDT)
The version number was removed from the summary so that it will apply to the Beta 1 spec
When a business commits to an interaction with potential business
partners, it might be that a particular partner needs only some of the
interaction. This would be specified in another interaction diagram.
The modeler needs to link these two interactions to say one supports the
other, with the same semantics of the currently supports association,
except applied to messaging rather than activities. The supports
association should be generalized to cover interactions
PartnerRole does not specify the context of the role (is it a role in an
organization?). The examples given (a buyer, seller, or manufacturer)
could just be Participants, rather than PartnerRoles. The term "role"
also conflicts with Participants, which are effectively roles in
Interactions.
The first sentence of the paragraph under Figure 11-4 (Conversational
view choreographies) refers to Figure 11-3, but is about Figure 11-4, as
far as I can tell. How is the parent-child relation referred to at the
beginning of the paragraph reflected in the notation or metamodel? It
says the Planned Order Variations as being keyed on Order Id, but the
figure shows it keyed on Variation ID also (compare to description of
Retailer Order and Delivery Variations Ack). The paragraph refers to
Conversations instead of Communication.
The second paragraph under Figure 11-4 refers to Detailed Shipment
Schedule and Delivery Monitor, which aren't in Figure 11-3 or 4. The
paragraph refers to Conversations instead of Communication.
The third paragraph under Figure 11-4 refers to Delivery Planning and
Special Cover, which aren't in Figure 11-3 or 4. It mentions messages
spawning conversations, which isn't described anywhere else. The
paragraph refers to Conversations instead of Communication.
The section on gateways in choreography covers splits (diverging)
gateways but not merges (converging) for parallel, exclusive. Only
merges are covered for complex gateways.
Send/receive events and tasks have the same meaning, but the
Collaboration section only shows message flow to/from tasks and other
activities. Clarify that message flow can be attached to send/receive
events in Collaboration.
Figure 8-18 (The Correlation Class Diagram) is missing the association
end name listed in Table 8-32 (CorrelationKey model associations).
Comments:
From: wstephe created: Fri, 24 Jul 2009 12:40:19 -0500 (CDT)
I was going to add an issue that would request to remove the conversation model association row from Table 8-32. The model association is uni-directional, so correlationKeys should appear in the Conversation table (11-1), but conversation should not appear in the CorrelationKey table (8-32).
About event-based gateways in choreography, the spec says:
[Event-based] Gateways are used in Choreography when the data used to
make the decision is only visible to the internal Processes of one
Participant.
On the right side of the Gateway [CB: I assume this means immediately
after]: either the senders MUST be the same; or the receivers MUST be
the same.
If the decision criteria is private to one participant, how can there
multiple senders after the gateway?
Exclusive gateways in choreography are required to use decision data
accessible to all participants involved in the gatway. But if if the
senders after gateway are the same, then receivers can use event
gateways or event subprocess to wait for event that might never come.
It isn't necessary for the receivers to have access to the decision
data.
The hook in BPMN for Resource Models is through the Resource class. Generally, Organization Models are considered separate from Resource Models, but there is not a separate hook for Organization Models in BPMN, the Resource class would have to be used for Organization models, which could be confusing.
The Resource class could be renamed to make it more generic, or a new class for Organization could be added.
Notation for data input/output sets is missing. I/O sets have a similar
execution effect as decision and merge gateways, so it seems like they
should be visible.
Comments:
From: wstephe created: Fri, 13 Mar 2009 13:50:54 -0500 (CDT)
The decision on this for BPMN 1.X was that there would be no notation for this since it would probably be too complicated. There was a non-normative suggestion that inputs that belong in the same inputSet could be connected to the same point on the activity, but we didn't want to have anything like pins. I haven't seen any other suggestions. If we had something to look at, then we could consider.
But, in general, in probably should be deferred for now.
Filed for Dale Moberg. The rule illustrated by Figure 12-36 is that the
choreography activities after an exclusive gateway must have the same
receivers if the initiators are different. However, the receivers can
be different if the activity starts a new process in the receiving
participant, or if the receiving participant has access to the data in
the decision from earlier in the flow. Steve says the discussions so
far did not account for activites that start processes in the
participants.
From side discussion with Frank: A single public interaction
(choreography, collaboration, or conversation) might be supported by
multiple internal processes, but the current metamodel only allows one
process per participant. The multiplicity should be widened to *.
dataOutputAssociation/@sourceRef should be optional, not required.
dataInputAssociation/@targetRef should be optional, not required.
This is to support non-executable models (<a href="http://www.osoa.org/jira/browse/BPMN-381" title="Abstract BPMN Profile"><strike>BPMN-381</strike></a>), since these elements are part of the data interface of the parent node, which is unspecified in non-executable models. The other end of the association, the dataObject, is still required.
Comments:
From: ssamoojh@ca.ibm.com created: Thu, 14 May 2009 11:04:19 -0500 (CDT)
Counterproposal - Rather than making the source or target optional, instead 'lighten' the spec text. The spec currently states that the source or target must be an ItemAwareElement. In the case of non-executable models, the source or target may be the FlowElement itself. So my proposal is to tweak the spec text, so as to allow this.
The Parameter class is an association of ProcessRole. Parameter has its own attributes. Thus, there should be a short subsection that describes Parameter, including a table that describes the attributes.
A general question: Parameter is a very generic name. Should this class be named something more specific?
Beta 1: Section 14.2.2 Activity (semantics): The state of a Data Object should be considered as a Performance Constrainst for an Activity Changing from the Ready to Active state
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-411
##Original Info: (Severity: Critical - Nature: Enhancement)
The state of a Data Object should be considered as a Performance Constrainst for an Activity Changing from the Ready to Active state.
If a Data Object is not in the state defined as an input (e.g., "Approved"), then the InputSet should not yet be considered "available."
From examples meeting on 2009.03.26:
When creating the looping example for <a href="http://www.osoa.org/jira/browse/BPMN-281" title="V0.5.6: Section 10.3 Data [Data]: Assignments not defined"><strike>BPMN-281</strike></a>, it is not obvious how to initialize properties. Also, updating a property via a dataInputAssociation or dataOutputAssociation is unnecessarily complicated because sourceRef and targetRef are currently mandatory elements, but not really applicable for properties.
Proposal:
(1) Introduce a new entity "initializationAssignment" (or better name) as a contained element for property (and data object for symmetry reasons), which has the same structure as assignment, but with an optional "to" element.
(2) Make dataInputAssociation::sourceRef and ::targetRef optional, likewise dataOutputAssociation::sourceRef and ::targetRef.
Comments:
From: trickovic created: Tue, 7 Apr 2009 04:00:15 -0500 (CDT)
As per 4/6 BPMN 2.0 meeting: Defer <a href="http://www.osoa.org/jira/browse/BPMN-471" title="Initializing and updating properties is not straight-forward">BPMN-471</a>.
Section 17 will be temporarily removed until the BPMN example is added.
The section should have a full example with diagrams, XML, and supporting text.
There is no association between PartnerEntities and PartnerRoles, even
though entities will play roles. The only link currently is through
participant, requiring modification of a C models to link a role or
entity, see <a href="http://www.osoa.org/jira/browse/BPMN-520">http://www.osoa.org/jira/browse/BPMN-520</a>. An association
between partner entities and roles would enable collections of C models
to be grouped by roles, with roles reused by entities.
Add an example of Mutlple Start Events on the Boundary of a Sub-Process as shown in an example for Issue 145 and described in the execution semantics section.
Section 10.2.5, Beta 1 spec
The figure for the mapping of Message to BPEL shows a snippet that includes a StructureDefinition element. The actual attribute for Message is structureRef, which points to ItemDefinition.
This figure should be updated.
Some sections with TBDs were removed for the Nov OMG posting. These sections should be returned and filled with content.
This section should match a parallel section in Chapter 11 (Choreography).
Mainly Editorial:
A HumanPerformer is a type of Performer, but there is no reference to this in the Performer section. There should be more description of how Performer can be used (e.g., through HumanPerformer).
The background text for the description of Collaboration is rather thin. Add more description and a figure or two.
The Sequence Flow constraints around the usage of Link Events are not clearly expressed in the spec.
Very simply, it should express that:
Instead the spec has several rather confusing statements (pgs 235-236) that make it hard to infer the simple behavior I described above.
Statements like:
Recommendation:
Description of issue: This section mixes conceptual meta-model statements with visual representation statements. A clearer separation of those concepts is needed.
– p 127 (157 in PDF) "... inclusion of re-usable tasks and processes in the diagram" should be "... invocation of re-usable tasks and other processes from the process"
– p 127 (157 in PDF) "... a process is not a graphical object. Instead, it is a set of graphical objects." A process is neither, it is a container for activities and other entities, all of which have a graphical representation.
– p. 133 (163 in PDF) ff "A task is a rounded corner rectangle" should be "A task is represented by a rounded corner rectangle". This occurs frequently for all task types, so globally change "is a rounded corner rectangle" to "is represented by a rounded corner rectangle"
Section 9 Collaboration [Choreography; Specification, Metamodel]: Clarify that a pool represents a single BPMN process, not a "participant" meaning role or business entity
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-299
##Original Info: (Severity: Significant - Nature: Enhancement)
This is number 2 of 12 issues submitted by Bruce Silver
Clarify that a pool represents a single BPMN process, not a "participant" meaning role or business entity. At least do this for a white box pool (aka private process); a black box pool (abstract process) is empty of activities, so its process is unknown and often labeled as role or business entity. Also remove the language that multiple pools in a BPD are about B2B. This is rarely the case. Multiple white box pools in a BPD are used when the processes involved have independent lifetimes and cardinality, and almost always when both pools represent the same business entity not B2B.
This is number 3 of 12 issues submitted by Bruce Silver
Enumerate the validation rules of BPMN. Back in the old days when the BPDM guys kept saying BPMN 1.0 had no explicit rules or metamodel, you said it did but it was buried in the narrative. Now you have an explicit metamodel but the rules are still buried in the narrative, and inconsistent from one part to the next. Judging from v1.x it will take years to clean up the narrative, so just enumerate the rules in one place and say this overrides contrary info elsewhere in the narrative.
Beta 1 Spec: Section 10.3 Data [Data]: If start of an activity is guarded by availability of input data, there should be some visible indication of this in the diagram
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-302
##Original Info: (Severity: Significant - Nature: Enhancement)
This is number 5 of 12 issues submitted by Bruce Silver
If start of an activity is guarded by availability of input data, there should be some visible indication of this in the diagram. ("Modeling" means you don't need to see the non-diagram attributes). It seems like BPMN 2.0 is trying to make data more a first class citizen, so this is needed.
Comments:
From: bruce created: Fri, 5 Dec 2008 17:29:56 -0600 (CST)
In a user task, it is understood that time can elapse between task ready and active, whereas in service task there is no delay. So the temporal semantics are clear from the diagram. The issue is when service task is guarded by data "availability" - whatever that implies. If service task could incur delay between ready and active because of input data, this should be visible somehow in the diagram.
Better clarify the subset of BPMN diagrams that are BPEL-mappable (roundtrippable!)
Description of issue: Missing example for process structure
Proposal: Add an example showing process structure.
Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.
Comments:
From: mkloppmann created: Thu, 19 Feb 2009 12:30:43 -0600 (CST)
Per the 2009.02.19 examples sub-team meeting:
– Medium priority
– The example should contain activities, events, gateways
– Combine with <a href="http://www.osoa.org/jira/browse/BPMN-316" title="Provide example: Basic gateway examples">BPMN-316</a>
Description of issue: Missing example for Inline Subprocess
Proposal: Add an example showing Inline Subprocess
Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.
Comments:
From: mkloppmann created: Thu, 19 Feb 2009 12:33:25 -0600 (CST)
Per the 2009.02.19 examples sub-team meeting:
– This item is related to <a href="http://www.osoa.org/jira/browse/BPMN-365" title="Notation for data flow in/out of a process">BPMN-365</a>
Description of issue: Missing examples for basic gateways.
Proposal: Add three examples showing XOR, IOR and AND gateways.
Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.
Comments:
From: mkloppmann created: Thu, 19 Feb 2009 12:31:13 -0600 (CST)
Per the 2009.02.19 examples sub-team meeting:
– Medium priority
– Combine with <a href="http://www.osoa.org/jira/browse/BPMN-310" title="Provide example: Basic process structure">BPMN-310</a>
Description of issue: Missing example for multi-instance activity.
Proposal: Add an example showing a multi-instance activities, including data assignments from a set of values to the individual parallel instances, and from the results of the parallel instances to a result set. This will require collaboration with the Data team.
Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.
Description of issue: Missing choreography example
Proposal: Add an example showing a choreography with several choreography activities, based on the existing example.
Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.
Type: Technical
Description of issue:
1. The spec misses the mapping for intermediate message send events
2. The spec misses a mapping for send/receive events and tasks where the other party is specified not by a service-ref, but by a message flow to another participant.
Proposal:
1. Include that mapping into spec (see Visio)
2. Introduce text describing how BPEL partnerLink is derived from either serviceRef or participantRef; use [serviceRef | participantRef] or similar notation as abbreviation.
Beta 1 Section 8.3.17 Sequence Flow and 14.2.1 Sequence Flow Considerations (Execution Semantics): Add Exclusive conditional behavior from activities
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-349
##Original Info: (Severity: Significant - Nature: Enhancement)
Suggested by Michael Rowley: Add Exclusive conditional behavior from activities.
"Perhaps there should be a new variant of the minidiamond symbol to show that they are exclusive (filled in black, perhaps?). For human activities, it would then be clear that the different flows are different choices that can be made by the user. In B4P they would also be the "outcome" of the task."
This was discussed on a BLOG (<a href="http://kswenson.wordpress.com/2008/01/01/human-process-trouble-ticket/#comment-8886">http://kswenson.wordpress.com/2008/01/01/human-process-trouble-ticket/#comment-8886</a>)
Proposal TBD
Description of issue: Missing example for complex gateway.
Proposal: Add an example showing a complex gateway.
Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.
Type: Example
Description of issue: Missing example for Conversation View.
Proposal: Add an example showing a conversation view.
Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should
also be provided using BPMN notation.
Comments:
From: wstephe created: Mon, 1 Dec 2008 21:45:34 -0600 (CST)
An example has been started. It needs to be finished (including XML).
Also, we should use this issue to track the full text requirements for Section 9.5 "Conversations" (V0.9.1)
Complete 11.4.1, 11.4.2, and 11.4.3 on choreogrpahy events.
Each sub-section may require more text, review and some example and pictures.
Comments:
From: trickovic created: Fri, 12 Dec 2008 06:37:38 -0600 (CST)
Issue assigned to Steve/the choreography team.
Some sections with TBDs were removed for the Nov OMG posting. These sections should be returned and filled with content.
This section should match a parallel section in Chapter 10 (Process).
Reported by dga...@trisotech.com, Jul 29, 2009
Is it still allowed to have Start and End Event on the boundary of an
expended Sub-process?
This was clearly stated and shown in BPMN 1.2. It is mentionned
at page 251, but no example are provided.
Is figure 7-8 page 69 valid?
Reported by dga...@trisotech.com, Jul 29, 2009
The figure 8-1 indicates "Infrastructure, Common Elements, and Services".
Three Core sub-packages are listed in page 71 "Foundation, Service, and
Common".
Figure 8-2 shows "Foundation, Common, and Service".
Section 8.1 describes "Infrastructure", Section 8.2
describes "Foundation", Section 8.3 describes "Common Elements" and
Section 8.4 describes "Services".
The list of BPMN core elements indicated in thre first bullet of section
2.1.1
is: "Infrastructure, Foundation, Common, and Service packages."
Is there 3 or 4 sub-packages and should we use the same naming convention
within this section of the document?
Since you still have the concept definition for "Business Process" listed as "TBD" in the Glossary, PNA would like to propose the following definition:
Business Process:
A Business Process is a cooperation between several people and/or systems each performing a particular role and possible other entities such as departments within a company or organization, in order to produce a product or to deliver a service to a customer. Within BPMN a Business Process is described using a BPD.
Currently only Sub-Processes can be Ad Hoc. However, it would be useful for Processes to be Ad Hoc also. This would allow libraries of Ad Hoc Processes to be defined and re-used
Page 203, Table 10-26, The text describing the none and all behavior of the behavior attribute have been inverted.
There are many situations where a human involved in a process triggers an Event. The current set of Event types do not adequate reflect this situation. Thus, a new type of Event, a User Event, should be added to BPMN.
This is a style suggestion to make diagrams clearer. The XOR gateway allows two forms of diagram: empty diamond, and a diamond with an X in it. While redundancy is OK in general, the fact that different vendors make different choices. But an X and a cross look very similar. While the X should be allowed, the spec should indicate that it is preferred to use the blank option, with the eye to eventually eliminating the X.
Reported by dga...@trisotech.com, Jul 08, 2009
The spec should prescribe how diagram fragments are presented. (e.g.
three dots at end of continuing flows, ...)
Given that BPMN has very specific structural requirements, most diagram
fragments in the spec (and elsewhere) are not valid BPMN models.
Reported by dga...@trisotech.com, Jul 06, 2009
The Message element is not listed in any of the categories
Comment 1 by dga...@trisotech.com, Jul 10, 2009
The Message element is not listed in any of the BPMN element categories
Chapter 10.7 needs a more detailed example of how lanes can use process information/elements to partition flow objects