Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: adepreter on May 28, 2018, 01:42:00 am
-
Hello,
We would like to DYNAMICALLY update the quicklinks in our model repository where our MDG is stored (without changing the MDG).
Does anybody know where these quicklinks are stored?
Thanks,
Alain
Why do we want to do this?
The model validation features of our addin dynamically adapts to metamodel changes without having to change anything in opur MDG.
Our formal metamodel is used 1) for model validation 2) for quicklinks generation 3) for documentation
See an example here: http://www.labnaf.one/guidance/index.html?guid=5049F7C5-210B-43b3-82BB-C6315222113A
The only thing missing to make it entirely dynamic is to update the quicklinks in the repostory when the metamodel gets changed.
We do *NOT* want to use a metamodel defined in the MDG as this is not dynamic.
-
Hi Alain,
Unfortunately, they're NOT stored in the DB!
We have a related issue. We generate the Quicklinker entries from an Excel Spreadsheet (similar to the ArchiMate relationship matrix). We have some automation to embed the new QuickLinker definitions into the MDG and then we unload/reload the MDG.
Works for us.
Paolo
-
An MDG added in the DB is stored in the t_document table (ElementID = TECHNOLOGY)
I believe the contents are stored as zipbin, you must be able to write some code to replace the <QuickLink /> content, and update the MDG dynamically.
Not sure if this is what you are after.
-
An MDG added in the DB is stored in the t_document table (ElementID = TECHNOLOGY)
I believe the contents are stored as zipbin, you must be able to write some code to replace the <QuickLink /> content, and update the MDG dynamically.
Not sure if this is what you are after.
But it doesn't help Alain. I think you still have to unload/reload the MDG to re-read the entries. We found it quicker, easier and more reliable to do it from the XML files.
Paolo
BTW: Our repository doesn't have any t_documents marked "TECHNOLOGY".
-
But it doesn't help Alain. I think you still have to unload/reload the MDG to re-read the entries. We found it quicker, easier and more reliable to do it from the XML files.
Paolo
BTW: Our repository doesn't have any t_documents marked "TECHNOLOGY".
If i choose to import the MDG to the local Database , it writes it as an entry in the t_document table.
The unload / reload was a issue, when we used to add MDGs by specifying the path in 'MDG Technologies - Advanced' window. however after we started adding it in the resource (to the repository) a restart of EA usually fixes the Quick linker.
May be i'm missing something.
-
But it doesn't help Alain. I think you still have to unload/reload the MDG to re-read the entries. We found it quicker, easier and more reliable to do it from the XML files.
Paolo
BTW: Our repository doesn't have any t_documents marked "TECHNOLOGY".
If i choose to import the MDG to the local Database , it writes it as an entry in the t_document table.
The unload / reload was a issue, when we used to add MDGs by specifying the path in 'MDG Technologies - Advanced' window. however after we started adding it in the resource (to the repository) a restart of EA usually fixes the Quick linker.
May be i'm missing something.
We're both missing something. I'm not importing into the repository as a resource (I thought this was deprecated - may be wrong). We find it faster to unload/reload than an exit of EA and restart.
-
Sorry, I meant 'Import to Model' or in Resources Window -> MDG Technologies.
-
I'm not importing into the repository as a resource (I thought this was deprecated - may be wrong).
The old version of importing to resources was deprecated. That used to break out all the parts of the technology and import them into their respective tables (e.g. profiles imported into the t_stereotypes table). The new version of importing to resources imports the whole technology file undigested, and then uses it as just another place to read technologies from at start-up. (I have no idea if what I just said makes sense)
-
I'm not importing into the repository as a resource (I thought this was deprecated - may be wrong).
The old version of importing to resources was deprecated. That used to break out all the parts of the technology and import them into their respective tables (e.g. profiles imported into the t_stereotypes table). The new version of importing to resources imports the whole technology file undigested and then uses it as just another place to read technologies from at start-up. (I have no idea if what I just said makes sense)
It does make sense, Neil,
But presumably, if we do that then EVERYBODY has to use the same version of the MDG at the same time yes? We allow multiple versions of the MDG to be "Live" at the same time. Can that still be done under the imported scenario?
Paolo
-
I'm not importing into the repository as a resource (I thought this was deprecated - may be wrong).
The old version of importing to resources was deprecated. That used to break out all the parts of the technology and import them into their respective tables (e.g. profiles imported into the t_stereotypes table). The new version of importing to resources imports the whole technology file undigested and then uses it as just another place to read technologies from at start-up. (I have no idea if what I just said makes sense)
It does make sense, Neil,
But presumably, if we do that then EVERYBODY has to use the same version of the MDG at the same time yes? We allow multiple versions of the MDG to be "Live" at the same time. Can that still be done under the imported scenario?
Paolo
Presumably you do that by having some of your people using the technology at one location and the rest using the technology at a different location? Unfortunately, for imported technologies I don't think you can switch off the internal location, so yes that's the version that everybody will get.
-
Presumably, you do that by having some of your people using the technology at one location and the rest using the technology at a different location? Unfortunately, for imported technologies I don't think you can switch off the internal location, so yes that's the version that everybody will get.
Yes, although by location I mean different URLs. I "improve" the MDG on my local hard drive. Power users get the stable development as UAT at one URL. The masses get the "approved" version at a third URL.
Paolo
-
I didn't know I would start such passionate discussion :-)
How can we wrap/unwrap the zipbin MDG content (to/from the t_document table)?
A.
-
Binary data are (usually) a zip with a single file encoded with base64.
q.
-
Thank you very much to all.
It works :-)
-
I have been looking at the ArchiMate3.xml that ships with EA v14.
It contains no QuickLink node, but instead has stereotypedrelationship definitions for the ArchiMate elements that were not in the v13.5 MDG XML:
It also has a "_HideUmlLinks" property, which seems to directly relate to QuickLinks.
Is this now how QuickLinks are defined?
I can't find anything in the documentation.
<Stereotype name="ArchiMate_BusinessActor" metatype="BusinessActor" ... strictness="profile">
<stereotypedrelationships>
<stereotypedrelationship stereotype="ArchiMate3::ArchiMate_Assignment" constraint="ArchiMate3::ArchiMate_BusinessRole;ArchiMate3::ArchiMate_Stakeholder;ArchiMate3::Business Behavior"/>
</stereotypedrelationships>
...
<AppliesTo>
<Apply type="Class">
<Property name="_defaultDiagramType" value="ArchiMate3::Business"/>
<Property name="_HideUmlLinks" value="True"/>
</Apply>
</AppliesTo>
</Stereotype>
-
Define Metamodel Constraints (http://www.sparxsystems.com/enterprise_architect_user_guide/14.0/modeling_tools/metamodelconstraints.html)
The relationships you see in the ArchiMate technology are (mostly) the ones that are defined in the metamodel diagrams in the specification. Using this method allows you to define both quicklinkers and model validation using exactly the same information.
-
Hi,
In v14 they made a change in the way the quicklinks are populated.
Before v14 you had to fill in a massive CSV file with every possible combination.
Now the quicklinks are apparently derived from the UML profile in some way.
I still have to dive into it myself but I would guess that this probably how the new quicklink works.
Geert
-
Yep.
Got this response from support:
The ArchiMate 3 MDG technology in EA 14 is using the metamodel functionality introduced in EA 14 to define quicklinks.
http://www.sparxsystems.com/enterprise_architect_user_guide/14.0/modeling_tools/metamodelconstraints.html
This method is a little less flexible than defining quicklinker rules explicitly, but allows you to model the relationships instead, and is much simpler when you have a set of stereotypes with inheritance between them. It also has the advantage that the rules you define can also be used by model validation.
Thanks!
-
The relationships you see in the ArchiMate technology are (mostly) the ones that are defined in the metamodel diagrams in the specification. Using this method allows you to define both quicklinkers and model validation using exactly the same information.
So the Archimate MDG has been built using metamodel constraints, which drive the quicklinks ?
What about the 'model validation' mentioned above? Is there a way I can validate a package for compliance to the MDG (ie Archimate) as opposed to base UML validation (using 'Validate Current Package')?
I started a post on this a few days ago if you'd rather use that to respond:
http://www.sparxsystems.com/forums/smf/index.php?topic=40041.0 (http://www.sparxsystems.com/forums/smf/index.php?topic=40041.0)
-
The relationships you see in the ArchiMate technology are (mostly) the ones that are defined in the metamodel diagrams in the specification. Using this method allows you to define both quicklinkers and model validation using exactly the same information.
So the Archimate MDG has been built using metamodel constraints, which drive the quicklinks ?
What about the 'model validation' mentioned above? Is there a way I can validate a package for compliance to the MDG (ie Archimate) as opposed to base UML validation (using 'Validate Current Package')?
I started a post on this a few days ago if you'd rather use that to respond:
http://www.sparxsystems.com/forums/smf/index.php?topic=40041.0 (http://www.sparxsystems.com/forums/smf/index.php?topic=40041.0)
I think Simon is talking about the strict connector syntax option here.
Geert
-
I think Simon is talking about the strict connector syntax option here.
Leave me with my hopes and dreams for a little bit longer ...
It feels like the framework is there for 'proper' model validation and that it should be possible. Maybe ?
-
I think Simon is talking about the strict connector syntax option here.
The same rules that drive Strict Connector Syntax are checked during model validation. So it's both.
Having said that, I know that the rules defined for ArchiMate haven't been refined as much as I would like them to be.
-
The same rules that drive Strict Connector Syntax are checked during model validation. So it's both.
So ... is there a way to do a package level model validation against a UML profile (as opposed the base UML validation which the "Validate Current Package" does) ? Specifically for Archimate ?
If so, how does one do that ... ?
-
What build of EA are you using?
Build 1422 validation reports validation errors in the same situations as strict connector syntax prevents.
-
What build of EA are you using?
Build 1422 validation reports validation errors in the same situations as strict connector syntax prevents.
Build 1420 ...
Strict connector syntax is working (mostly) as expected (there are some scenarios where I think it is valid Archimate but Sparx is saying no, need to dig into those bit further)
So - if I update to 1422 I get something different with validation ? Can you describe / explain how it works ? (is it something I control through "Configure Validation Rules" ?)
Thanks