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.
(For [Service Task (Add-on)], there are Service Task Definitions published on the Questetra site and ones to be created by users.)

As of November 2020, “GraalJS”, “Nashorn” and “Rhino” are available in [Script Task] and [Service Task (Add-on)] as a script engine, but regarding Rhino, it is going to be deprecated on June 30, 2021.

The following forms of retrieving and updating process data that are available only in Rhino also will be deprecated.

  • Retrieving: data.get(“1”)
  • Updating: retVal.put(“1”, foobar)

Therefore, if you are using Rhino in [Script Task] and [Service Task (Add-on)] as the script engine, please proceed with the following measures.

The version 12.3 of Questetra BPM Suite upgraded on 18th Jan. 2021 will be configured to cause an error in Workflow Apps that use Rhino. ​An error does not affect the operation of a running Workflow App, but you will need to fix the error when releasing a new version of the App.

Script Task

Changing Script Engine

  • Switch from “Rhino” to “GraalJS/Nashorn”
  • “GraalJS” is recommended in the long term
    • Since Nashorn” is deprecated in JDK 11, Questetra also plans to do so in the near future

Changing Script (code)

If your script uses the deprecated formats for data retrieving/updating or E4X for XML processing, you will need to modify your code.

  • Change formats for data retrieving/updating
    • Retrieve: data.get(“Data definition number”)
      => engine.findDataByNumber(“Data definition number”), engine.findDataByVarName(“field name”), etc.
    • Updating: retVal.put(“Data definition number”, value in format according to data type)
      => engine.setDataByNumber(“Data definition number”, value in format according to data type), engine.setDataByVarName(“field name”, value in format according to data type), etc.
    • The formats using “field name” are recommended
    • Related information: R2301: Script Data Retrieving / Updating
  • Change XML processing

Operational check

​After changing the settings, conduct [Debug process execution] to check whether the App behaves as expected.
Even if you merely change the script engine, the operation may change depending on your code. ​If the behavior changes, modify the code.

​Examples of code changes

Here is a code example that reads the following XML in a String-type Data item and outputs the price/quantity element of the type = “Apple”.

<sales vendor="John">
  <merchandise type="Orange" price="4" quantity="6"/>
  <merchandise type="Apple" price="3" quantity="10"/>
  <merchandise type="Peach" price="5" quantity="3"/>

Before (Rhino): Formats of deprecated data retrieving/updating, E4X is used

var type = "Apple";
var xmlText = data.get("2");
var xmlObj = new XML( xmlText );

var price = xmlObj.merchandise.(@type == type).@price;
var quantity = xmlObj.merchandise.(@type == type).@quantity;

var outStr = "type: " + type + "\n" +
             "price: " + price + "\n" +
             "quantity: " + quantity;

retVal.put("0", outStr);

After (GraalJS): Formats of data retrieving/updating with Field name, XPath expression is used

const type = "Apple";
const xmlText = engine.findDataByVarName("q_xml_text");

const xpathType = "/sales/merchandise[@type='" + type + "']"
const node = xpath.findNode(xmlText, xpathType);
const price = xpath.findNodeText(node, "@price");
const quantity = xpath.findNodeText(node, "@quantity");

// Retrieve texts directly
// const price = xpath.findNodeText(xmlText, "/sales/merchandise[@type='" + type + "']/@price");
// const quantity = xpath.findNodeText(xmlText, "/sales/merchandise[@type='Apple']/@quantity");

let outStr = "type: " + type + "\n" +
             "price: " + price + "\n" +
             "quantity: " + quantity;

engine.setDataByVarName("q_xpath_output", outStr);

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 0 (Rhino), or if the element is undefined, you need to modify it.

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 the provided modelling element, we recommend that you replace it with a modelling element in the workflow diagram.

  • Standard Modelling elements: R2010: List of Modelling Elements
    • Modelling elements are added to the standard one after another
    • 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 either “1” (Nashorn) or “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.

Changing Script Engines

  • Change the value of <engine-type> element to 2 (GraalJs) or 1 (Nashorn)
    • <engine-type>2</engine-type>
  • If <engine-type> is not set, add it

Modifying Script (codes)

If your code in the <script> element uses an obsolete format for data retrieving /updating or uses E4X for XML processing, you need to modify the code.
See “Changing Scripts (Code)” in the “Script Tasks” section above for how to modify.

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

%d bloggers like this: