Looking deep into the EA repository, and using the Archimate2 MDG, I discovered the following:
1 – eaDocX/Excel updates only via the API. The stereotype passed is not the FQ one. In my example, <>.
2 – the FQ one seems to live in the infamous t_xref table, as an entry which associates the object_guid with an FQ stereotype. In this case, Archimate2:Archimate_BusinessRole
3 – So when we look at the element stereotype, EA is reading BOTH tables.
4 – When eaDocX/Excel creates new Archimate stereotype elements, they seem to invent the FQ name. Maybe EA is doing this as part of the ‘createElement’ API which we use.
I’m guessing that, when EA does a ‘createElement’, it is going looking in all its MDGs, looking for one with the ‘Archimate_BusinessRole’ stereotype, and, in my case, getting just one hit, from the correct MDG.
You’re using <>, so maybe it gets more than one hit, and just picks the first one it finds.
BTW – I’m using EA 13.1.
Your only solution is to take you life in your hands, and do a change to t_xref, to change the FQ stereotype. The format of the table is truly shameful, but fairly obvious:
Description = @STEREO;Name=ArchiMate_BusinessActor;FQName=Archimate2::ArchiMate_BusinessActor;@ENDSTEREO;
Client = (your element GUID)
The programmer of this must have been SO proud….
.
