Notice Concerning Deprecation of Nashorn (April 2022)

There are two types of automatic Steps in Questetra BPM Suite, which are: [Script Task] where you can define your own processing by writing ECMAScript codes, and [Service Task (Add-on)] which you can add to your workflow platform by importing (available for Professional Edition).
(For [Service Task (Add-on)], there are Service Task Definitions published on the Questetra site and ones to be created by users.)

As of May 2021, “Nashorn” is available in [Script Task] and [Service Task (Add-on)] as a script engine, but it is going to be discontinued in the new version 13.2 scheduled to be released in October 2021 14.0 scheduled to be released in April 2022.

Therefore, if you are using Nashorn as the script engine in [Script Task] or [Service Task (Add-on)], please proceed with the following measures by September 30.

(Regarding the Rhino script engine, it is going to be discontinued with the new version 13.1 scheduled to be released in July 2021, so please correspond by June 30th.)

The Schedule for Nashorn Discontinuation

• January 2022 (TRA: Ver. 13.3)
  • If there is a Step in which Nashorn is used in a Workflow App, an App Setting Error (workflow app definition error) will occur
    • If you want to [Release] a new version of the App, the App Setting Error must be resolved
  • It does not affect the running of the Workflow App (Process execution)
    • In the Workflow App that has already been released, the Process is executed by the script engine Nashorn
• April 2022 (TBA: Ver. 14.0)
  • Script engine Nashorn will be completely discontinued
  • Script Tasks
    • Nashorn will be forcibly changed to Graal JS
    • Depending on the code content, the processing result may change or a there may be a processing failure (error)
  • Service Tasks (Add-on)
    • No changes to the script engine
    • When the Process is executed, the corresponding Step will result in a Process failure

Script Task

Changing Script Engine

• Switch from Nashorn to GraalJS

Modifying Script (code)

Scripts that used to work in Nashorn work the same in GraalJS in most cases.
However, in a script where implicit type conversion is performed the processing result may change, or an execution error may occur depending on the content of the written code. In such cases, you will need to modify the script to explicitly specify the type.

Operational check

After changing the settings, conduct [Debug process execution] to check whether the App behaves as expected.
If the processing result is different or results in an error, modify the code.

Examples of code modifications

Data type conversion

Whereas Nashorn performs implicit (automatic) type conversions, GraalJS requires explicit type conversions (casting).
For example, if there is a part where a numerical value is specified as an argument (unknowingly) in queryParam / formParam of HttpRequestWrapper, an error will occur in GraalJS so it needs to be corrected.

const limitNum = 1000;

httpClient.begin().queryParam("limit", limitNum); //before
↓
httpClient.begin().queryParam("limit", String(limitNum)); //after

Service Task (Add-on) -Service Task definition (Add-on XML)-

Service Task Definition files (Add-on XML) have been registered in either of the following sections.

• Service Task Definition unique to Apps
  • Detail > ▼App > Manage Add-on > Definition of service task
  • App Administrator Authorization of the target App is required
• App- shared Service Task Definition
  • System settings > App-shared Add-on> Definition of service task
  • System Administrator Authorization is required

In the registered Addon-XML file, if the value of &lit;engine-type> element is 1 (Nashorn), you need to modify it.
(In cases where &lit;engine-type> is 0 or undefined, you need to as well)

There are several ways to handle the Service Task definition, so please consider a suitable method for your environment.

a. Replace with the standard Modeling Elements

If the function of the Service Task definition you are using is equivalent to a standard modelling element, we recommend that you replace it with that modelling element in the workflow diagram.

• Standard Modelling elements: R2010: List of Modelling Elements
  • More standard items are being added all the time
  • Some of the Service Task definitions which were previously published as add-ons have now become standard modelling elements

b. Replace with new Service Task Definitions

If a new version of a Service Task Definition is published, download the new Addon-XML file then update the existing add-on file, or register it separately and replace it in a workflow diagram.

• Service Task Definition: Add Automatic Processing Process (Addon)
  • In the retrieved Addon-XML file, confirm that the value of <engine-type> element is 2 (GraalJS)
  • Operational specifications of Service Task Definitions may be changed. Please check if it meets your purpose
  • If you update the existing Service Task Definition file, it will affect the operation of the running App

c. Edit Service Task Definition (Add-on XML) to update

In the case of your own Service Task Definition, or the measures mentioned in the a/b sections are not available, you should edit and update the Addon-XML file by yourself.

• Related information: M416: Create your own Auto-Step for Business Process Definitions

Changing Script Engines

• Change the value of <engine-type> element to 2 (GraalJs)
  • <engine-type>2</engine-type>

Modifying Script (codes)

See “Modifying Scripts (Code)” in the “Script Tasks” section above for how to modify.

Changing <last-modified>

• If <last-modified> (last modified date) has been configured, overwrite the value with a new one
  • If the last update date is not new, a validation error will occur when registering the updated file to the Workflow App

We apologize for the inconvenience, but we would appreciate it if you could prepare for and deal with the deprecation of Nashorn.