Find in database (qea-file) the origin (profile or not) of tags at elements

[Jacob Vos]

At a DataType, I have a number of tags. Some of them are shown on the 'Element' tab of the Properties pane, some of them on the 'Tags' tab of that pane.

The ones on the 'Element' tab are there because they stem from an applied profile (which is shown at that tab).

The ones on the 'Tags' tab probably do not stem from a profile. At least: I can't see that. And if they did, I would expect them on the 'Element' tab.

Now I would like to find in the database (qea-file) what the origin of these tags is. The tags are in the table t_objectproperties. But where is stored what their origin is? I should say it should be anywhere, because otherwise how could EA determine on which tab to show the tags?

[Geert Bellekens]

That information is not stored in the model itself.
You can only find that by reading the UML profile from the MDG file.

Now there is a workaround you can try. Tagged values that are part of a stereotype have a weird pattern in their guids.

Each tagged value BPMN2.0::Activity.ActivityType has a guid that starts with the same sequence of 20 characters.

So if you find another tagged value that shares that first 20 characters with another tagged value, it is probably a tagged value that is defined as part of a stereotype.

Geert

[Jacob Vos]

Hmm, interesting. I'm going to try it next week and let you know.

Jacob

[Jacob Vos]

I did some investigation. The GUIDs have no matching part that refers to a profile. What I found is that a tag is referred to by the first 8 digits of the GUID. For example:
- Web locatie: 39D646FF
- Alternatieve naam: 4BF34B01

The 2nd and 3rd part of the GUID indicate a relation with a stereotype. For example:
- Web locatie + Domein:      39D646FF-C24E-03c2
- Web locatie + Basismodel:   39D646FF-F1D5-80f1

- Alternatieve naam + Domein: 4BF34B01-9D4E-1d9d
- Alternatieve naam + Basismodel: 4BF34B01-3E57-a43e
- Alternatieve naam + Codelijst: 4BF34B01-2995-b529 ánd 4BF34B01-D093-f5d0
- Alternatieve naam + Enumeratie: 4BF34B01-5D03-935d
- Alternatieve naam + Gegevensgroeptype: 4BF34B01-92A5-f192 ánd 4BF34B01-CDA7-f2cd
- Alternatieve naam + Objecttype: 4BF34B01-5D6D-665d ánd 4BF34B01-E42B-bbe4

... and so on

Where two different patterns are present, possibly two different profiles have been applied.

Besides these patterns that often occur there are numerous tags that have other, all kinds of patterns. Maybe these origin from even older profiles, or were added without a profile.

So based on this information I can do some reasoning like: if a pattern often occurs, the tag probably origins from the default profile we use.

So thank you so far for your help.

I also registered a topic with Sparx Support.

[Jacob Vos]

Answer from Sparx Support: whether a tagged value relates to a profile, and if so which one, can be retrieved via scripting, by getting the FQName (a read-only property) of the TaggedValue. Then you get e.g.:

Tag: Alternatieve naam - FQName: MIM BRO Grouping NL::Codelijst::Alternatieve naam
Tag: Begrip - FQName:

My next question (to Sparx Support) is: how to arrange that the tagged value 'Begrip' (in this example) will also be related to the 'MIM BRO Grouping NL' profile.