Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: peigee on November 17, 2015, 12:50:34 pm
-
The document (Introduction to Scripts) states 'Scripts are stored with the model and are organized using Groups.', therefore, I thought my added scripts would have been stored in the repository and others can see them immediately or after 'Reload Project'. However, others could not see them and it appears the scripts are stored locally within the SPARX client.
I can't see any script export/import options available. What is the best way to distribute my scripts for others to use, other than manually adding each empty script and then copy/paste the content by others?
Your advise is very much appreciated.
-
Export Automation Scripts through Export Reference Data dialog
http://www.sparxsystems.com/enterprise_architect_user_guide/12.0/projects_and_teams/exportrefdata.html
-
Thank you VKN for your promptly and helpful response. I have now managed to export the automation scripts that I assume including mine.
It appears I don't have the permission to 'Import Reference Data' as its feature greyed out. I gather most my colleagues would have the same permission issue. Wondering why this import to the client side (as I would assume) would need access control.
-
I gather the scripts are stored with the data model within the repository however under each user's workspace!?
I reckon the export/import reference data is designed for the movement between projects. I would expect there is an option for me to set my scripts to be 'shared' so others working on the same project can see them!
-
Did your colleagues try restarting EA then connect to the project?
-
No. Had only tried 'Reload Project' that I would have expected the same effect...
Will ask my colleagues to try to restart...
-
Thank you VKN for your suggestion.
After restarting EA, my colleagues can see the scripts without importing. It seems 'Reload Project' does not reload all the project data!?
-
There a special Refresh Script Tree button in the scripting view that you can use to reload the scripts
Geert
-
Thank you Geert for another useful tip.
I found out the refresh does work if the scripts are not present, however, if the scripts have been deleted or renamed, the refresh would not update the list and one could still see the deleted or renamed scripts that had been loaded earlier until restarting EA or close project and reconnect.
-
I found out the refresh does work if the scripts are not present, however, if the scripts have been deleted or renamed, the refresh would not update the list and one could still see the deleted or renamed scripts that had been loaded earlier until restarting EA or close project and reconnect.
That is really weird.
I would report that as a bug (http://www.sparxsystems.com/support/bug_report.html). I'm sure that's something they can quickly fix.
Geert
-
Hello,
The document (Introduction to Scripts) states 'Scripts are stored with the model and are organized using Groups.'
Pardon me, but what document is this? Is it in the help file, a Sparx white paper, or something from a third party? I really do want to know, because that quote seems wrong to me.
The best way of distributing scripts is to package them into an MDG Technology. This is how Sparx does it with their EAScriptLib.
With an MDG Technology, the scripts are not bound to any particular project. They are stored in a file and can be used freely in any project.
HTH,
/Uffe
-
Doesn't seem wrong to me.
If I write a script it is stored in the model and organised in groups no?
You have a point with regards to the distribution, but a big downside is that from an MDG file you get all scripts in one single standard group.
So you can't use the scripts context menu's to execute scripts (unless there's a hidden passage way I haven't discovered yet)
Geert
-
Doesn't seem wrong to me.
If I write a script it is stored in the model and organised in groups no?
When you write it, yes. But not necessarily when you use it (could be in an MDG Technology). Plus, if you save a script from the editor it gets written to disk. So the statement is incomplete or, using a couple fewer letters, wrong. :)
And since this is a deployment issue, both the writing side and the using side are important.
You have a point with regards to the distribution, but a big downside is that from an MDG file you get all scripts in one single standard group.
So you can't use the scripts context menu's to execute scripts (unless there's a hidden passage way I haven't discovered yet)
No, I haven't found one either. But it wasn't clear from the OP that this was a requirement. Which is part of the reason I asked about the source of the incorrect information he or she has been working from: if there are more errors in that document, then clearing those up might help.
/Uffe
-
The content that I had quoted is from the following document file distributed as part of EA12.0.1210 client program:
...\ProgramFilesX86\Sparx Systems\EA\Books\Automation\Scripting\Introduction to Scripts.rtf
-
Hi again,
The content that I had quoted is from the following document file distributed as part of EA12.0.1210 client program:
...\ProgramFilesX86\Sparx Systems\EA\Books\Automation\Scripting\Introduction to Scripts.rtf
Oh dear. Well I'd definitely call that plain wrong an over-simplification.
I explained the different storage locations in my answer to this SO question (http://stackoverflow.com/questions/9177115/where-does-enterprise-architect-store-user-defined-scripts) the other year. In brief, scripts can be used from the EA installation directory ("Local scripts"), from within the project itself, and from an MDG Technology.
In order to distribute scripts, you can use the Model Import/Export functions under the Project menu; importing a script this way will store it in the project, and if you want to make any changes you have to run the export/import cycle again.
An MDG Technology is an XML file, just like the result of a reference data export. The difference is that an MDG Technology can contain more than one type of thing, eg scripts, UML profiles, and document templates.
Using an MDG Technology, you can make your scripts available to the users regardless of which project they happen to be in, if they configure their EA clients to look for MDG Technologies in a shared directory. They only need to do this once. Subsequent updates requires them to restart EA (or deselect / reselect the MDG Technology, which is too complicated for some users).
It gets a little more complicated by the fact that an MDG Technology itself can also be imported to a project, or to a user's installation directory. Don't do that, use a shared directory instead.
HTH,
/Uffe
-
It gets a little more complicated by the fact that an MDG Technology itself can also be imported to a project, or to a user's installation directory. Don't do that, use a shared directory instead.
There's merit in being able to import an MDG to a model as well.
I have one client were we only limited access to things like installation/registry/configuration. (EA on citrix outsourced to a 3th party with less then ideal service)
But they do have only three models in a shared DBMS for the three major projects.
Depending on the project we want different scripts, templates and profiles to be available.
So in cases like this importing MDG in the model is the best solution.
Geert