Accessing Sparx API from the "outside"

[Viking]

Hello together,

I am looking for possibilities to access the Sparx API from "outside". I want to run "scripts" in Java, Visual Basic or something else (that works) and manipulate content in EA via the Sparx API. So to say I want to run a script which also could be excecuted inside EA. Most welcome would be Java inside Eclipse as container.

The database for our EA environment is MSSQL-server. I saw a lot of possiblities to access EA (e.g. Scripting Enterprise Architect, from there I used the subject-title). But these possibilities are EAP-based and sometimes I have the impression, that they are outdated (e.g. I did not find a complete example using Java API).

Are there any summaries available?

Many thanks in advance, V.

[qwerty]

As I mentioned in my book, these are just samples. I definitely can not list all existing programming languages (though I'm fluent in quite a number of them). My experience in Java is limited and at the first time writing, Java had not been supported at all for EA. But there has been an addition that shows a sample for Java too. So, what are you looking for?

q.

[Geert Bellekens]

You can. Look for examples at the VBA code in the Excel importer or the Java samples available in the installation directory.

Geert

[DarrenDickens]

I use VBA running from within Excel.

I started using that because I knew VBA/Excel rather than VBScript, JScript or JavaScript. These 3 "unknown to me" languages would have meant that I could run my scripts inside or outside EA.

However, I felt getting started with EA in VBA (a familiar environment) was more useful to me. I liked VBA's use of typing such as "Dim oAttribute As EA.Attribute" which would stop me writing stupid code trying to assign a parameter to the attribute (should have assigned it to an EA.Method). I would get a VBA compilation error rather than in VBScript (which doesn't have types) everything is a Variant and so stupid coding mistakes get hidden and pop up during testing instead. I felt I needed the hand-holding of the type system.

I have looked at Geert's examples on his website and other forums and found them very useful. Thanks Geert.

Any other language, e.g Java inside Eclipse, would not be executable inside EA. You would need to convert it to JavaScript later, much like I would have to convert VBA to VBScript. I have seen some benefits of running scripts inside EA and some outside EA. It all depends on what you want to do.

Hope that helps.

@ any guru - If I have said anything that is wrong please feel free to correct me; I'm open to being educated.

Darren

[Viking]

Thank you, DarrenDickens. Good points.

Java and JavaScript are not similar.

[Rich Anderson]

I use Visual Studio Community Edition (free) to drive EA from the outside using VB.  You could use C# if you prefer that.  I find it very good, particularly for getting things in and out of EA through Excel.   You just need to include the reference to EA from within Visual Studio and then create a simple Windows forms application to do the work.   

[Uffe]

First up, the EA API abstracts the underlying database engine. You only need to worry about that if you start issuing your own queries, and that's not related to what implementation langauge and container you use.

The EA "Object Model" API, which allows an application to access EA repositories, is available in COM (and thus .NET) and Java. The COM version is the more native one, and the Java version has in the past lagged behind in terms of feature implementation.

The Object Model API is also available to the in-EA scripting engine, which supports VBScript, JavaScript and JScript (spot the difference). An in-EA script executes in a context which includes the currently open repository, while an external application has to connect to (or create) a repository before it can do anything.

There is another API, the "Add-In Model" API. This is only available in COM, and allows Add-Ins to subscribe to events fired by the EA client. The Add-In is deployed as a DLL, and can integrate its own GUI into the EA client's.

In-EA scripts can be deployed in repositories and MDG Technologies. For other applications, you must decide on how to distribute and deploy them yourself.

If I understand the OP correctly, you're after writing a script that can be run either by the in-EA engine, or by some other, external, scripting engine like VBA or WSH. This would be difficult to achieve, since there is no simple way for the script to know which scripting engine it is being executed by. I also find it difficult to see any benefit.


Application code which accesses EA repositories can be executed in EA, or in a different framework, or as a stand-alone. The same is true for code which accesses Excel spreadsheets, PDF documents, etc. Which is appropriate depends on the situation.

I use in-EA scripts when performance is not a concern, when the application only needs to interact with an EA repository and perhaps the file system, or when there are deployment restrictions in a client's IT environment.

