Connection of Throwing and Catching Link Events ambiguous

[falko]

The BPMN spec is ambiguous about the connection of throwing and catching Link Events. I see two possible interpretations:

1. Throwing and Catching Link Events are correlated using the mandatory attribute name and the attributes source and target are just optional similar to incoming and outgoing.
2. Throwing and Catching Link Events are correlated using the attributes source and target.

After further investigation, I discovered that the BPMN 2.0 Finalization Task Force intended to introduce the attributes 'source' and 'target' to avoid the correlation via names. See also OMG Issue 14816, BPMN 2.0 FTF Report and BPMN 2.0 FTF Report Verification Site.

Here is the resolution that all FTF members accepted:

This is what's in the final BPMN 2.0 specification:

So it looks like source and target are meant to be used for link correlation. However, this raises further questions:

1. Why is the name attribute still there?
2. Does this new mechanism break backwards compatibility with BPMN 1.x?
3. How did vendors actually implement it in their current implementation?

[falko]

When I think about connecting Link Events in a modeling tool, I believe that source and target are rather impractical to handle in a user interface.

Furthermore, I challenge the key arguments raised in OMG Issue 14816:

There is no constraint on names, so I could create multiple Catch Link Events with the same name, thus breaking the model.

There plenty of other places in the BPMN spec where constraints are only expressed by plain text.

Names are not used, in general throughout the spec, for formalizing relationships. Instead IDs are.

In fact Error, Escalation and depending on the implementation event Signal and Message Events are correlated via simple names.

Users do sometimes assign different names to the Throw and Catch (for example "A" for the throw and "from A" for the catch).

That is certainly true for the name of the Event, which is displayed graphically as a label in the diagram. But the name of a Link is an attribute of the underlying Event Definition. So different values for documentation are perfectly handled without source and target. However, most other Event Definitions refer to some central definition of the according Error, Escalation, Signal or Message. This is a generic pattern of BPMN Events, which could be applied to Link Events to avoid direct correlation via names that are entered by a user in multiple parts of a model.

Proposal:
Keep the attribute name as correlation key and completely remove source and target (or if that is not possible for backwards compatibility, make them completely optional like incoming and outgoing).
Optional: Make Link Event Definitions refer to central Link definitions.

[mskurz]

I tend to use explicit associations instead of implicit associations that are based on names.
IMHO, this creates easier to maintain models and it is more consistent with most parts of the spec.

Even if link events are explicitly associated, it is still helpful to add a name to the events in order to represent the association visually.
(Repost)

[falko]

In our meetings we discovered that almost none of the participating vendors implemented the connection between throwing an catching Link Events in the way described in the final version of BPMN 2.0. Now we want to find out if it would be easier to change the specification rather than all the tools. In the end, the spec is for the vendors and if the majority of vendors follows a different path, the standard needs to adapt.

Therefore, we would like to invite you to participate in a quick survey to clarify this issue:

• Please draw the BPMN diagram below in your favorite modeling tool and connect the throwing Link Events with the catching Link Event. Then export the model as a BPMN 2.0 XML file and send it to [email protected]. The results will be discussed in next weeks meeting.

[falko]

I added a new Git repository to store the results: https://github.com/bpmn-miwg/bpmn-link-event-survey

[AlbertoManuel]

I have a different perspective on this issue.

The link event is widely used in process documentation (procedures for example) where the process model is break across multiple pages. Limiting to comply with the possibility of using link events is half way to not letting companies to proper document business processes.

[falko]

@AlbertoManuel Can you explain your concern a little more? We are not discussing to abandon the Link Event, but just how they should be connected in a model.

[AlbertoManuel]

Falko:

Now I understand where you are coming from. When you formulate the challenge, I assumed it was to get rid of link events. Please forget my previous comments.

Best

Alberto.

Enviado do meu iPad

No dia 14/01/2014, às 17:45, Falko Menge [email protected] escreveu:

@AlbertoManuel Can you explain your concern a little more? We are not discussing to abandon the Link Event, but just how they should be connected in a model.

—
Reply to this email directly or view it on GitHub.

[falko]

Statistics as of 2014-01-15
1 (MID Innovator): no link support
2 Signavio, Yaoqiang: event label = link name
2 Trisotech Visio Modeler, camunda: link name can be set independent from event label
1 itp-commerce: name autogenerated ID + source & target
1 W4: source & target, name not used for correlation

[SimonRinguette]

On the 2014-01-15 meeting, this issue was discussed in the light of the survey results conducted at https://github.com/bpmn-miwg/bpmn-link-event-survey about how vendor currently serialize the link events. It was found that there is a divergence in the vendor serialization of the linkEventDefinition attributes to correlate the link events.

Some vendor uses the "name" attribute as it was before in BPMN 1.X to correlate and other uses source/target.

It was decided in the meeting that we would recommend to the FTF to clarify the intention of the specification without a set proposal but exposing the divergent vendor position on the issue.

As reported by @falko in the previous comment, 3 general approach were used by vendors and 2 vendor used each approach.

• intermediateEvent "name" attribute used for correlation (2 vendor)
• linkEventDefinition "name" used for correlation (2 vendor)
• linkEventDefinition Source/Target used for correlation (2 vendor)

The first and second approach produce very similar serialization, the first one only giving less user flexibility (can't detach the graphical label from the linkEventDefinition name).

The specification seems to point toward Source/Target as the proper serialization but seeing that most vendors went the backward compatibility route, this issue need a specification clarification on the intention.

[falko]

We just received an E-Mail from Jim Lange stating that:

Oracle BPM currently does not support link events. If a user imports a BPMN 2.0 file containing link events, they are converted to signal events (which Oracle does support).

[SimonRinguette]

This discution was re-opened in the 2014-01-22 meeting. There was a feeling that we needed to make a proposal to the FTF group based on what the vendors would feel the best way to fix this issue would be handled. Since no consensus on the current vendor implementation could be reached, we submit this issue to an offline vote to have a larger number of participants.

A doodle is available to vote on your favorite resolution between:

• Correlate linkEvents using the name attribute of linkEventDefinition and remove Source and Target attributes
• Correlate linkEvents using the Source/Target attributes of linkEventDefinition and ignore the name attribute

You can register your votes here: http://www.doodle.com/shifbgzes2y9abu9. Voting close at the 2014-01-29 meeting.

[dgagne]

Posted!

From: SimonRinguette [mailto:[email protected]]
Sent: January-23-14 11:58 AM
To: bpmn-miwg/bpmn-miwg-test-suite
Subject: Re: [bpmn-miwg-test-suite] Connection of Throwing and Catching Link Events ambiguous (#141)

This discution was re-opened in the 2014-01-22 meeting. There was a feeling that we needed to make a proposal to the FTF group based on what the vendors would feel the best way to fix this issue would be handled. Since no consensus on the current vendor implementation could be reached, we submit this issue to an offline vote to have a larger number of participants.

A doodle is available to vote on your favorite resolution between:

• Correlate linkEvents using the name attribute of linkEventDefinition and remove Source and Target attributes
• Correlate linkEvents using the Source/Target attributes of linkEventDefinition and ignore the name attribute

You can register your votes here: http://www.doodle.com/shifbgzes2y9abu9. Voting close at the 2014-01-29 meeting.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/141#issuecomment-33143692.

[SimonRinguette]

On the 2014-01-29 meeting, we reviewed the polling vote from doodle (http://www.doodle.com/shifbgzes2y9abu9)

9 votes for : Correlate linkEvents using the name attribute of linkEventDefinition and remove Source and Target attributes
6 votes for : Correlate linkEvents using the Source/Target attributes of linkEventDefinition and ignore the name attribute

We will propose the corelation on linkEventDefinition name attribute to the FTF and note that a clear consensus was not reached on the issue.

[dgagne]

Changed the tag