Insight · Platform

Scripting and Automation in Sparx EA: What’s Possible and What It Takes

By Sparx Services · October 28, 2025 · 7 min read

Architects automate in Sparx EA to take repetitive work off their week: producing the same diagrams every cycle, checking the model against team conventions, generating reports, creating elements that follow an MDG. Sparx EA has a built-in scripting and automation capability for this that most teams never fully use. You can automate diagram generation, model validation, batch reporting, element creation and custom toolbox behavior, in VBScript, JScript, or C# through the Add-In API. Scripting also requires dedicated internal capability to build and maintain. Ad hoc scripts written by one architect and abandoned when they move on create more problems than they solve.

AI-augmented work changes part of that calculation. Much of what teams once scripted, an architect can now describe to an AI that does the mechanics in the model under their review. This reference covers what the scripting engine does, where it still pays off, and where the AI-augmented route is the better fit.

What the scripting engine does

Sparx EA’s internal scripting engine is accessible via the Scripting window (Extensions › Scripting in the main menu). It supports three languages:

VBScript: the original and most widely documented option, with a large body of community examples. Synchronous, straightforward, and direct access to the EA Automation Interface. Adequate for most internal automation.

JScript: Microsoft’s JavaScript implementation, syntactically familiar to web developers, with the same Automation Interface access.

C# (via Add-In API): for production-grade automation, the Add-In framework lets you build compiled .NET assemblies that integrate directly into the EA UI: menu items, toolbox entries, ribbon controls, and event handlers. The right choice for team-wide automation that runs regularly and must be reliable.

All three reach the same underlying EA Automation Interface, a COM-based object model that exposes the full repository: packages, elements, connectors, diagrams, attributes, operations, tagged values, and constraints.

The Automation Interface: what you can touch

The Automation Interface is the key to understanding what scripting can and cannot do. Everything in the repository is reachable programmatically: repository navigation (iterate packages, find elements by name, GUID, or type, traverse the full hierarchy); element creation and modification; diagram manipulation (create diagrams, add objects, set positions and formatting, generate images); model search (run SQL queries directly against the repository database, or use EA’s built-in search with custom queries); programmatic validation; document generation; and external data access. EA scripts run in the Windows environment and can use any COM-accessible library.

What the Automation Interface does not do natively: it provides no REST endpoint, and it does not run without an active EA client session, automation scripts require EA to be open.

Practical automation that pays off

These are the four scenarios where scripting reliably removes manual effort.

Batch diagram generation

If your program produces a defined set of diagrams on a cycle, weekly architecture views, monthly change-impact diagrams, release documentation, these can be scripted to run unattended or at the click of a button, generating consistent images or documents from the current model state. It removes significant recurring effort and enforces a single formatting standard across architects.

Model validation scripts

EA’s built-in validation checks UML syntax, but real programs have conventions that go beyond it: every element of type X must have a description; every interface must have a realizing component; every requirement must trace to a design element; no package may exceed a defined element count. These rules become VBScript or C# validators run on demand or as part of a model review, with results written to a report or surfaced as EA model issues.

Automated reporting

Scripted reporting extends EA’s native document generation to scheduled or triggered runs, multi-format output (generate RTF, convert to PDF, archive to SharePoint), and data-driven reports that combine model data with external sources, for example joining EA application inventory with CMDB data from a SQL query.

Guided MDG element creation

When teams work with custom MDG Technology stereotypes, creating elements with the correct stereotype, tagged values, and parent package is error-prone by hand. Scripts can provide guided creation wizards that prompt for the required information and produce a correctly-formed element, reducing MDG compliance errors.

Integration with external data sources

Sparx EA scripts can call external web services (via WinHTTP or MSXML COM objects), read Excel files (via COM automation), query SQL databases (via ADO), and write results back to the model. Practical examples: pull application data from a CMDB API to populate EA application elements; read requirement data from a Jira or Azure DevOps export to create linked requirement elements; push EA metadata to an external register or governance tool. These integrations demand care. They write to the model and must be idempotent, well tested and documented, but they remove the manual synchronization work that otherwise falls on architects.

The Add-In API: production-grade automation

For automation that must be reliable, maintainable, and used by an entire team, the Add-In API is the right approach. A Sparx EA Add-In is a .NET DLL registered as a COM server and declared in the Windows registry. Add-Ins can add custom menu items, ribbon controls, and toolbox pages; react to EA events (element created, diagram opened, model saved); implement custom validators that integrate with EA’s built-in validation framework; add custom property pages for specific stereotypes; and generate custom diagram layouts. The development workflow is a software-engineering discipline: version control, unit testing, build pipeline, deployment packaging. Teams that approach Add-In development as “a quick script” consistently underestimate the maintenance burden.

