More exploring scripts – looking at application interoperability

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

Overview of scripting scenarios to explore

Overview of interoperability 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 Sub
 End 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.

Calling my own class library

Calling my own class library

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.

Calling EA from our DLL

Calling EA from our DLL

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:

  1. Create a new EA.Repository object (e.g. myEARepository)
  2. Open your file( or EA server) using myRepository.OpenFile(filenamestring)
  3. 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
Example of an EA client

Example of an EA client

  • 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



3 thoughts on “More exploring scripts – looking at application interoperability

  1. quadrabyte

    I had to solve the invocation-from-command-line problem you describe (number 5) to get my model compiler to integrate into an automated build system I was using during development of an embedded application. Here’s an extract of the interesting parts of the code (highlighted in yellow).

    This solution required some C# (along with some legacy VB code). The entry point at main() is where a C# console application starts execution. The real work of doing the model compilation happens at the bottom with oOutputLanguage.CreateDomains but could of course invoke a script instead.





    1. adrianlincoln


      I’ve been through the code extracts and not completely clear on a few items. Can you explain a bit more what the AddIn class is/does.

      It would appear that it is external to EA since I read that the EA_Connect method is making a connection to the EA Repository (as an external application) – is this correct? And you say that your line which performs the CreateDomains could be replaced to invoke a script which implies that it must be executing within EA, and that is exactly what I seek. So I am sure I am missing something from the code and/or explanation.

      Perhaps you can expand the description of the key components which will better help me understand the approach you have taken.

      Many thanks


  2. Pingback: More exploring scripts – running EA Scripts from your code | EXploring EA

Comments are closed.