ワークフロースタジオ フロー、サブフロー、およびアクションに関する一般的なガイドライン

ワークフロースタジオ コンポーネントをより効果的に作成、実行、トラブルシューティング、および監視します。これらのガイドラインを使用して、ワークフロースタジオ コンポーネントのパフォーマンスを最適化します。

ワークフロースタジオ の概要

ワークフローの作成、構成、および監視を単一のページエクスペリエンスに統合します。プレイブック、フロー、アクション、ディシジョンテーブル、統合を 1 つの設計環境に統合します。

アプリケーション開発

アクションまたはフローを設計するときは、次の一般的なガイドラインに従います。

標準の ServiceNow AI Platform アプリケーション開発機能を使用して、ワークフロースタジオのコンテンツを作成、管理、保護、および展開してください。フローデザイナーおよびアクションデザイナーは、通常は次のアプリケーション開発タスクを実行します。

• フローやアクションを格納するカスタムアプリケーションを作成します。
• アプリケーションのアクセス許可を設定して、アプリケーションデータへのアクセスを共有または制限します。
• ワークフロースタジオへのアクセスをアプリケーション開発者に許可します。
• カスタムアプリケーションをアプリケーションリポジトリに公開して、フローやアクションを他のインスタンスに展開します。

フロー

フローは、短いモジュール型の再利用可能な作業の集合にする必要があります。実行に 1 時間以上かかる場合は、長すぎる可能性があり、より効率的にすることができます。

フローに適用される一般的なガイドラインはすべてサブフローにも適用されます。

競合するビジネスロジックや重複するビジネスロジックを回避する

自動化は、フローデザイナー、ビジネスルール、ワークフロー、および統合ハブを使用して作成できます。ワークフロースタジオ の使用を開始する前に、既存の ServiceNow AI Platform の自動化がどのように機能するかを理解してください。ワークフロースタジオ フローおよびアクションに置き換える前に、自動化を無効にします。「アーキテクチャの概要」を参照して、ワークフロースタジオ が ServiceNow AI Platform 内でどのように機能するかを確認してください。

必要に応じて、フロー、サブフロー、およびアクションのドキュメントを確認してください。

フローにトリガーまたは変数の入力が必要かどうかを判断する

フローは常にトリガー条件が満たされたときに実行され、トリガーは常にフローの入力として同じデータを提供します。フローを開始するために代わりに変数の入力が必要な場合は、サブフローを作成します。

ビジネスロジックを再利用する

一連の再利用可能な操作をサブフローとして作成し、それを複数のフローで使用できます。

ロールで保護されたデータにアクセスしてユーザー情報を保持するにはフローロールを付与

フローロールは、フローの権限をシンプルに保つのに役立ちます。システムユーザーとしてフローを実行する代わりに、フローロールを使用してユーザー情報を保持し、データへのアクセスを許可します。フローロールを追加すると、ユーザーが開始したフローに通常含まれない追加のデータにアクセスすることもできます。付与されたロールはフローにのみ適用されます。フローを開始したユーザーには適用されません。

フローのタイミングを制御するにはフローロジックまたはスケジュールベースのトリガーを使用

フローロジックまたはスケジュールベースのトリガーは、フローのパフォーマンスを最適化するのに役立ちます。フロー内で待機するために、gs.sleep() メソッドを使用しないでください。gs.sleep() メソッドを使用すると、スレッドで他の作業を実行できなくなります。特定の時間にフローを実行するには、スケジュールベースのトリガーを使用します。特定の期間フローを一時停止するには、[期間が終わるまで待機] または [条件待ち] フローロジックを使用します。

依存関係を回避する

ブランチが別のブランチからの出力を待機する必要がある場合、互いに依存する並列ブランチはフローを停止します。フロー内で並列ブランチを作成する代わりに、サブフローを呼び出して結果をメインフローに返します。

スコープループカウンター

スクリプトループには最大反復数がないため、有効な終了条件がない場合はループが無限に実行されます。

有効な終了条件があることを確認するには、インラインスクリプトまたはアクション内のスクリプトステップでスコープループカウンターを使用します。for (i=0; i< length; i++) :for (var i=0; i< length; i++) に var を追加します。

For Each および Do Until ループの反復回数を 1000 に制限

1000 以上のループがある反復では、実行の詳細とコンテキストレコードを保存する必要があるため、メモリの問題が発生する可能性があります。

• [レコードを検索] の最大レコード数を設定します。
• プロパティ sn_flow_designer.max_iterations は変更しないでください。デフォルトは 1000 です。
• ネストされたループの場合、各ループには独自の最大反復回数があります。
• 大量のデータ処理の場合は、小さなバッチに分割することを検討してください。
• 一括インポートの場合は、同時インポートを検討してください。

実行を高速化するための QuickAPI の使用 (ビジネスルールの代替)

• QuickAPI は非常に高速に実行されますが、デバッグ機能は少なくなります。
• フォアグラウンドの QuickAPI 実行は、フローを呼び出したユーザーとしてユーザーセッションで実行されます。
• バックグラウンドの QuickAPI 実行は、バックグラウンドスレッドで実行され、「システム」ユーザーセッションで実行されます。

フロー自体からフローを呼び出す代わりに Do Until ループを使用する

フローがフロー自体を呼び出す直接再帰は許可されず、エラーが発生します。フロー A がフロー B を呼び出す間接再帰は、フロー A を最大 3 回まで呼び出すことができます。フローを再帰的に呼び出す代わりに、 Do Until フローロジックを使用して、特定の条件が満たされるまでレコードの作業を続行します。

