Book a Demo

This webinar has completed, the recording will be posted shortly.


Enterprise Architect implements a flexible and easy to use scripting capability based on industry standard Javascript, Microsoft JScript and VBScript. Geert Bellekens, owner of and Sparx Systems partner will demonstrate how automation can save hours of your time.

In this webinar you will learn how to:


Don't miss this opportunity to learn more about Enterprise Architect

Session 1

Melbourne Thu 07 May 08:00 am
New York Wed 06 May 18:00 pm
Los Angeles Wed 06 May 15:00 pm
London Wed 06 May 23:00 pm
Auckland Thu 07 May 10:00 am

Session 2


Geert Bellekens Bellekens IT

Explore the webinar resources

Example model: EAExample.eap Download links

Questions & Answers


Enterprise Architect 12 (Build 1213).

Yes. Scripting has been available in every version of Enterprise Architect since Enterprise Architect 7.5, Corporate Edition or higher.

Read the Enterprise Architect User Guide for more information about Automation and Scripting.

Yes. Click the link above to download the scripts.

Yes. Click the link above to download the scripts.

The EAExample model was used throughout the webinar. This model ships with every copy of Enterprise Architect.

Automation API support included to allow custom extensions for other frameworks and export formats.

Executing Scripts

Sparx: Yes. You would have to write an executable that can be run as a scheduled task by Windows. Read the Community Site article to learn more information on running scheduled scripts in Windows Server.

Geert: See EA-Matic and its open source code on Github for an example.

Yes. The webinar demonstrated how a script could be applied to several diagram elements.

Yes. You can include and execute scripts from other scripts using the !INC statement.


Security, Sharing and Version Control

You can use security to allow or disallow Workflow Scripts, but unfortunately this is not available for Standard Scripts. Review the Enterprise Architect User Guide for more information on Workflow Scripts.



However, scripts can be included with MDG Technologies to prevent users from modification. Read the Enterprise Architect User Guide to learn more about adding Scripts to an MDG Technology file.

It is probably best to organize that outside of EA using a version control system of some kind.

There is currently no integration with a version control system for scripts. Any version control will have to be done manually.

The scripts created in the webinar are stored in the model and available only in that model. You can export them and import them into another model in order to use them there as well as shown in the webinar.
Other options for sharing scripts amongst different model is storing them as a local script by saving the file in the appropriate folder:
<EA Installation Folder>\EA\Scripts.

You can also save scripts in an MDG technology file and distribute them that way.

No. You can test the elements stereotype in the script and react appropriately.


The API is documented in the help file. See section Automation and Scripting | Enterprise Architect Object Model | Reference

Scripting Language Support

The selection of a scripting Language was a matter of personal preference.




With the "context" script groups you can limit the menu's to Element, Package, Diagram or Connector. If you need more fine-grained control you can consider writing an add-in or using the third party add-in EA-Matic written by Geert Bellekens.

You'll have to work bottom up using EA.Element.ParentID , EA.Element.PackageID and EA.Package.ParentID
something like:

function getQualifiedNameElement(element, fqn)
'add my name to the fqn
fqn = & "/" & fqn
'first check if this element is nested under another element
if element.ParentID > 0 then
dim parentElement as EA.Element
set parentElement = Repository.GetElementByID(element.ParentID)
fqn = getQualifiedNameElement(parentElement, fqn)
'no parent element, so we go to the package
dim parentpackage as EA.Package
set parentPackage = Repository.GetPackageByID(element.PackageID)
fqn = getQualifiedNamePackage(parentPackage, fqn)
end if
'return fqn
getQualifiedNameElement = fqn
end function

function getQualifiedNamePackage(package, fqn)
'add my name to the fqn
fqn = & "/" & fqn
if package.ParentID > 0 then
dim parentpackage as EA.Package
set parentPackage = Repository.GetPackageByID(package.ParentID)
fqn = getQualifiedNamePackage(parentPackage, fqn)
end if
'return fqn
getQualifiedNamePackage = fqn
end function

Yes. On the Project Interface there are operations like ImportDirectory() and ImportFile() that can be used to reverse engineer from code.

Yes. For a simple run of a report, read the Enterprise Architect User Guide topic on RunReport. Note that setting the Filename extension (.rtf or .pdf) sets the output type. For a more complex scenario there is the Document Generator Class available to do specific scripted reporting.

Project.RunReport(PackageGUID, "Diagram Report", "C:\Temp\MyDiagrams.pdf")

Or export each individual diagram to a separate PDF using Diagram.SaveAsPDF.

You can find examples in


There is a wide variety in use cases. Typically we see thing like

  • Model maintenance - Scripts to do some cleanup in the model
  • Helper functions - Scripts that help the user to do a complex or time consuming action.
  • Import/Export - Scripts that import or export stuff to and from the model
  • � and a lot more ...

You can use Repository.GetContextItemType() to determine the type of the object in context.


Geert: Yes, you can use the Excel API to create an excel file from within a script. Or you could do it the other way around and write a VBA script in Excel and then use the EA API from within Excel. An example of such an Excel file importing elements into EA is available for free on

Sparx: MDG Integration for Office is designed to integrate with the Microsoft Office and Visio Suites. Import documents and spreadsheets into Enterprise Architect, providing a rich modeling experience. Learn more about MDG Integration for Microsoft Office and an interface with Microsoft Project.

This is standard VBScript syntax for checking if an object is initialized.

  • Do not write a huge script and only start testing it when it is finished. Instead write small bits and test them while progressing. Debugging large scripts is very hard.
  • Do not attempt to iterate the whole model in your scripts. Iterating is slow, and if you iterate the whole model that can easily take minutes or even hours for a big model. Instead use Repository.SQLQuery() to find the id's of the elements you need and instantiate them using Repository.GetElementByID()

There is an example script in the Local Scripts that deals with tagged values. VBScript - Element Extras Example

share this page share by email share on linkedin share on X share on facebook