Questetra には、ユーザ自身がスクリプト(ECMAScript)を記述してオリジナル処理を定義することのできる自動処理工程[スクリプトタスク]と、インポートして追加することのできる自動処理工程[サービスタスク(Add-on)]があります(Professional で利用可能)。
([サービスタスク(Add-on)]には、公開されているサービスタスク定義やユーザ自身が自作したものがあります。)
2021年5月9月現在、[スクリプトタスク][サービスタスク(Add-on)]では、スクリプトエンジンとして「Nashorn」を利用することができますが、2021年10月リリース予定の Ver. 13.2 2022年4月リリース予定の Ver. 14.0 にて廃止される予定ですのでお知らせいたします。
つきましては、[スクリプトタスク][サービスタスク(Add-on)]にて、スクリプトエンジンに「Nashorn」が利用されている場合は、9月30日 2022年3月31日までに次の対応を進めていただきますようお願いいたします。
(スクリプトエンジン「Rhino」についても、2021年7月リリース予定の Ver. 13.1 にて廃止される予定です。6月30日までに対応を進めてください。)
◆ Nashorn 廃止までの対応予定
- 2022年1月(予定: Ver. 13.3)
- ワークフローアプリにて「Nashorn」が利用されている工程がある場合、アプリ設定エラー(ワークフローアプリの定義エラー)となります
- アプリの新バージョンを[リリース]する場合、アプリ設定エラーを解消いただく必要があります
- ワークフローアプリの処理(プロセス実行)には影響ありません
- 既にリリースされているワークフローアプリでは、スクリプトエンジン「Nashorn」にて処理が実行されます
- ワークフローアプリにて「Nashorn」が利用されている工程がある場合、アプリ設定エラー(ワークフローアプリの定義エラー)となります
- 2022年4月(予定: Ver. 14.0)
- スクリプトエンジン「Nashorn」が完全に廃止されます
- スクリプトタスク
- 「Nashorn」が強制的に「GraalJS」に変更されます
- コード内容によっては、処理結果が変わったり、「処理失敗(エラー)」となる可能性があります
- サービスタスク(Add-on)
- スクリプトエンジンの変更は行われません
- プロセス実行時に対象の工程は「処理失敗」となります
◆ スクリプトタスク
スクリプトエンジンの変更
- 「Nashorn」から「GraalJS」へ変更
スクリプト(コード)の変更
多くの場合、Nashorn で動作していたスクリプトは、GraalJS でも同じように動作します。
ただ、「暗黙的な型変換」が行われているようなスクリプトでは、記述されたコードの内容によっては、処理結果が変わってしまったり、実行エラーとなってしまう可能性があります。そのような場合は、明示的に型を指定するようスクリプトの変更が必要となります。
動作確認
設定変更後は、[デバッグ実行]にて、期待通りの動作をしているか動作確認を行ってください。処理結果が変わっていたり、エラーとなっていたりする場合は、スクリプトの修正を行ってください。
コードの変更例
データの型変換
Nashorn では暗黙的な(自動的な)型変換が行われていたところも、GraalJS では明示的な型変換(キャスト)が必要となります。
例えば、HttpRequestWrapper の queryParam / formParam などにて(無意識に)数値を引数に指定しているところがあれば、GraalJS ではエラーとなるので修正が必要となります。
const limitNum = 1000;
httpClient.begin().queryParam("limit", limitNum); //変更前
↓
httpClient.begin().queryParam("limit", String(limitNum)); //変更後
◆ サービスタスク(Add-on) 〜サービスタスク定義(Addon-XML)〜
サービスタスク定義ファイル(Addon-XML)は、次のいずれかの箇所に登録されています。
- アプリ固有のサービスタスク定義
- (アプリ詳細画面) > ▼アプリ > アドオンの管理 > サービスタスク定義ファイル
- 対象アプリの「アプリ管理権限」が必要
- アプリ共有のサービスタスク定義
- システム設定 > アプリ共有アドオン > サービスタスク定義ファイル
- 「システム管理権限」が必要
登録されている Addon-XML ファイルにて、<engine-type> 要素の値が「1」(Nashorn)の場合、対応が必要となります。
(<engine-type> が「0」(Rhino)、または未定義の場合も対応は必要です。)
利用されているサービスタスク定義の内容に応じて、いくつかの対応方法がありますので、ご利用環境に合った方法をご検討ください。
a. 標準アイテム(モデリング要素)に置き換える
利用しているサービスタスク定義と同等の機能が標準アイテムとして提供されている場合、ワークフロー図にて標準アイテムに置き換えていただくのが良いです。
- 標準アイテム:R2010: モデリング要素の一覧
- 標準アイテムは、随時追加されております
- 以前はサービスタスク定義のアドオンとして公開されていたものが、標準アイテムとなったものもあります
b. 新しいサービスタスク定義に置き換える
利用しているサービスタスク定義の新版が公開されている場合、新しい Addon-XML ファイルをダウンロードし、既存のアドオンファイルを更新、もしくは別途登録後、ワークフロー図で置き換えてください。
- サービスタスク定義:自動処理工程を追加する(アドオン)
- 取得した Addon-XML ファイルにて、<engine-type> 要素の値が「2」(GraalJS)となっていることを確認ください
- サービスタスク定義の動作仕様は変更となっている場合があります。目的に合致しているかどうかを確認ください。
- 既存のサービスタスク定義ファイルを更新した場合、稼働中のアプリの動作に影響を及ぼします
c. サービスタスク定義(Addon-XML)を編集して更新する
自作のサービスタスク定義や、上記 a/b の方法で対応できない場合は、ユーザ自身で Addon-XML ファイルを編集し、更新してください。
- 関連ドキュメント:M416: 業務プロセス定義で利用可能な自動工程を自作する
スクリプトエンジンの変更
- <engine-type> 要素の値を「2」(GraalJS)に変更
- <engine-type>2</engine-type>
スクリプト(コード)の変更
対応方法については、「スクリプトタスク」セクション内の「スクリプト(コード)の変更」を参照してください。
<last-modified> の変更
- <last-modified> (最終更新日)が指定されている場合、値を新しいものに書き換えてください
- 最終更新日が新しくない場合はアプリへの更新登録時にバリデーションエラーとなります
お手数をお掛けし誠に恐縮ではございますが、スクリプトエンジン Nashorn 廃止への準備・対応を進めていただきますよう、よろしくお願いします。