Synchronise stereotype: tagged value groups

[bITs.EA]

Hi,

When I sync my stereotypes after adding some tagged values to my MDG, the TVs aren't added in a TV group anymore. They just appear on the bottom of the TVlist.

I guess it's not possible to change this behaviour, but I would like to know where this information is stored in the database. Because new elements have the correct TV groups, while old one's don't change... So I guess the groups are stored somewhere for each element and these groups aren't changed when syncing.

So, does anybody know where the TV group info is stored??

[qwerty]

As mentioned in the other post: EA stores MDG information only in memory during runtime and does not transfer it to any database. There is no real API available to work with those data. It all goes under the hood.

q.

[bITs.EA]

But why does EA keeps grouping the tagged values in the wrong way? If it's only stored in runtime, EA should load the new MDG when I restart EA. So on startup, everything should be fine if it's only stored in runtime.

That's why I thought it is stored somewhere, because the groups are still wrong after startup...

[qwerty]

The grouping is something EA does on the fly. Whether a stereotype is related to a MDG is stored in t_xref. I wrote a bit about that in my Inside book. It's only a part of the whole truth, but maybe it will help you further.

q.

[bITs.EA]

Can the t_xref table be linked with other tables through IDs? Or is it a table which stands alone?

(I don't understand what the content of the t_xref table is and unfortunately I don't have your book...)

[qwerty]

t_xref links a lot of data and one of them are stereotypes. The link is accomplished via GUIDs. It's not so simple. So I can't post all the stuff here. But as I found it out and you have the right approach you should be able to figure it out too.

q.

[bITs.EA]

So, just to be sure I'm searching in the right direction: the xrefID corresponds with GUIDs in other tables?

[qwerty]

Yes. That's what they do.
Too fast. That's the primary key. The referencing GUID is hidden somewhere in another column. (I'm off-site.)

q.

[bITs.EA]

Then it will be the Client column (that's the only column (next to xrefID) which contains GUIDs. I'll take a look at that one!

Thanks for the info

[qwerty]

Correct. In some cases the Description also contains one ore more GUIDs. But the ClientID is the main element reference.

q.

[bITs.EA]

For those interested in this topic:

1) This query selects the xref description for all objects of a certain stereotype in a certain MDG technology: (As you can see, the t_xref.client corresponds with the t_object.ea_guid)

Code: [Select]

SELECT obj.object_id, obj.name AS ElementName, xref.description
FROM t_xref AS xref INNER JOIN t_object AS obj ON xref.client = obj.ea_guid
WHERE xref.description LIKE '%<Name of MDG>%' AND xref.name = 'CustomProperties' AND obj.stereotype = '<Stereotype>'
2) The xref.description looks like this:

Code: [Select]

@PROP=@NAME=_defaultDiagramType@ENDNAME;@TYPE=string@ENDTYPE;@VALU=UML Behavioral::Use Case@ENDVALU;@PRMT=@ENDPRMT;@ENDPROP;
@PROP=@NAME=_subtypeProperty@ENDNAME;@TYPE=string@ENDTYPE;@VALU=Partena BPMN::Activity::TaskType@ENDVALU;@PRMT=@ENDPRMT;@ENDPROP;
@PROP=@NAME=_tagGroups@ENDNAME;@TYPE=string@ENDTYPE;@VALU=Task,Measures,Loop,Project@ENDVALU;@PRMT=@ENDPRMT;@ENDPROP;
@PROP=@NAME=_tagGroupings@ENDNAME;@TYPE=string@ENDTYPE;@VALU=TitelFR=Task;TitelNL=Task;taskPriority=Task;activityType=Task;TaskType=Task;DescriptionEN=Task;DescriptionFR=Task;DescriptionNL=Task;Frequency=Measures;AverageTime=Measures;isSequential=Loop;loopCharacteristics=Loop;Status=Project;@ENDVALU;@PRMT=@ENDPRMT;@ENDPROP;
@PROP=@NAME=_tagGroupStates@ENDNAME;@TYPE=string@ENDTYPE;@VALU=Task=open;Measures=closed;Loop=closed;Project=closed@ENDVALU;@PRMT=@ENDPRMT;@ENDPROP;
3) The xref.description actually contains the properties of the <AppliesTo> in the MDG technology:

Code: [Select]

<AppliesTo>
<Apply type="Activity">
<Property name="_defaultDiagramType" value="UML Behavioral::Use Case"/>
<Property name="_subtypeProperty" value="Partena BPMN::Activity::TaskType"/>
<Property name="_tagGroups" value="Task,Measures,Loop,Project"/>
<Property name="_tagGroupings" value="TitelFR=Task;TitelNL=Task;taskPriority=Task;activityType=Task;TaskType=Task;DescriptionEN=Task;DescriptionFR=Task;DescriptionNL=Task;Frequency=Measures;AverageTime=Measures;isSequential=Loop;loopCharacteristics=Loop;Status=Project;"/>
<Property name="_tagGroupStates" value="Task=open;Measures=closed;Loop=closed;Project=closed"/>

The problem is that EA forgets to update this t_xref.description when synchronising a stereotype. So with an update script, it's easy to solve this problem.

Greets

S.

[peterc]

I know that this is an old topic, but I've just come up against this very issue - having updated the tagged values in groups, they only apply to newly created elements and does NOT modify any of the (many) existing elements.

As far as I can see, there is no direct way to access the necessary parts of the t_xref table (from SQL queries I can see that I need to modify the value for Description where the Client value matches a relevant source element GUID). It might be easier to just test the value for Description and if it matches my old value then replace it with my new value (by implication if the Description was my old list of tagged values and other bits then the GUID must reference the right kind of element). Or have I missed something that will allow access more simply?

If that is true then I think I need to form the right repository.execute command in the script to run an SQL code to modify the database - is that right and the only way?

I'm not bad at scripting, but very poor on SQL so it could be a long exercise... and the more so since I understand from other posts that this is an undocumented feature.

The last post mentioned that with an update script it's easy to solve the problem (but didn't mention how easy that script might or might not be to write).

[Uffe]

If that is true then I think I need to form the right repository.execute command in the script to run an SQL code to modify the database - is that right and the only way?

Looks like it. I've come up against this before and haven't found a non-hacky way of solving it. The tag groupings are simply not visible in the API.
Luckily, I haven't had it happen in a released-and-deployed technology so I haven't had to take any corrective action in a production environment.

The last post mentioned that with an update script it's easy to solve the problem (but didn't mention how easy that script might or might not be to write).

The script itself is trivial. In VBScript it'll look like this:

Code: [Select]

option explicit

!INC Local Scripts.EAConstants-VBScript

Repository.EnsureOutputVisible("Script")
Repository.Execute("SQL statement goes here, eg    UPDATE t_xref SET something WHERE something else")
Session.Output "Ta-daa!"
The hard part is designing the SQL statement and as I said, I haven't had the need to do one.

HTH,


/Uffe

[qwerty]

Just to go back one step: have you used Synch Stereotypes before trying some futile coding (the MDG tagged values/stereotype properties are not directly present and created by EA on demand).

q.

[peterc]

Yes I have done the sync stereotypes step - it's just that when that is done (as found out by others) it does not apply new tag grouping (all the new tags get appended on the end of existing elements, but in the correctly defined group on new elements). I just want to get it consistent for all elements, in the preferred tag groups.