2023-05-26: Published.
2023-08-15: Changed the article title and the content regarding correspondence in Version 15.1/16.0
(This article will be updated if there is any information regarding the discontinuation of GraalJS (Nashorn Compatible Mode) in the future.)

Questetra has two types of automated processes: Script Tasks, in which users can write their own scripts (ECMAScript) and define their own processing, and Service Tasks (Add-on), which can be imported and added to Questetra (available in Professional edition).
(The add-on automated processes include publicly available service task definitions (Addon-XML) and those created by users themselves.)

As of May 2023, the GraalJS (Nashorn Compatible Mode) (former name: GraalJS) can be used as a scripting engine in the [Script Task] and [Service Task (Add-on)], but this will be discontinued in Ver. 16.0, scheduled for release in April 2024.

If you are using GraalJS (Nashorn Compatible Mode) as the scripting engine in [Script Tasks] and [Service Tasks (Add-on)], please change to GraalJS (Standard Mode) by March 31, 2024. Please take the following action.

What is a Script Engine?
The main feature of GraalJS, as well as Rhino / Nashorn, etc., which were adopted in the past, is that the JavaScript execution engine (script engine) can access functions implemented in Java. Using this feature, [Script Task] etc. can access the workflow engine of Questetra implemented in Java by borrowing JavaScript syntax.
Although the syntax of the script conforms to the JavaScript (EcmaScript) specification, the specification of the part that can access the functions implemented in Java differs depending on the script engine. Therefore, adaptive maintenance of the scripts is required when the script engine changes.

◆ History of the discontinuation of GraalJS (Nashorn Compatible Mode) and plans for support

The most suitable script engine changes with the Java version and technology, and in the past, Questetra used the Rhino / Nashorn script engines, which were discontinued in June 2021 and April 2022, respectively.

When GraalJS was introduced in Questetra, Nashorn Compatible Mode was adopted as the GraalJS operation mode for compatibility and migration from Nashorn. Since Nashorn has since been discontinued, it is no longer necessary to use Nashorn Compatible Mode.

In Ver. 15.0 in April 2023, GraalJS (Standard Mode) will be added as a new script engine (default setting) and GraalJS (Nashorn Compatible Mode) will be discontinued.

The future schedule until GraalJS (Nashorn Compatible Mode) is completely discontinued is as follows

  • August 2023 (Scheduled: Ver. 15.1)
    • (Canceled the response to be App definition error, and added a response to output a warning to [Process Log] when updating to Version 15.1.)
    • A warning message is now recorded in the [Process Log] when “GraalJS (Nashorn Compatible Mode)” is used when executing a Process
    • If a workflow app has a process that uses GraalJS (Nashorn Compatible Mode), an app definition error will occur
      • When releasing a new version of an app, it is necessary to resolve the app definition error.
    • There is no error during process execution (workflow app processing)
      • In workflow apps already in operation, processing is performed with the GraalJS script engine (Nashorn Compatible Mode).
  • April 2024 (Scheduled: Ver. 16.0)
    • Script engine GraalJS (Nashorn Compatible Mode) is completely deprecated.
    • Script Task
      • GraalJS (Nashorn Compatible Mode) will be forced to change to GraalJS (Standard Mode)
      • Depending on the code contents, the processing result may change or the processing may fail (error).
    • Service Task(Add-on)
      • As with [Script Task], the script engine is forcibly changed
      • Script engine(<engine-type>)is not changed
      • The target process fails when the process is executed

◆ Script Task

If you are using Script Tasks, you will need to change the script engine and, if necessary, the script (code). After changing the settings, please check the operation and if there are no problems, release the new version.

◆◆ Script Engine Changes

  • Changed from GraalJS (Nashorn Compatible Mode) to GraalJS (Standard Mode)

◆◆ Script (code) Changes

In many cases, scripts that worked in GraalJS (Nashorn Compatible Mode) will work equally well in GraalJS (Standard Mode).

However, the following two changes need to be addressed.

  • If a method of java.lang.String is used for a String object
    • E.g. String#equals() Methods, etc.
  • Accessing Java objects in a manner not described in the specification
    • E.g. Error#message property, ItemView#value property, ItemView#display property, etc.

