BPMN quicklink broken if another MDG defines a stereotyped relation

[Geert Bellekens]

We have our own MDG that extends ArchiMate, and defines a number of relations between our stereotypes and other elements.
One of those is a stereotype that has a steretotyped relationship to BPMN2.0::Activity with the stereotype ArchiMate3::ArchiMate_Serving.

This works perfectly fine for our architecture models. We can use the quicklinker to add this relation to the model.
The problem is that simply defining these stereotyped relations in our MDG somehow breaks the quicklinker in the standard BPMN 2.0 diagram.

When I use the quicklinker from an activity I only the dependency as an option, and not the standard BPMN relations.

Removing my MDG that defines the stereotyped relationship restores the standard quicklink behavior

Reported

Geert

[Geert Bellekens]

Weird enough this is not an issue when I use a metarelationship with metaclass Realization.

So that became our workaround.

Geert

[Eve]

The problem is that the BPMN technology still uses the CSV to define the quicklinker.

To aid in migration, the model based definition overrides the CSV when it's defined.

The UML relationships don't do the same thing because the stereotypes are explicitly overriding the UML based relationships.

[Geert Bellekens]

The problem is that the BPMN technology still uses the CSV to define the quicklinker.

To aid in migration, the model based definition overrides the CSV when it's defined.

The UML relationships don't do the same thing because the stereotypes are explicitly overriding the UML based relationships.

I understand that, but that mechanism should never allow another MDG to break existing fucntionality.

Do you have any idea when the CSV will be replaced by metamodel relations? In this CSV these relations are only allowed on BPMN2.0 diagrams. That makes it impossible to make your own version of a BPMN diagram in your own MDG.

Geert