バックグラウンドでフローを実行する

バックグラウンドでフローを実行すると、フローの実行が完了するまでユーザーセッションを一時停止することなく、UI スレッドを解放できます。デフォルトでは、フローはバックグラウンドで非同期的に実行されます。バックグラウンドでフローを実行すると、フローの実行中にユーザーが UI で作業を続けることができます。

大きな出力を収集した後に待機するフローロジックを回避する

大きなペイロードを取得した直後に使用すると、メモリの問題を防ぐことができます。大きなペイロードをメモリに格納する代わりに、ペイロードを処理するアクションを追加します。取得されたペイロードを早く処理するほど、システムは他のアクションを処理するために早くメモリを解放できます。

環境間の切り替えを最小限に抑える

フロー内のインスタンスと MID サーバーのステップ間で切り替えを頻繁に行うと、処理が遅れる可能性があります。遅延のリスクを最小限に抑えるには、インスタンスと MID の切り替えを 1 回のみに制限します。

フローによって生成された sys_complex_object レコードを更新セットに含める

複雑なデータスキーマが見つからないと、実行の問題が発生する可能性があります。フローによって生成された sys_complex_object レコードを更新セットに含めたことを確認してください。更新セットを手動でビルドするのではなく、アプリケーションリポジトリを使用して 1 つのインスタンスから別のインスタンスにフローを転送することを検討してください。

カスタムトリガーが必要な場合はスクリプトからフローを呼び出す

ビジネスニーズを満たす既存のトリガーがない場合は、カスタムトリガー条件が満たされたときにフローを開始するスクリプトを作成できます。不要なトリガーを使用するフローを作成するのではなく、トリガーのないサブフローを作成することを検討してください。スクリプト条件が満たされた場合にのみ、スクリプトを使用して必要なサブフロー入力を提供します。フローではなくサブフローを呼び出すことで、フローのトリガー条件が満たされてフローが予期せず実行される可能性を回避できます。

古いリリースのインスタンスに新しいリリースのフローを展開することは避けてください

ワークフロースタジオ では、以前のリリースで実行されているインスタンスへの新しいリリースフローの展開はサポートされていません。

危険:

フローデータモデルはリリース間で変更される可能性があるため、新しいフローが実行されなかったり、以前のリリースのインスタンスで実行したときに予期しない結果が生じたりする可能性があります。展開する前に、同じリリースバージョンになるようにインスタンスをアップグレードしてください。

本番環境でフローレポートをオフにする

フローレポートを無効にして、フローの実行に必要なメモリ量を最小限に抑えます。フローレポートには、[実行の詳細] ページの構成とランタイム情報が保存されます。これらのレポートはトラブルシューティングに役立ちますが、メモリとデータベースの両方に大量のデータを保持する必要があります。デフォルトでは、フローレポートは無効になっており、フローまたはアクションを手動でテストする場合にのみ実行の詳細が生成されます。代わりに、レポートをオフにしているときも使用できるログファイルを使用できます。

ネストされたループを使用してフローで消費するメモリ量を削減する

レポートが有効になっている場合は、com.snc.process_flow.reporting.iteration.lastn を値「1」に設定して、前のループ反復で消費されるメモリ量を減らします。レポートする反復が多いほど、より多くのメモリが必要になります。

サブフロー

フローに適用される一般的なガイドラインはサブフローにも適用されます。

フローの代わりにサブフローを使用する理由は次のとおりです。

フローにトリガーまたは変数の入力が必要かどうかを判断する

フローは、トリガー条件が満たされたときに常に実行されます。トリガーは常にフローの入力として同じデータを提供します。フローを開始するために代わりに変数の入力が必要な場合は、サブフローを作成します。

ビジネスロジックを再利用する

一連の再利用可能な操作をサブフローとして作成し、それを複数のフローで使用できます。

呼び出しごとに異なる入力値を設定する

サブフローを呼び出すたびにサブフローの入力値の設定を変えます。たとえば、さまざまなレコードタイプを実行の入力として受け入れるようにサブフローを設計します。レコードタイプごとに特定のフローを書き込む代わりに、この汎用レコードサブフローを再利用します。

大規模なフローのパフォーマンスと読みやすさを向上させる

フローが 25 アクションを超える場合は、サブフローを使用します。sn_flow_designer.max_actions システムのプロパティで指定されているアクションの最大数は 50 ですが、最高のパフォーマンスを得るにはフローを 25 アクションに制限します。

入力と出力をサブフローで渡す

入力と出力を渡す場合は、サブフローを呼び出します。開始時にサブフローで使用できる入力を指定する場合、またはサブフローの終了後に親フローで使用できる出力を指定する場合は、サブフローを使用します。

単一のイベントで複数のフローをトリガーする場合と並列サブフローを使用する場合の比較

• 相互に関連する出力があるか、すべてが利用可能な場合に何らかのアクションを実行する必要がある場合は並列サブフローを使用します。そうでない場合は、複数のフローをトリガーする方が簡単です。
• 並列サブフローを設定するには、待機なしで各サブフローを起動し、[ 条件待ち] を使用して各サブフローが終了する (完了、エラー、キャンセル) まで待機します。

類似の機能を持つサブフローが複数ある場合は動的フローを使用する