If there is a specific need to interact with an EA repository from within another application, I write in whatever framework that application supports (generally VBA).

For everything else, I use C# unless the client requests a Java implementation.

in VBScript (which doesn't have types) everything is a Variant

This isn't right. VBScript does have types. Variant is not the only type in VBScript, but it is the default type for variables whose type is not declared. There is nothing stopping you from declaring your variables with the correct types in a VBScript in the EA scripting engine. It's even got IntelliSense. However, it doesn't catch type-related errors for you like a proper IDE does.


Finally, throwing Eclipse into the mix never helped anyone accomplish anything. It's great if you really enjoy spending 85% of your time working on the tool as opposed to the problem, but if not, steer clear.


/Uffe

[DarrenDickens]

Firstly an aside
I don't want to start a war on whether VBScript has types or not but the following didn't work in my in-EA script

Code: [Select]

Dim myString As String
I got "Expected end of statement". I would have thought String was a simple enough type for VBScript to handle. Removing "As String" worked. I also note that "Dim myString As EA.Attribute" worked. Did I define a string wrongly? Either way, it was the "catch type-related errors" that I was after so I couldn't use VBScript.




The main point I wanted to add was that one thing that I do miss with my out-of-EA scripts is not having the ability to use Repository.Execute(sqlString) to UPDATE the underlying database tables. This seems to be an undocumented feature of EA, i.e. not in the help file but mentioned in several forums (thanks Geert). Some bits of my EA model could not be updated via the Automation interface (COM?) so I had to resort to SQL UPDATE commands. I had to run a very small in-EA script that waited for SQL UPDATE requests via a control file (and some other handshaking) that would be written to by my large out-of-EA script. One example of this problem is linking an Action to an Operation (equivalent to dragging an operation onto an action in a diagram and creating a CallOperation Action).

If someone can tell me another way of updating the SQL tables I would be interested to hear. My workaround is OK but it does require me to start the in-EA script before my out-of-EA script. Also I need to run the in-EA script each time I load a new model.

[KP]

Firstly an aside
I don't want to start a war on whether VBScript has types or not but the following didn't work in my in-EA script

Code: [Select]

Dim myString As String
I got "Expected end of statement". I would have thought String was a simple enough type for VBScript to handle. Removing "As String" worked. I also note that "Dim myString As EA.Attribute" worked. Did I define a string wrongly? Either way, it was the "catch type-related errors" that I was after so I couldn't use VBScript.

"Dim myString As EA.Attribute" isn't typing myString, it's just letting EA's intellisense know. "Dim myString As String" fails because EA's intellisense doesn't know about Strings, just the EA Object Model.

[Uffe]

If someone can tell me another way of updating the SQL tables I would be interested to hear. My workaround is OK but it does require me to start the in-EA script before my out-of-EA script. Also I need to run the in-EA script each time I load a new model.

Ouchie.

Well, Repository.Execute() is undocumented and unsupported, but I'd be surprised if it was missing altogether. There aren't two versions of the API, are there? Are you sure it's not just missing from IntelliSense in your IDE?

I seem to recall using it in an Add-In, but I may be wrong about that.

/U

[DarrenDickens]

"Dim myString As EA.Attribute" isn't typing myString, it's just letting EA's intellisense know. "Dim myString As String" fails because EA's intellisense doesn't know about Strings, just the EA Object Model.

Thanks for the clarification

[DarrenDickens]

Ouchie.

Well, Repository.Execute() is undocumented and unsupported, but I'd be surprised if it was missing altogether. There aren't two versions of the API, are there? Are you sure it's not just missing from IntelliSense in your IDE?

I seem to recall using it in an Add-In, but I may be wrong about that.

/U

Unfortunately, I guess, we'll never know from Sparx (since it is unsupported). I was just repeating other people's posts about it.

[sargasso]

Well, in a sense the way that this stuff "should" be done is through XMI.
(But then again, beware young man .. that way lies madness.  Ha ha he he ... he he .. hee .... .......................

[Eamonn John Casey]

I use SharpDevelop. Developing in C#.
My wrapper is available here:
https://github.com/EamonnJCasey/Sparx-Enterprise-Architect-Wrapper