AXScripting / AX Groovy (legacy scripting in Niagara AX)

The Module Matters More Than the Code

A Groovy script in an AX station is not free-standing code. The station stores the script text as a property value on a component, and that component's type resolves to a module jar installed on the host. Alongside the question of what a script does, then, sits a mechanical one that can be answered first: which module defines the component, and does an N4 build of that module exist. Module packaging also changed between the generations. An AX module shipped as a single jar, while an N4 module is split into runtime, UX and Workbench jars, so an AX jar cannot be dropped into an N4 host's modules directory and expected to resolve. This is the constraint that usually settles the migration question before anyone reads a line of Groovy.

N4 additionally enforces module signing, and later 4.x releases treat an unsigned or wrongly signed module as a load failure rather than a warning. A one-off jar built years ago by an integrator who is no longer reachable cannot be signed without its source, which means the component type is simply unavailable on the new host. Where no N4 build of the defining module exists, the script does not carry over as it stands, and the logic has to find another home in N4: a component on the Baja API, an equivalent assembled on the wiresheet, tagging and a query, or nothing at all where the equipment it served has gone.

Inventorying Scripts Without Opening Every Component

A station backup is enough to do most of the inventory offline. A bog file is a zip archive containing file.xml, so the entire station configuration, including script source held as component property values, is readable as text. Searching that XML for import statements, class names and distinctive strings finds logic faster than clicking through the nav tree, and it finds it in folders nobody remembered were there.

On a running station, a BQL query from the station root returns every instance of a component type together with its slot path, which gives the complete list rather than the list somebody remembers. BQL predicates work against property values, so the same query narrows to components whose source text contains a particular device name, point path or unit string. That is how you get from a list of scripts to a list of scripts that touch one piece of equipment.

Presence is not use. A script component can exist, hold real code, and never execute, because its inputs were unlinked, its parent folder is disabled, or its execution trigger was removed at some point nobody recorded. Check status flags and last execution time before treating a component as live logic. A count of script components overstates the amount of running logic, sometimes by a wide margin, and the difference is worth establishing before any of it is scheduled for reimplementation.

What Constrains the Migration Schedule

The conversion path has a version floor. An AX station has to be at 3.8 before the N4 tooling will convert it, so a station still on 3.5, 3.6 or 3.7 is really two pieces of work: an in-generation AX upgrade with its own module compatibility problems, and then the conversion. Third-party AX modules tend to fail at that first step rather than the second, which is a reason to do it before any date is committed to for the migration itself.

Some AX-era controller hardware cannot run N4 at any version, and for those sites the work is a controller replacement with a commissioning window and licensing attached rather than a software upgrade. The limit is the platform, not a setting: N4 expects a Java 8 class library and more RAM and flash than the JVM on those controllers was built around. No configuration moves that line.

Migration does not have to be a single cutover. An N4 Supervisor can hold Niagara Network connections to AX 3.8 stations that have not moved yet, subject to a compatible build, so controllers convert one at a time instead of all at once. A station carrying load-bearing or difficult logic can be scheduled late on purpose, so the reimplementation is checked against the original while the original is still running.

What a Rebuilt Component Breaks Downstream

Script outputs are rarely consumed only by the wiresheet beside them. History extensions, alarm extensions and Niagara Network subscriptions all reference a slot by ORD, and a history ID is assembled from the station name and the history's own name. Reimplement the logic under a different component name and the trend does not continue: a second history starts alongside the first, and anything built on the old ID stops gaining data at the changeover without reporting an error.

The cheap version of the fix is to keep the slot path and the extension names identical when the logic moves, even when the new component is nothing like the old one internally. Where a name genuinely has to change, moving the histories is separate work with its own decision about whether the old data is renamed, merged, or left in place as an archive. That decision costs more after the cutover than before it.

• History extensions on a script output: the history ID carries the point name, so a rename produces a new history rather than a continuation of the old one.
• Alarm extensions: alarm class routing and existing acknowledgment records are tied to the source, so a rebuilt source is a new source as far as the alarm console is concerned.
• Niagara Network subscriptions: a Supervisor or peer station still pointing at the old ORD resolves to a fault instead of a value, and one faulted proxy point is easy to miss on a busy station.
• Reporting and exports keyed on history ID: anything outside Niagara that pulls by ID keeps returning the old series, which reads as data that simply stopped rather than as a broken reference.