動的フローでは、テンプレートを適用して複数の類似したサブフローの入力を処理することで、プロセスを区分化できます。区分化により、統合ハブ スポークのサブフローなど、類似の機能を実行するサブフローを区別できます。

エラー処理プロセスで 10 個のアイテムの制限を回避する

エラー処理プロセスを強制的に 10 個のアイテム制限内に収まるようにするのではなく、さらに多くのアイテムを含めることができるサブフローを呼び出します。サブフロー出力を使用して、他のフローの自動化をトリガーすることもできます。

是正処置を実行する

複数のフローで同じ一連のアクションを再作成するのではなく、再利用可能なサブフローを作成して、レコードデータのエラーを修正します。フローエラーによってレコードデータが望ましくない状態になった場合は、サブフローを使用してこれらのレコードを修正します。エラーハンドラーを使用して、そのようなレコードデータをサブフロー出力として特定することができます。

トリガー

レコードトリガーを作成するときは、次の一般的なガイドラインに従います。

フローにトリガーまたは変数の入力が必要かどうかを判断する

フローは、トリガー条件が満たされたときに常に実行されます。トリガーは常にフローの入力として同じデータを提供します。フローを開始するために代わりに変数の入力が必要な場合は、サブフローを作成します。

条件を追加して、フローを開始するレコード値を指定します。

必要なときにのみフローを開始することで、フローを開始して一時停止し、特定のレコード条件が適用されるまでフローの再開を待機するよりもシステムリソースの消費が少なくなります。[条件待ち] アクションで始まるフローを作成する代わりに、レコードトリガーの一部として待機条件を含めるようにフローを再設計します。

同じテーブルのレコードトリガーに一意の条件を作成する

フローが互いに上書きされないようにするには、同じテーブルで実行されているフローごとに一意の条件を作成します。同じテーブルの複数のフローに同じフィルターがある場合、フローが実行される順序を知る方法はありません。条件を使用すると、より正確で少ない数のレコードセットが返されるため、フローのパフォーマンスの最適化にも役立ちます。

インポートおよび更新セットによって追加または更新されたレコードを無視する

レコードトリガーは、更新セットの適用または XML ファイルのインポートによって追加または更新されたレコードを無視します。これらの操作は、個々のレコードではなく、アプリケーションまたはテーブル全体に適用されます。

サービスカタログテーブルのレコードトリガーをサービスカタログアプリケーショントリガーに置き換える

フローデザイナーは、レコードトリガーのオプションとしてサービスカタログテーブルを表示しなくなりました。代わりに、サービスカタログアプリケーショントリガータイプを使用するフローを作成します。

待機条件

条件を待機するフローを作成するときは、次の一般的なガイドラインに従います。

待機条件の代わりにレコードトリガーを使用してフローを開始する

特定のレコード条件が満たされたときにのみフローを実行する場合は、フローを開始して一時停止するのではなく、レコードトリガーを使用してフローを作成します。待機中のフローは、フロートリガーよりも多くのシステムリソースを消費します。

再開条件が発生し得ないフローをキャンセルする

終了フローのフローロジック でフロー停止条件を指定することで、フローが無期限に待機しないようにします。システムリソースを解放するために、再開条件が満たされ得ないフローをキャンセルすることもできます。たとえば、関連するインシデントがクローズされている場合に、インシデントレコードの更新を待機しているフローをキャンセルします。

待機条件を現在のテーブルに存在するフィールドに制限する

[条件待ち] アクションは、レコードが属するテーブルのフィールドに対する変更のみを監視できます。このアクションでは、関連レコードまたはカタログ変数のフィールドの変更を検出できません。たとえば、アクションがインシデントレコードの変更を待機している場合、カタログアイテムや変更タスクレコードなどの関連レコードへの変更を検出することはできません。これらのフィールドは実際には関連レコードに属しているため、別のレコードにドット連結するような待機条件をビルドすることは避けてください。カタログ変数に依存する待機条件をビルドすることは避けてください。

ステージのあるフローまたはサブフロー

ステージを使用してフローまたはサブフローを作成する場合は、次の一般的なガイドラインに従います。

For Each フローロジックに依存するステージの定義を避ける

フローデザイナーでは [For Each] ブロック内にステージを追加できません。[For Each] ブロックの前後にのみステージを追加できます。

異なるフローまたはサブフローでの同じレコードのステージの作成を避ける

ステージフィールドには、テーブルのレコードで実行する最後のフローまたはサブフローからのステージ情報が常に表示されます。複数のフローまたはサブフローが同じレコードで実行される場合、理論的には、1 つのフローまたはサブフローで定義されたステージが別のフローまたはサブフローのステージを上書きする可能性があります。複数のフローまたはサブフローが互いのステージを上書きしないようにするには、フローまたはサブフローごとに一意のトリガー条件または開始条件を定義します。

フローまたはサブフローの外部からのステージフィールドの更新を避ける

フローまたはサブフローを使用してステージを管理する場合は、フローまたはサブフローの外部からレコードステージフィールドを直接更新しないでください。ステージフィールドの値を手動で更新すると、予期しない結果または望ましくない結果が生じる可能性があります。

テーブルの各フローに一意のトリガー条件があることを確認する

各フローに一意のトリガー条件を追加すると、フローはそれらの条件でのみ実行され、あるフローのステージが別のフローのステージを上書きすることを防ぐことができます。一意のトリガー条件を指定すると、レコード変更を生成できるフローの実行回数が制限され、フローのトラブルシューティングが容易になります。

