Scripts

LicenseInt4 Shield Lite (1 of 2) · Custom add-on (1)Details

Show for

Any licenseInt4 Shield Lite

Feature or limit	Int4 Shield Lite
AI assistant chat	Add-on
Test data dynamization	Included

Anything a license model does not include can be added through a custom license. The license installed for you is shown in the app under Profile → License. All features by license

Overview

The Scripts page is the catalogue of every shared, reusable script on the platform. Scripts are small, named pieces of source code — Aster expressions, XSLT stylesheets, XPath queries, Regex patterns, plus free-form JSON, XML, and Template assets — that participate in integration testing. They are typically used to transform payloads, evaluate conditions, or assemble validation logic during test-case design and execution. Scripts also power features elsewhere in the platform: an Aster script can serve as a custom validation that runs after the result comparison of a test run, or as a transformation step in a business-object action.

Aster is the platform's own scripting language, purpose-built for shaping payloads and variables during testing. It exists so that a power user can express data transformations and bespoke checks that the standard, no-code configuration cannot capture — without leaving the testing platform. One property is worth understanding before you write one: an Aster script does not, by itself, mark a test as passed or failed. Ordinarily it just shapes data, and the only way it can force a test to fail is by failing itself — a typo, an invalid operation, an undefined function, or an explicit stop in the script. The single exception is a custom validation, where the script deliberately returns a pass/fail verdict (see Tips & edge cases).

Custom validations are the place where you write arbitrary check logic that the built-in payload comparison cannot express — for example, asserting a relationship between two values, or a condition that depends on data the comparison does not look at. The script must return a truthy verdict for the test to pass, and it can also return an extra table to be shown alongside the verdict on the test-run report. An automation object can attach such a script so that the check runs automatically after the normal result comparison.

Each script has a human-readable identifier (for example, Z_MY_TRANSFORM) and is version-controlled: every edit creates a new version while preserving the previous one for history and revert. Scripts in this catalogue live in a flat, shared namespace — they are not organised in folders and they are not scoped to a project — so the same script can be referenced from anywhere in the platform that supports scripting. Scripts that belong to a specific automation object are managed inside that automation object and do not appear in this list.

From this page you can browse the catalogue, search for a script by ID or description, open a script to view or edit it, create a new one, or check where an existing script is referenced before changing or removing it. Four of the seven script types (Aster, XSLT, XPath, Regex) can be executed directly; the remaining three (JSON, Template, XML) are stored as versioned text assets that other parts of the platform consume.

Beyond custom validations and business-object actions, Aster scripts are also used to compute or extract business dimension values, as script-based find expressions on automation objects, and as steps in Messenger flows. An Aster script can remember values between runs — counters, document numbers handed from one test to the next — in the Data Store.

Opening a script shows the script editor: the source code, an optional sample-data pane, and the Output and Messages panes, so you can write a script and try it against real test data on the same screen.

Tasks

How to create a script

1. Click Create New in the toolbar.
2. In the header bar of the editor, enter the Script ID (up to 100 characters — a short, recognisable name such as Z_MY_TRANSFORM is recommended), an optional Description, and pick the type from the drop-down list. Optionally add Tags.
3. Write the source code in the Source pane. For Aster, the editor suggests function names as you type and shows a short description when you point at a function.
4. Click Save. The script is created at version 1 and the editor switches to view mode. Run becomes available once the script has been saved.

Script IDs must be unique across the shared catalogue. If another script already uses the ID, the save is refused.

How to edit a script

1. Open the script and click Edit (or click the script ID in the header bar).
2. If other scripts reference this one, the Script in use dialog lists them first. Changes take effect for all of them immediately; click Edit to continue or Cancel to stay in view mode.
3. The header bar shows Editing mode. Change the source, ID, description, type or tags as needed.
4. Click Save. Every save creates a new version; the previous version is kept. Cancel discards your changes.

How to test a script against sample data or a test case

1. Open the script. In edit mode you can test your unsaved changes; in view mode the saved version runs.
2. Provide input:
   • For XSLT, XPath and Regex scripts, paste or type input into the Sample Data pane. To use a stored payload instead, pick a Test Case and click Load Input or Load Output, then choose the message part to load. If the sample-data pane is empty, the selected test case's input payload is used.
   • For Aster scripts, pick a Test Case in the header bar. The script can then read that test case's payloads and business dimension values.
3. Click Run.
4. Read the result in the Output pane. When an Aster script returns a custom-validation result, the pane shows the validation table as it would appear on the test-run report.
5. Check the Messages pane for log output, warnings and errors. Lines with an error are underlined in the source; click the line reference in a message to jump to it.

Running a script from the editor never saves it, and the run itself is not recorded.

How to check where a script is used

Scripts can call other scripts with INCLUDE('...') or LOAD('...'). Check the callers before you rename, rewrite or delete a script.

1. Click a row in the list to select it.
2. Click Where Used in the toolbar.
3. The dialog lists every other script whose source names the selected script. Click a script ID to open it. If nothing references it, the dialog reads This script is not referenced by any other scripts..

The same list appears when you start editing or deleting a referenced script.

How to delete a script

1. Open the script in view mode and click Delete.
2. The confirmation dialog lists the scripts that still reference this one. Deleting is allowed even when the list is not empty — those scripts will fail the next time they run, so update them first.
3. Click Delete to confirm. The script and all its versions are removed.

How to apply an AI assistant suggestion

If your licence includes the AI assistant, you can ask it to write or change the script you have open.

1. Open the script and switch to edit mode — suggestions apply only while you are editing.
2. Ask the assistant for the change. Its proposal appears in the source pane as a highlighted difference.
3. Accept or reject the proposal in the assistant chat. While a proposal is pending, Save, Cancel and Run are disabled.
4. Save the script as usual.

