In my last post on scripting I was looking at using scripts as part of customising EA. When I finished the last post I was part way through my exploration of “Application Interoperability”. So let me continue, but I must warn you that in this post I won’t be covering too much that is unique to scripting, however it is nevertheless useful stuff that provides some groundwork for subsequent experiments into scripting.
Last time I looked at how a script can gain access to an application such as Excel which can operate as a COM server. My next set of experiments looked into if and how scripts could interact with code that I’d developed outside of EA, for example, a windows application or from one of my own class libraries (DLL).
To provide a sense of what I was thinking about let me use a diagram to illustrate theses and other options I am exploring. In the diagram I show EA and its repository together with several other components that may be treated within the current context as being “internal” to EA’s operating environment plus several components that clearly site “outside of the box”. I have treated everything that EA knows about including any registered AddIns as being inside, the others, which EA doesn’t know about, are outside.
To guide us through the experiments I have numbered the connections to represent each specific test; remember we are in the world of experimenting, so I am just illustrating capability, whether or not it is of any value is another story.
Overview of scripting scenarios to explore
1. Calling my Class Library (DLL) from an EA script
This is a relatively straight forward case since it is just another example where we use our script to create an application object, but in this case the object (DLL class) is one I created. Of course, there are some rules, for example when we create our class library we must:
- provide suitably accessible public methods
- our library needs to be registered as a COM object so that Windows is aware of the class when our script wants to use it.
So here is the code for my class library – very simple.
Public Class MyEACalledClass
Public Sub New() MsgBox("Hello from my DLL") End SubEnd Class
This class is compiled as a library and then registered for COM interop using regasm, this is the same way that we register an EA AddIn – see my post One of our Addins is missing for more information.
And then within our EA model we can create a script that calls this class as illustrated in the screen shot. When the script runs we get the message box that we have in the class constructor.
So we have address case 1 – now into case 2.
(2) my DLL can access EA repository
We can extend the functionality of the class library (DLL) as we wish. For example, we may want our library to perform some functions that involve interacting with the current EA repository. To do this we simply need to:
- Write the relevant EA code in our class library (linking with Interop.EA.dll)
- At run time, we need the script to pass the current EA repository object to our class library
Below is a trivial example. The setEAModel receives the current EA repository object which is stored locally and then the getEAModelInfo method interacts with EA and returns a value to the calling process, in our case as shown below a simple script.
Private myRepository As EA.Repository = Nothing
Public Sub setEAModel(pRepository As EA.Repository) myRepository = pRepository End Sub
Public Function getEAModelInfo() As String If myRepository IsNot Nothing Then Dim myInfoString As String = myRepository.ConnectionString Return myInfoString End If Return "No report" End Function
Here is an example script calling our class library and getting information back relating to the current repository.
Clearly we wouldn’t create a library to perform such a trivial task which can be done locally. However, there may be situations where you want other functions such as interacting with another application / service that cannot be done within a script, but doesn’t warrant the need to create an EA addin, and hence this could be an option.
(3) / (4) Windows application using our class library and interacting with EA repository
The next 2 examples look at using a windows application as a EA client, firstly just accessing the EA repository and then accessing and running a script.
The first test case (3) of access our own DLL is purely windows and an everyday task for windows application developers, so no more on that.
As with any other windows application you need to ensure that you include the relevant library(s) that supports interoperating with EA ( Interop.EA.dll) which exists in the EA installation directory. Then to connect to EA:
- Create a new EA.Repository object (e.g. myEARepository)
- Open your file( or EA server) using myRepository.OpenFile(filenamestring)
- Perform required functions as required.
If you are new to working with the EA API I would suggest getting a copy of Scripting Enterprise Architect by Thomas Kilian – it goes through most stuff that you may want to do when working with EA. And if that isn’t sufficient then check out Sparx Systems Automation Forum
So why would we produce a windows application as an EA client? The simple reason is that you want to provide a client that performs specific functions that do not require the use of the EA UI, for example:
- to reduce complexity for the user – I have developed clients that make it easy to work with an EA model, as illustrated below a very simple interface with an application that can be provided to new users or more specifically in my case to those resistant to starting to use EA
- to provide interaction with a 3rd party application
- to run automatically to perform some house keeping tasks on the repository – this allows the application to be scheduled with windows Task Scheduler.
BTW: In relation to working with EA I have found it really useful at time to produce a small windows application accessing EA as an external application. I have developed a small template application which provides the basic infrastructure for interacting with EA, selecting and opening a repository and providing basic element functions that I continually reuse when testing stuff.
(5) Accessing and running EA script’s from the outside
For the final experiment today, I was looking at a means for an external windows application to make a call to EA, and for EA to run a requested script for us. For example, there can be scenarios when you want to run a script on an automatic basis.
As far as I can see EA doesn’t provide a means to open EA from a command line, run a script and close. The nearest I can see is the Project Shortcut – which nearly fulfils the requirements except that it doesn’t appear to provide a means to run a suitable script of my choice. Is there a mechanism?
Well in the meantime it looks like I will have to create an application that will open my repository and execute the scripts. So how can this be done – well as I started I see it’s not a short answer so I’m going to dedicate my next post to that task, as well as look at possible interactions between EA Addins and EA scripts. I’m already writing it so won’t be long.
In the meantime I hope this was of interest.
Any queries about this or other scripting issues let me know as I could add them to my expanding list of scripting experiments.
All the best