Script Engine

inSCADA JDK21 ships two distinct scripting environments: server-side (ins.*) and client-side (Inscada.*). They run in different places, target different use cases, and expose isolated API surfaces.

Two Separate Worlds

	Server-side (ins.*)	Client-side (Inscada.*)
Where it runs	inSCADA server (JVM)	Browser (browser JS)
Engine	GraalJS (Nashorn-compat)	The browser’s own engine
Binding	ins (global)	new InscadaApi(projectName)
Purpose	Automation, calculation, alarms, scheduled work	User interaction, UI control
Typical usage	Scheduled scripts, variable / alarm / log expressions, MQTT parsing	Animation click, custom HTML widgets, dashboard widgets

→ Server-side (ins.*) details → Client-side (Inscada.*) details

Where Scripts Run

Scripts fire in many places across the platform. The table below shows the environment each one runs in.

Context	Environment	Trigger
Scheduled Script	server (ins.*)	Periodic / Daily / Once / manual
Variable Expression	server (ins.*)	Automatically on poll cycle
Alarm Expression	server (ins.*)	Automatically on value change
Log Expression	server (ins.*)	Automatically on poll cycle
MQTT Subscribe/Publish	server (ins.*)	On every MQTT message
Animation Expression	server (ins.*)	On UI update (remote)
Animation Click Script	client (Inscada.*)	User click
Custom HTML Widget	client (Inscada.*, sandboxed iframe)	Inside the widget
Dashboard Widget	client (Inscada.*)	Dashboard render / interaction

Which one should I pick?

Reading/writing values, firing alarms, doing scheduled calculations — server-side (ins.*). Showing a popup to the user, SVG zoom, swapping animations — client-side (Inscada.*). To combine them: the client’s mirror methods call their server-side counterparts asynchronously.

Sandboxing and Security

Scripts run in isolation in both environments, but the constraints differ:

• Server side — HostAccess.EXPLICIT: only Java methods annotated @HostAccess.Export are reachable. eval and with are disabled, host class lookup is blocked entirely (so Java.type(...) and the java.* namespace are unavailable), and there are no threads, native access, process creation, environment access or guest file I/O.
• Client side — custom HTML widgets run inside a sandboxed iframe; they reach the host page API through InscadaBridge using origin-validated postMessage.

The two server-side limits

Limit	Default	What it bounds
Statement count	100,000 per run	A runaway loop. while(true){} is stopped in milliseconds
Execution time	5 minutes	A run that is stuck rather than looping — a host call that never returns

The statement limit is the one authors actually meet, and it does not arrive as a normal error: the engine cancels the context rather than throwing something catchable, so your own try/catch cannot absorb it and carry on.

A script that walks every sample will cross the line eventually

A report datasource that loops over logged values spends roughly five or six statements per sample, so it crosses 100,000 once enough history has accumulated — it passes in test with a few hundred samples and fails months later in the field. Raising the limit moves the wall rather than removing it. The way out is a call that aggregates on the server, or paging with an early exit.

Write control sequences so they can be re-run

The execution timeout kills the run. A script that writes to devices can therefore be stopped part-way through a sequence, so do not rely on a multi-write sequence completing as a unit — make such sequences idempotent.

On the client side there is no such budget; avoid code that freezes the browser tab.