Where AI-augmented work changes the calculation

One-off and irregular changes. Today, a bulk update to a few hundred elements means writing a script, testing it on a copy, running it and deleting it. AI-augmented, the architect describes the change, which elements, which tagged values, what the new values should be, and an AI with access to the live repository proposes the change, applies it once the architect approves, and reports what it did. There is no script left to maintain.

Validation rules. Today, team conventions become VBScript or C# validators that someone has to keep in step with the model. AI-augmented, the architect writes the conventions as rules, and the AI checks the model against them and reports the gaps. Changing a rule is an edit to the rule set rather than a code change. Automation checks completeness, people own correctness.

Diagrams and element creation. Today, consistent diagrams and correctly formed MDG elements come from scripts and wizards. AI-augmented, the architect states what each view should show and which stereotypes to use, and the AI builds the elements and lays out the diagrams for review.

The skill it asks. Stating the outcome precisely, knowing your MDG well enough to say what correct looks like, and reviewing what the AI changed before it stands. The same judgment a good script author applies, without the code to maintain.

Tools that help. AI Power Tools for Sparx EA, free from NovoCircle, lets Claude in the Claude desktop app or GitHub Copilot in VS Code work on the live repository from the architect’s Windows machine, with EA open on the same machine. Kernaro Assist from Sparx Systems works inside the EA client. Scripts and Add-Ins still earn their place for automation that must run identically every time, react to EA events, or extend the EA user interface. An AI can also help an architect write and document those scripts.

When not to automate

Scripting in Sparx EA is not always the right answer.

A VBScript file that no current team member understands is an operational liability.

Don’t automate one-off tasks: if you need to bulk-update 500 elements once, write it, run it, delete it. Don’t automate rapidly-changing model structures, scripts that rely on specific element types break when the model is reorganized; stabilize the structure first. Don’t replace native EA capabilities with custom scripts: confirm EA’s built-in document generation, model search and templates can’t do what you need before writing anything. And don’t automate without a skill owner: before committing to an automation investment, confirm that at least one person can maintain it.

The maintenance burden teams underestimate

Scripting in EA is deceptively easy to start. VBScript is accessible, the Automation Interface is well-documented, and early scripts often work quickly. The maintenance burden emerges later: EA version upgrades occasionally change API behavior; model-structure changes break element-finding logic; scripts written for one project get repurposed for another with different conventions and fail silently; and the person who wrote the script leaves the team. Any script or Add-In worth keeping needs documentation, tests against your own repository, and more than one person who can maintain it. Work an architect can describe to an AI and review avoids that burden altogether.

Frequently asked questions

What scripting languages does Sparx EA support?

The internal scripting engine supports VBScript and JScript. For production Add-Ins, compiled automation integrated into the EA UI, the Add-In API uses .NET (C# or VB.NET). VBScript is the most widely used for internal scripts because of the large community knowledge base. For any automation that will be team-wide and regularly used, the Add-In framework with C# is the appropriate choice.

Can I automate diagram generation in Sparx EA?

Yes. The Automation Interface provides programmatic access to diagrams: create them, add elements, set positions and formatting, and generate image or document output. Batch diagram generation across a portfolio of applications is one of the most common use cases. Output quality depends on how well the underlying model elements are connected; automation cannot compensate for a poorly-structured model.

What is the difference between EA scripting and EA Add-Ins?

Scripts (VBScript or JScript) run inside the EA scripting engine: quick to develop, no compilation, good for personal or team-internal automation. Add-Ins are compiled .NET assemblies that extend the EA application itself: menu items, toolbox pages, event handlers, custom UI. Add-Ins are the right choice for team-wide production automation; scripts are right for per-project or personal automation. Both access the same underlying Automation Interface.

When should a team invest in EA scripting capability?

Invest when you have a stable model structure scripts can rely on, a repeating task that consumes significant manual effort, and at least one team member who can own the scripts long-term. Do not invest in scripting as a substitute for good MDG governance, a well-structured model with consistent stereotypes and tagged values produces better results from EA’s native capabilities than a poorly-structured model with complex scripts layered on top.

Take the repetitive work off your architects’ week.

We can teach your architects to hand that work to AI on your own repository, and to know when a script is still the better tool, with mentoring until it sticks. Or we can do the work for you, including the MDG and validation rules, and hand it over.

Book a call

Keep reading