Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: andy__d on December 27, 2025, 02:57:59 am
-
We're new to using MDG technologies and UML profiles in our models, and have recently discovered some issues with our existing automation tools and a new data type that was created as an MDG technology.
Previously, we'd been using class objects, with stereotypes and tagged value types defined in the UML Types dialog, and have a number of automations built that, before inserting an element or tagged value, check in the database to a) validate that what's being added is valid and b) to determine the type of tagged value being inserted, to know how to insert it (i.e. if Type=Memo, add to the Notes, not the value, if Type=RefGUID, lookup the ea_guid first, and insert that, rather than the name, etc, etc). We'd been looking at the t_propertytypes and t_stereotypes tables to get this information for the automation.
What we've found, however, is that our new object type that is derived from an MDG technology does not insert stereotype names or tagged value definitions into those tables, which means that validation fails when our automation tries to manipulate these new types of objects. When creating the UML profile for these new types, I'd initially tried creating the tagged values in the UML Types dialog, and adding them to the stereotype object in my profile diagram: but, that didn't create new tagged values in the objects to which that technology stereotype was applied: so I added them as features on the stereotype element, and created dataType / enumeration objects that I associated with the features (and added the "Type=RefGuid; Values=Actor;" string that you'd normally put in the notes in the UML Types dialog into the notes of the data type, and they worked as I'd expect them to - apart from not being in the database table. I'd wondered if perhaps I'd done this wrong (the documentation was a little unclear to me - though I assume that's an understanding issue, not a documentation issue...), or whether this was expected behavior, and I was looking in the wrong place for where these stereotype / tagged value definitions appear in the database?
-
MDG technologies are stored in the xml file. The individual steroeotypes and tagged values are not stored in the database.
You will have to update your automation to parse the MDG xml instead of relying on the database to get the stereotypes and tagged values.
Geert
-
Coming at your problem from a different angle. The functionality (b in particular) you're describing seems to be redundant.
If I define a tagged value type in the UML Types dialog. Any tagged value (new or old) with that name automatically gets the type specified in the dialog. Nothing needs to be added to the notes of the tag itself to make that happen. Even the new tagged value dialog recognises that match and disables the value field.
There are factors that complicate that simple answer. Adding a AppliesTo or BaseStereotype to the definition limits where the definition can be applied and tagged values where the notes specify their own type won't get overridden.
The tagged values coming from an MDG technology stereotype work in the same way. Any attributes defined on the stereotype become properties as soon as the stereotype is applied (or element is created.) They show in the main Properties window instead of the Tags part of the same dialog and the type of control they display is specified within the MDG Technology file. (See With Predefined Tag Types (https://sparxsystems.com/enterprise_architect_user_guide/17.1/modeling_frameworks/definestereotypetags.html) for the recommended way to set that in your technology and With Predefined Tag Types (Legacy Profiles) (https://sparxsystems.com/enterprise_architect_user_guide/17.1/modeling_frameworks/definestereotypetagswithsu2.html) for the legacy method.)
All that is to say, your automation appears to be trying to duplicate functionality built-in to EA. If you're not seeing that functionality then that's the problem I would be trying to solve.