Nashorn Compatible Mode

Example of code changes
Methods derived from java.lang.String

Please do not use methods derived from java.lang.String, as the String class is moving in the direction of supporting JavaScript String.

const orgName = engine.findDataByVarName("q_org").getName(); //Organization name

if(orgName.equals("Sales Department")){ //Before change
if(orgName === "Sales Department"){ //After change
Properties not listed in the Java class specification

In the com.questetra.bpms.core.event.scripttask.ItemView class getValue() / getDisplay() methods are defined, but value / display properties are not. However, in GraalJS (Nashorn Compatible Mode) it was possible to get the Choice ID / Display Label value with item.value / item.display .

const item = engine.findDataByVarName("q_select_radio"); //choice type
let itemStr = "";

itemStr = "Choice ID:" + item.value + "、Display label:" + item.display; //Before change
itemStr = "Choice ID:" + item.getValue() + "、Display label:" + item.getDisplay(); //After change

Similarly, the Java exception object (the entity java.lang.Throwable) has no message property.
Exceptions thrown by processing Java objects become Java exception objects; when processing Java exception objects, do not access the message property. Change to use the toString() method, for example. (The toString() method is also defined in JavaScript’s Error object, so you can handle Javascript’s Error object/Java’s Exception object in the same way.)

    //Processing Java Objects
    engine.log(e.message); //Before change
    engine.log(e.toString()); //After change

◆◆ Operation Check

After changing the settings, use [Debug] or [Debug only this node] to check if the operation is as expected. If the result of the process is different or an error occurs, modify the script.

◆ Service Task (Add-on) – Service Task Definition (Addon-XML)

The service task definition file (Addon-XML) to add an add-on automated process can be registered in one of the following locations:

  • App-specific Service Task definitions
    • (App Detail screen) > ▼ App > Manage Add-on > Definition of service task
    • Requires “App Administrator” authorization for the target App
  • App-shared Service Task definition
    • System Settings > App-shared Add-on > Definition of service task
    • Requires “System Administrator” authorization

In the registered Addon-XML file, if the value of the <engine-type> element is “2” (GraalJS (Nashorn Compatible Mode)), it must be modified.

Depending on the service task definitions you are using, there are several ways to deal with this issue. Please consider the method that best fits your environment.

a. Replace with built-in automated processes (modeling elements)

If the same functionality as the service task definition you are using is provided as a built-in automated process, we recommend that you replace it with the built-in automated process in the workflow diagram.

  • R2010: List of Modeling Elements
    • Built-in automatic processes are added as needed
    • Some service task definitions that were previously published as add-on automated processes are now built-in automated processes

b. Replace with new service task definition

For some service task definitions, GraalJS (Standard Mode) compliant version ( element value is “3”) can be downloaded. If a compliant version is available for the service task definition you are using has been released, download the new Addon-XML file, update the existing add-on file or register it separately, and then replace it in the workflow diagram.

  • Service Task Definitions: Add-on Auto-Steps
    • In the obtained Addon-XML file, check that the value of the <engine-type> element is “3” (GraalJS (Standard Mode)).
    • The operating specifications in the service task definitions may undergo changes. Please check to see if they are consistent with your objectives.
    • Updating an existing service task definition file will affect the behavior of running apps
    • Addon-XML samples compliant with GraalJS (Standard Mode) will be provided only for some service task definitions.

c. Edit and update the service task definition (Addon-XML)

If it is not possible to use your own service task definition or methods a/b above, please edit and update the Addon-XML file yourself.

Script engine changes

  • Changed the value of <engine-type> element to “3” (GraalJS (Standard Mode))
    • <engine-type>3</engine-type>

Script (code) changes

See “Script (Code) Changes” in the “Script Tasks” section for instructions on how to proceed.

Changes to <last-modified>

  • (date of last update) is specified, replace the value with the newer one
    • If the last modified date is not newer than the already registered value in Addon-XML, a validation error will occur when registering an addon update.

We apologize for any inconvenience this may cause, but we would appreciate it if you could proceed with preparations for the discontinuation of the GraalJS (Nashorn Compatible Mode) script engine.

%d bloggers like this: