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.
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.)
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.
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 Service Task Definition is published, download a 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)
Modifying Script (codes)
See “Modifying Scripts (Code)” in the “Script Tasks” section above for how to modify.
- 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.