Home Forums eaDocX queries Fully qualified names not supported?

Home Forums eaDocX queries Fully qualified names not supported?

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
  • #8854
    Colin Wood

    We are using an MDG that has custom stereotypes

    If I export one of these stereotypes using eaDocX for Excel, change the alias and import back to EA, the result is the alias is changed (hooray) but so is the stereotype.


    We use an MDG called ‘GAF’. I create an element, using the GAF, with stereotype ‘system’. If I query this using properties|Stereotype Selector dialogue it says its fully qualified name is GAF::system. That’s to be expected.

    If I export this element and then import it, the element stereotype is changed to some other profile stereotype with the same name e.g. UAFP:System. This causes the element to be rendered with different attributes like its shape, colour and tags.

    Notice that eaDocX also confuses the case of the same name e.g. ‘system’ and ‘System’.

    I think this may be a EA v12 to v13 issue.

    The attachment shows a before and after test on a simple model that shows the problem visually.
    The system and interface elements both get messed up.

    This is a real pain as I only found the problem out after doing an export/import on 250 elements!

    eadocX Support

    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….

    Colin Wood

    We have looked at other MDGs/Addins and they havnt anticipated this problem; they do not embed the FQN in the local name e.g. BPMN and ArcGIS so they would also have to change their stereotype names if they are to work reliably with eadocx.

    Also Ive tried changing the stereotype name in the exported eadoc/Excel from the local name to the fully qualified name, and importing back to EA. EA handles this fine so I am not convinced that eadocx is not at fault here. DO you have evidence that the API is asymmetric in handling FQNs?

    eadocX Support

    Can you send a copy of your MDG, to support@eadocx, and I’ll try to reproduce what you’re seeing.

    Colin Wood

    Please find attached MDG as requested.

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.

Compare licence prices

Choose the licence that’s right for you and your team


Download a free trial

Download eaTeamWorks today for several free for life features, plus no obligation, 30-day trials of all the products: eaDocX, ea Revision Manager, eaSheets, Model Expert and PortfolioManager. Discover for yourself why we sell the world’s best-selling Enterprise Architect extension.