エラーステージを使用してユーザーに通知する

フローのエラーステータスは、フローの実行には影響しません。フローはエラーステージに達しても引き続き実行されます。条件付きフローロジックブロックを使用してエラーステージを設定し、現在のステージのステータスがエラーであることをユーザーに伝えます。たとえば、必要な限度内で承認されていない承認がある場合、ユーザーにエラーを通知することができます。

エラーステージを使用してフローの処理を停止する

条件付きフローロジックブロックを使用して、フローがエラーステージに移行するタイミングを特定します。フローロジックを使用して、フローの処理を停止するか、何らかの修復アクションを実行します。たとえば、フローがエラーステータスになったときに、レコードのステータスやアサインを変更することができます。

Do the following in parallel フローロジック

パス間のデータ依存関係の作成を避ける

フローは任意の順序でパスを実行できるため、別々のパス間でデータの依存関係を作成しないようにしてください。たとえば、1 つのパスでレコードを作成し、別のパスで同じレコードを更新しないようにしてください。レコード更新パスが、レコード作成パスの前に実行される場合があります。

パス間でデータを共有しない

どのパスが最初に出力値の提供を完了するかをシステムが判断できないため、ワークフロースタジオ ではパス間でデータピルをドラッグすることはできません。

動的フローのフローロジック

類似の機能を持つサブフローが複数ある場合は動的フローを使用する

動的フローでは、テンプレートを適用して複数の類似したサブフローの入力を処理することで、プロセスを区分化できます。区分化により、統合ハブ スポークのサブフローなど、類似の機能を実行するサブフローを区別できます。

動的に呼び出されるサブフローの入力がテンプレートフローの入力と一致することを確認する

動的フローの入力がフローテンプレートの入力と一致しない場合、システムはエラーをスローし、メインフローを正しく実行できません。

フロー出力の取得時に正しいコンテキストを使用する

コンテキストレコードはフローの実行を一意に識別します。動的フローを複数回実行する場合は、複数のコンテキストレコードから選択できます。フロー内で動的フローを複数回使用する場合は、フロー出力を取得するたびに適切な実行から適切なコンテキストレコードを選択していることを確認してください。

Password2 データピル

パスワード (双方向暗号化) データを含むフローの設計時には、次の一般的なガイドラインに従います。

既存のパスワード (双方向暗号化) データピルを使用して値をアサインします。

password2 変数に値を割り当てるには、既存の password2 データピルを選択する必要があります。その他のフィールドタイプから値を選択することはサポートされません。ワークフロースタジオ では、無効なデータピルタイプが選択された場合に、警告メッセージが表示されます。

注:

パスワード (双方向暗号化) の値を手動で入力することはできません。

パスワード (双方向暗号化) 変数を有効なフィールドタイプにのみ使用する

ワークフロースタジオ で、無効なフィールドタイプの値として Password2 データピルが選択されないようにします。フィールドが互換性のないタイプである場合、システムは警告メッセージを表示します。

ワークフロースタジオ では、Password2 データピルを次のフィールドタイプにのみドラッグできます。

• メール本文のフィールド
• HTML フィールド
• Password2 フィールド
• PowerShell 入力変数
• REST フィールド
  • 変数
  • REST ペイロード本文
  • クエリパラメーター
  • ヘッダー
  • REST マルチパートフォームの値
  • フォーム URL エンコードの値
• SOAP フィールド
  • ヘッダー
  • エンベロープ

注:

パスワード (双方向暗号化) 変数を条件として使用することはできません。

ユーザーが、アクションとフローの保存、公開、またはテストを行ったら、フローデザイナーは検証チェックを実行します。このチェックでは、制限付きフィールドタイプにデータピルがドロップされた場合にアラートが表示され、アクションまたはフローの実行が阻止されます。アクションまたはフローを更新して無効なデータピルを削除してから、アクションを再試行してください。

復号化のための暗号化モジュールを設定する

有効な暗号化モジュールアクセス権を持つユーザーのみが、password2 変数のコンテンツを復号化して表示できます。暗号化アルゴリズムと、暗号化されたデータにアクセスできるロールを指定するには、「KMF による Password2 暗号化 」を参照してください。

[SLA パーセンテージタイマー] アクション

[サービスレベルアグリーメント (SLA) パーセンテージタイマー] アクションを含むフローを作成するときは、次の一般的なガイドラインにいます。

SLA タスクトリガーのあるフローにのみ [SLA パーセンテージタイマー] アクションを追加する

[SLA パーセンテージタイマー] アクションは、フローが SLA タスクトリガーから開始された場合にのみ実行できます。[SLA パーセンテージタイマー] アクションを含むサブフローは有効にできません。

予想されるステータス値に対する条件付きフローロジックを作成する

[ステータス] フィールドの値をフローロジックの条件として使用します。[完了]、[修理]、[スキップ] など、予想される [ステータス] 値に対するフローロジックをビルドします。たとえば、SLA パーセンテージタイマーのステータスが [完了] になったときに通知を送信する [If] フローロジックブロックを追加します。

各 [SLA パーセンテージタイマー] アクションに一意の累積 [待機] 割合値を割り当てる

各 [SLA パーセンテージタイマー] アクションは、[待機] 割合値を使用して独自のスケジュールされた終了日時を計算します。複数の [SLA パーセンテージタイマー] アクションを作成する場合は、各アクションに固有の累積 [待機] 割合値を指定します。たとえば、完了率の値が異なる 3 つのアクションを作成します (25％、50％、75％ 完了など)。3 つのアクションすべてを 25％ などの同じ完了率の値に設定すると、タイマーは同時に完了します。

既存のフローをコピーしてカスタマイズする

デフォルトの SLA フローをコピーし、独自のロジックでコピーをカスタマイズすることで、開発時間を短縮します。SLA 定義から実行するカスタマイズされたフローを選択します。「SLA 定義の作成 」を参照してください。

動的入力

サードパーティ統合の動的入力を検討する

動的入力を使用すると、外部ソースからデータを動的にフェッチするフローを作成できます。サードパーティ統合では、動的入力によって特定のエンドポイントに関連するデータ値を提供できます。ワークフロースタジオ を使用したサードパーティ統合の設定の詳細については、「統合ハブ」を参照してください。

大量のデータの取得に要する時間に注意する

デフォルトでは、タイムアウトになるまでの動的入力によるデータ収集時間は最大 300 秒です。データ収集アクションでデータ収集にそれ以上の時間がかかる場合は、sn_flow_designer.sync_action_execution_timeout_in_seconds のシステムのプロパティをより高い値に設定します。ただし、エンドユーザーが値を入力または選択する必要があるインタラクティブフローには長いタイムアウト値を使用しないでください。

スクリプトエラーに注意する

すべてのデータ収集アクションはスクリプトステップを使用するため、スクリプティングによってエラーが発生する可能性があります。スクリプトを使用して動的入力の JSON 変数を出力すると、入力で必要な JSON 値を受信できなくなるエラーが発生する可能性があります。動的入力スクリプティングエラーが発生すると、次の警告メッセージが表示されることがあります。

図 : 1. スクリプティングエラーに対して表示されるメッセージ

動的入力タイプの入力を 40 個の入力値に制限する

動的入力タイプの入力は、JSON オブジェクトがメモリに格納できないほど大きくなるのを避けるため、特定の数の入力のみをレンダリングできます。動的入力を 40 個の入力値に制限すると、メモリ不足が発生したり、レンダリングエラーやデータの切り捨てなどの予期しない動作が発生したりする可能性が最小限に抑えられます。

動的テンプレートと動的選択の場合、JSON 出力を 5,000 アレイアイテムに制限する

動的選択および動的テンプレート入力では、最大 5,000 個のアレイアイテムしか表示できません。動的選択では最大 5,000 個の選択リストオプションのみを表示でき、動的テンプレートでは最大 5,000 個のフィールドテンプレート値のみを表示できます。データ収集アクションで動的テンプレートまたは動的選択のデータを収集する場合、返されるアレイアイテムの最大数を 5,000 に制限します。5,000 アレイアイテム制限により、選択またはフィールド値をレンダリングするときにインスタンスでパフォーマンスの問題が発生するのを防ぎます。

動的出力

サードパーティ統合の動的出力を使用する

動的出力を使用して、フロー設計時に外部システムのデータをイントロスペクトしてフェッチします。たとえば、特定のエンドポイント API とやり取りするサービスエンドポイントまたは呼び出しアクションを指定できます。ワークフロースタジオ を使用したサードパーティ統合の設定の詳細については、「統合ハブ」を参照してください。

大量のデータの取得に要する時間に注意する

デフォルトでは、システムで停止されるまでの動的出力によるデータ収集時間は最大 300 秒です。データ収集アクションでデータ収集にそれ以上の時間がかかる場合は、sn_flow_designer.sync_action_execution_timeout_in_seconds のシステムのプロパティをより高い値に設定します。エンドユーザーが値を入力または選択することが想定されるインタラクティブフローに長いタイムアウト値は避けてください。

スクリプトエラーに注意する

すべてのデータ収集アクションはスクリプトステップを使用するため、スクリプティングによってエラーが発生する可能性があります。スクリプトエラーにより、出力で必要な JSON 値を受信できない場合があるため、JSON 変数を出力するために使用されるスクリプトを確認します。動的出力スクリプティングエラーが発生すると、次の警告メッセージが表示されることがあります。

図 : 2. スクリプティングエラーに対して表示されるメッセージ

List.[Table] データ

リストレコードをフィルターするための参照修飾子を追加する

参照修飾子を追加し、リスト変数を有効なオプションとして表示するレコードをフィルターします。参照修飾子は必須のリストフィルターとして機能し、これにより参照修飾子の条件に一致するレコードのみがリスト変数に表示されます。たとえば、アクティブなインシデントレコードのみを表示するには、参照修飾子の条件として [アクティブ][次の値に等しい][true] を追加します。

ServiceNow Store の対象アクションのデフォルトレコードを選択しない

すべてのインスタンスが選択したレコードにアクセスできることがわかっている場合を除き、リストのデフォルトレコードを選択しないでください。スポーク開発者は通常、カスタムアクションをインストールする顧客のデータにアクセスできません。ServiceNow Store でカスタムアクションを公開する場合は、デフォルトレコードをデモデータとして提供する必要が生じる場合があります。

For Each フローロジックでリスト変数を使用する

リスト変数を使用して、For Each フローロジック内で処理するレコードを指定できます。For Each フローロジックは、データに存在するすべての non-record sys_id を無視します。たとえば、リスト変数にメールアドレスが含まれている場合、フローロジックはそれを無視します。

承認ルール

デフォルト値の入力

デフォルト値としての承認ルールを作成または選択します。

変換関数

有効なタイプの入力のデータピルに変換関数を適用する