Field reference

List columns

Column	Description
Script ID	The identifier of the script, unique within the shared catalogue. Any text up to 100 characters is accepted; stick to letters, digits and underscores, because other scripts reference this one by quoting its ID.
Type	The kind of script (see the table below).
Description	Short label describing what the script does. Optional, up to 500 characters.
Tags	Tags assigned to the script. Use Filter by tags... to narrow the list.
Version	The current version number. It increases by one with every save.
Last Modified	When the current version was saved, shown as a relative date (for example, "3 days ago").
Modified By	The user who saved the current version.

Use Search scripts... to find scripts by ID or description. The list can be exported from the toolbar.

Script types

Type	Can run in the editor	Typical use
Aster	Yes	Transformations, calculated values, custom validations, business dimension processing, Messenger flow steps.
XSLT	Yes	XSLT 1.0–3.0 stylesheets that transform an XML payload. Aster scripts can also load and apply them.
XPath	Yes	XPath queries; the run returns every matching node or value.
Regex	Yes	Regular expressions; the run returns every match.
JSON	No	Versioned JSON text kept for reuse.
XML	No	Versioned XML text kept for reuse.
Template	No	Versioned free text kept for reuse.

Tips & edge cases

• Scripts are never edited in place. Every save creates a new version and keeps the previous one. The list and the editor always show the current version.
• Two people editing the same script overwrite each other. The last save wins; both saves become versions. Agree on who edits a shared script.
• Renaming a script can silently break callers. Other scripts call this one by its script ID. If you change the ID of a script that others INCLUDE or LOAD, those callers fail the next time they run. Use Where Used first.
• "Where used" only knows about other scripts. Custom validations, find expressions and business dimension settings on automation objects, business-object actions and Messenger flows that use the script are not listed, and they do not stop a delete. Check those configurations before removing a script.
• "Where used" is text-based. The platform looks for INCLUDE('name') or LOAD("name") in script source. A script ID that appears in a comment still counts as a reference; an INCLUDE whose name is put together while the script runs is not detected.
• Pick clean script IDs. IDs with quotes, parentheses, brackets, dots or other special characters can break INCLUDE/LOAD calls and make Where Used report wrong results or fail.
• Syntax errors show up when you run, not when you save. Run the script once before saving important changes.
• Runs are time-limited. A run from the editor is stopped after 60 seconds, and an Aster script has a 30-second budget plus limits on loop iterations and on the size of the data it builds. Only a few scripts can run at the same time across the installation; if you see a message that too many scripts are running, try again a moment later.
• In the editor, an Aster script has no "current message". Functions that read the message being processed by a test step return nothing when you run from the editor. Select a test case and read its payloads instead.
• Aster scripts can call the platform's AI model. The LLM_BASIC_REQUEST function sends a one-shot prompt to the configured AI provider and returns the response text. It works only when your licence includes the AI chat feature; otherwise the script stops with an error. A slow provider slows the script down.
• Aster scripts can use the Data Store. The DS_* functions read and write values in Data Store buckets. They need the test data dynamization licence feature and permission on the bucket's project scope.
• Aster scripts can act as custom validations. A script whose result is a two-element array — a pass/fail verdict followed by a table in JSON form — is recognised as a custom validation. The verdict decides pass or fail; the table is shown on the test-run report. Running such a script from the editor previews the table.
• A script can be shared or local to one automation object. The scripts in this catalogue are shared across the whole platform. An automation object can also own local Aster scripts, which are edited inside the automation object. Local scripts never appear in this list or in global search; script pickers on that automation object offer them marked Local.
• Three types are not executable. JSON, XML and Template scripts are stored as versioned text; running one reports that the type is not executable.
• Version history is kept but not shown here. Earlier versions are preserved, but this page has no history view, revert or copy action. To start a variant of a script, create a new script and paste the source.
• The catalogue is global. There is no folder or project scoping for shared scripts; everyone with Script: Read sees the same catalogue. A prefix convention (for example, Z_TEAM_…) helps avoid collisions.
• Scripts are trusted code. A script runs with the permissions of the person or test run that executes it. Grant Script: Execute and Script: Write only to people you trust to write automation code.

Related features

• Automation Objects — attach scripts as custom validations, find expressions and business dimension processing; manage local scripts.
• Business Objects — use scripts as transformation steps in actions.
• Data Store — buckets that Aster scripts read and write with the DS_* functions.

Prerequisites & permissions

About permissions. What you can see and do is decided by the roles assigned to your user. Each role bundles permission groups, and each permission group allows activities — Read, Write, Delete, Execute and, for schedules, Change owner — on a kind of record (for example Test Case, Automation Object, System Under Test). A role grants its groups per project scope, so you may be allowed to change records in one project but only view, or not see, those of another.

If a button is disabled, a page says you don't have access, or a list comes back empty, missing permissions are the most likely cause — or, for whole product areas, the installed licence. You can review your own access under Profile → My access; an administrator can change your roles under IAM → Users.

Specifically for this page:

• Seeing the list and opening a script requires Script: Read.
• Creating, editing and saving a script requires Script: Write.
• Deleting a script requires Script: Delete.
• Running a script requires Script: Execute. A script that includes other scripts also needs Script: Read; one that reads a test case needs Test Case: Read in that test case's project scope; one that uses the Data Store needs the matching Data Store entry permission on the bucket.

Shared scripts are not scoped to a project or folder — anyone with Script: Read sees the entire catalogue.

Was this page helpful?Send a quick note to the documentation team.

0 / 2000 characters