変換関数を適用する前に、入力のデータピルのタイプを確認してください。無効なデータピルタイプに変換関数を適用すると、システムは変換をスキップします。変換関数によってシステムで解析できない結果が生成された場合にも、エラーが発生します。たとえば、文字列を日付に変換する際に、変換によって有効な日付が生成されない場合、システムはエラーをスローします。

同じデータピルを使用して、複数の入力に適用された変換関数を確認する

変換関数は、実行時に特定の入力用に新しい値を作成し、元のデータピルは変更されません。したがって、複数のアクションまたはステップで同じデータピルを使用する場合は、変換関数を個々の入力に適用する必要があります。

フロー実行の詳細で最終的に変換された値を確認する

フロー実行の詳細には最終的に変換された値のみが表示され、適用された各変換の値は表示されません。

変換関数をテストして予期した結果が得られることを確認する

変換関数がデータピルの予期したランタイム値を生成することを確認します。詳細については、「フローのテスト」および「アクションのテスト」を参照してください。

インラインスクリプト

再利用可能かつメンテナンス可能なインラインスクリプトを作成するには、次の一般的なガイドラインに従います。

再利用不可能な短いロジック用のインラインスクリプトを記述する

インラインスクリプトを使用して、特定の入力およびユースケースのデータをフォーマットまたは変更します。再利用可能なロジックの場合は、代わりにアクションまたはサブフローを作成します。

利用可能な変換関数の確認

ワークフロースタジオ は、データ変換とフォーマットの操作のための標準的な変換関数のリストを提供します。カスタムスクリプトソリューションを記述して管理するのではなく、既存の変換関数が利用可能な場合はそれを選択してください。

インラインスクリプトからのスクリプトインクルードの呼び出し

インラインスクリプトからスクリプトインクルードを呼び出すと、記述するコードの量を削減でき、また共通コードを 1 つの場所に保持することもできます。スクリプトインクルードを呼び出すには、クラスコンストラクターを使用します。スクリプトインクルードの作成の詳細については、「Script includes」を参照してください。

var si = new MyScriptInclude();
si.functionOne();

インラインスクリプトではなく、再利用可能なコードのカスタムアクションまたはサブフローを作成する

ソースデータのデータ型の変更など、再利用可能または複合データロジックのカスタムアクションまたはサブフローを作成します。また、コードに慣れていないフローデザイナー向けにカスタムアクションやサブフローを提供することもできます。

アクションとフローの機能を複製しないようにする

アクションとフローの機能を複製するインラインスクリプトは記述しないでください。たとえば、レコード操作を実行するインラインスクリプトを記述するのではなく、レコードベースラインを作成および更新するアクションを使用します。

データ型を変更しないようにする

インラインスクリプトが入力または出力で想定されているものと同じデータ型の情報を提供することを確認して、ランタイムエラーを回避します。

var キーワードで変数を宣言して変数を作成する

「var」キーワードを使用して変数を宣言し、適切な JavaScript スコープ内に留まるようにします。値を割り当てて変数を作成すると、JavaScript によってその変数がグローバルオブジェクトに添付され、変数値がローカルスコープ外で存続してエラーが発生する可能性があります。

For Each フローロジックとフローデータオブジェクトを使用してレコード出力を処理する

インラインスクリプトは、For Each フローロジックから [複数のレコードの検索] アクションの [レコード] 出力にのみアクセスできます。[複数のレコードの検索] アクションをフローに追加して、レコード出力を生成します。For Each フローロジックをフローに追加して、レコード出力の各レコードを処理します。fd_data オブジェクトとアイテムオブジェクトを使用して、For Each フローロジックへのインラインスクリプト参照を作成します。たとえば、この参照では、For Each フローロジックがフローアウトライン「fd_data._2__for_each.item」の 2 番目のアイテムであると想定しています。

先行入力候補を使用して、フローおよびアクションデータへの参照を生成します。

fd_data オブジェクトを使用してフローおよびアクションデータへの参照を作成します。「fd_data」と入力すると、スクリプトエディターに既存のフローとアクションデータの先行入力候補が表示されます。フローおよびアクションデータへの参照をビルドする候補を選択します。

注:

[アイテム] オブジェクトを使用する For Each フローロジックのレコードデータを参照してください。

スコープループカウンター

スクリプトループには最大反復数がないため、有効な終了条件がない場合はループが無限に実行されます。

有効な終了条件があることを確認するには、インラインスクリプトまたはアクション内のスクリプトステップでスコープループカウンターを使用します。 for (i=0; i< length; i++) に var を追加し、for (var i=0; i< length; i++) を取得します。

複合データ

再利用可能かつメンテナンス可能なデータ構造を作成するには、次の一般的なガイドラインに従います。

階層内の子レベルの数を最低限にする

データ構造の子レベルが多いほど、階層からデータ変数を表示して選択することが難しくなります。任意の数の子レベルを持つデータ構造をビルドできますが、7 つを超える子レベルを持つデータ構造をナビゲートして把握することは困難になります。最高のユーザーエクスペリエンスを得るには、水平方向にスクロールして表示および入力しなければならないほど子レベルが多いデータ構造を作成しないでください。

レコードデータのタイプごとに個別のオブジェクトを作成する

ほとんどの ワークフロースタジオ データは、インスタンスからのものか外部システムからのものかを問わずレコードデータです。この設計メソッドにより、オブジェクトの内容とデータの出所を確実に把握できます。

レコードデータ構造を再作成する

レコードデータを送受信するオブジェクトをビルドする場合は、これらのレコードのデータベースディクショナリーエントリを確認し、一致するオブジェクトデータ構造を作成します。たとえば、インシデントおよび構成アイテムテーブルからのデータをオブジェクトに含める必要があるとします。インシデントテーブルの [簡単な説明] フィールド用に文字列要素を作成し、構成アイテムテーブルの [クラス] フィールド用に文字列要素のアレイを作成することができます。

さまざまなタイプのレコードを結合するオブジェクトを作成する

複数のタイプのレコードの情報が必要な場合は、必要なすべての情報を含むオブジェクトを作成します。その後、そのオブジェクトを使用して、ワークフロースタジオ でデータのフォーマットや解析を行うことができます。

複合データを使用したスクリプティング

複合データを使用してスクリプトを作成する場合は、次の一般的なガイドラインを念頭に置いてください。

文字列入力を使用して複合データを JSON 文字列に変換する

複合データを文字列入力にマッピングすると、ワークフロースタジオ によって自動的に JSON 文字列に変換されます。スクリプトを記述する代わりに、文字列入力を REST ステップに追加し、前のアクションまたはステップからの複合データにマッピングすることができます。

オブジェクトをテンプレートとして保存する

オブジェクトをテンプレートとして保存して、他のアクション、フロー、およびスクリプトステップで再利用できるようにします。

以前のデータにアクセスするためのスクリプト入力変数を作成する

アクション入力または前のステップからアクセスするデータのスクリプト入力変数を作成します。スクリプト入力変数を入力またはステップデータピルにマッピングします。たとえば、スクリプト入力変数を、前のステップで検索したユーザーレコードリストにマッピングします。

複合データを格納するスクリプト出力変数を作成する

スクリプトで作成した任意の複合データを格納するスクリプト出力変数を作成します。スクリプト出力変数は、スクリプトで定義された値と一致する必要があります。たとえば、複数の連絡先オブジェクトを格納するオブジェクトの連絡先アレイを作成します。連絡先オブジェクトをテンプレートとして保存し、再利用できるようにします。

アクション出力をスクリプト出力変数にマッピングする

カスタムアクションで複合データを出力する場合は、アクション出力を追加し、スクリプトステップ出力変数のデータピルにマッピングします。たとえば、連絡先アレイを作成し、前に保存した連絡先オブジェクトテンプレートをロードします。アクション出力を、スクリプトステップによって生成された連絡先アレイにマッピングします。

フローデザイナーとドメインセパレーション

ワークフロースタジオ でドメインセパレーションを使用する場合は、次の一般的なガイドラインに従います。

テナントフロー、アクション、およびサブフローがドメインに対して適切に実行されていることを確認する

テナントは ワークフロースタジオ のコンテンツを上書きできないため、TOP ドメインのサービスプロバイダー (SP) アドミニストレーターは、ドメインで正しく実行されるように、テナントを作成して管理する必要があります。ドメイン固有のフローを作成することもできますが、階層の上位のドメインから作業しているユーザーが複数の子ドメインフローをトリガーする可能性があります。たとえば、TOP ドメインで作業しているユーザーは、ACME や INITECH などの子ドメインでフローをトリガーできます。

注:

フロー作成者は、階層内の現在のドメインと親ドメインから利用可能な ワークフロースタジオ のコンテンツのみを表示できます。ワークフロースタジオ は包含ドメインから表示されるコンテンツを表示しません。

各フロー、アクション、およびサブフローに一意の名前を指定する

すべてのドメインが ワークフロースタジオ コンテンツを共有するため、TOP ドメイン内の SP アドミニストレーターに各フロー、アクション、およびサブフローに一意の名前を付けるように依頼します。これにより、あるドメイン向けのフローと別のドメインのフローの名前が重複しないようにします。たとえば、「インシデントの検証 - TOP」、「インシデントの検証 - ACME」、「インシデントの検証 - INITECH」のように、フロー名にドメインを追加します。

フローとアクションに現在のドメインまたは親ドメインからのアーティファクトのみが含まれていることを確認する

ワークフロースタジオ は、現在のドメインまたは親ドメインで利用できないアーティファクトを含むフローがアクティブ化されるのを防ぎます。たとえば、ACME ドメインに属するドメイン固有のフローを作成する場合、兄弟ドメイン INITECH に属するアクションまたはサブフローを含めることはできません。

属するドメインの ワークフロースタジオ のコンテンツを編集する

親ドメインのユーザーは、子ドメインのフロー、アクション、およびサブフローを表示できません。編集するには、属しているドメインに変更する必要があります。たとえば、TOP ドメインのアドミニストレーターは ACME ドメインからのフローを表示できません。それらを表示および編集するには、アドミニストレーターが ACME ドメインに切り替える必要があります。

展開

古いリリースのインスタンスに新しいリリースのフローを展開することは避けてください

ワークフロースタジオ では、以前のリリースで実行されているインスタンスへの新しいリリースフローの展開はサポートされていません。

危険:

フローデータモデルはリリース間で変更される可能性があるため、新しいフローが実行されなかったり、以前のリリースのインスタンスで実行したときに予期しない結果が生じたりする可能性があります。展開する前に、同じリリースバージョンになるようにインスタンスをアップグレードしてください。

フローエラー処理

フローエラー処理によるメリットを得るには、次の一般的なガイドラインに従います。

エラー処理アイテムをフローのメインセクションに追加しないようにする

通常、アクションまたはサブフローがメインセクションでエラーを返すと、フローは実行を停止します。停止したフローは、エラーが返された時点を過ぎてアクションまたはサブフローを実行することはできません。エラー処理アクションとサブフローを [エラーハンドラー] セクションに追加すると、エラーが発生した場合にエラー処理アクションとサブフローが確実に実行されるようになります。

エラーステータス情報をキャプチャする

エラーステータスオブジェクトには、エラーを生成したアクションに関する情報が含まれています。この情報を使用して、エラーの原因や、修正が必要な可能性があるレコードデータを特定することができます。

サブフローエラーメッセージを非表示にする

サブフローのエラーハンドラーを有効にして、エラーが親フローにカスケードされないようにすることができます。サブフローの [エラーハンドラー] セクションを空のままにすると、常に [完了 (エラーを取得)] ステータスが生成されます。

サブフローを使用して 10 個のアイテム制限を回避する

エラー処理プロセスを強制的に 10 個のアイテム制限内に収まるようにするのではなく、さらに多くのアイテムを含めることができるサブフローを呼び出します。サブフロー出力を使用して、他のフローの自動化をトリガーすることもできます。

サブフローを使用して是正処置を行う

複数のフローで同じ一連のアクションを再作成するのではなく、再利用可能なサブフローを作成して、レコードデータのエラーを修正します。フローエラーによってレコードデータが望ましくない状態になった場合は、サブフローを使用してこれらのレコードを修正します。エラーハンドラーを使用して、そのようなレコードデータをサブフロー出力として特定することができます。

アクションエラー評価

アクションエラー評価によるメリットを得るには、次の一般的なガイドラインに従います。

独立したステップのみの実行継続を許可する

ステップが後続のステップで必要なデータを返さない場合は、ステップの実行継続を許可します。ステップが後続のステップで必要なデータを提供する場合、後続のステップを正常に実行できないことがわかります。

エラー条件が 10 を超えないようにする

作成できるエラー条件の数に制限はありませんが、各エラー条件は評価する必要があります。アクションで評価する必要があるエラー条件が多いほど、アクションの実行が低速になる可能性があります。

特定のステップの失敗を識別する

ステップステータスを使用して特定のステップがいつ失敗したかを識別できます。特定のステップを識別することは、アクションにタイプが同じステップの複数のインスタンスが含まれている場合に役立ちます。また、フローエラーハンドラーが失敗に対して適切な是正処置を実行できるように、特定のステップを識別することもできます。

特定のエラー条件を一般的なエラー条件の前に配置する

アクションが一致するエラー条件を検出すると、エラーの評価は停止します。一般的なエラー条件を最初に配置すると、アクションが特定のエラー条件に一致しなくなる可能性があります。

わかりやすいエラー条件ラベルを使用する

エラー条件を編集する必要なく識別できるようになります。デフォルトでは、エラー条件は編集時にのみ表示できます。

フローアドミニストレーター

本番環境でフローレポートをオフにする

フローレポートを無効にして、フローの実行に必要なメモリ量を最小限に抑えます。フローレポートには、[実行の詳細] ページの構成とランタイム情報が保存されます。これらのレポートはトラブルシューティングに役立ちますが、メモリとデータベースの両方に大量のデータを保持する必要があります。デフォルトでは、フローレポートは無効になっており、フローまたはアクションを手動でテストする場合にのみ実行の詳細が生成されます。代わりに、レポートをオフにしているときも使用できるログファイルを使用できます。

ネストされたループを使用してフローで消費するメモリ量を削減する

レポートが有効になっている場合は、com.snc.process_flow.reporting.iteration.lastn を値「1」に設定して、前のループ反復で消費されるメモリ量を減らします。レポートする反復が多いほど、より多くのメモリが必要になります。

フロー実行の詳細で最終的に変換された値を確認する

フロー実行の詳細には最終的に変換された値のみが表示され、適用された各変換の値は表示されません。

フロー優先度

フロー優先度を設定するときは、デザインに関する次の検討事項に従ってください。

すべてのフローを高い優先度で実行するように設定しない

すべてのフローの優先度を高く設定するのではなく、複数の優先度を組み合わせて設定します。ワーカースレッドは、フロー間の相対的な優先度で作業を選択します。すべてのフローが高い優先度で実行されている場合、待機すべき優先度の低いフローはありません。

一時停止する必要があるフローにはフロー優先度を設定しない

一時停止する必要のあるフローは、デフォルトである中程度の優先度のままにしておきます。フローの実行を再開すると、その優先度の値が失われるためです。

ビジネスクリティカルなフローには高い優先度を使用する

優先度の高いフローは、ビジネス価値が高く、実行頻度が低く、実行時間が短いフローに限定します。他のフローを実行できるワーカースレッドの数が制限されるため、大量のフローを高い優先度に設定しないでください。高優先度のフローを長時間実行すると、他のフローの実行に使用可能なワーカースレッドが減る可能性もあります。

ボリュームの大きなフローには低い優先度を使用する

他の時間的制約のあるフローが最初に実行されるように、ボリュームの大きなフローは低い優先度で実行します。優先度の低いフローには時間的制約がないようにしてください。

時間的制約のあるフローには中程度の優先度を使用する

他のフローと比較して時間的な制約が高いフローには、デフォルトのフロー優先度を使用します。

関連情報

• https://learning.servicenow.com/