複数のシナリオを連結する
複数のシナリオを連結して、1 つのシナリオで別のシナリオをトリガー設定し、2 番目のシナリオで出力されたデータを 1 番目のシナリオに戻すことができます。 これにより、複数のシナリオでシナリオセクションを複製する必要がなくなり、よりモジュール型のシナリオを作成できます。
親シナリオから複数の子シナリオを呼び出すことができ、複数の親シナリオから 1 つの子シナリオを呼び出すことができます。 子シナリオをネストして、別のシナリオから呼び出すこともできます。
親シナリオが子シナリオがデータを返すのを待っている場合、その時間は親シナリオのタイムアウトにカウントされません。 例えば、親シナリオが 5 つの子シナリオを呼び出すと、各子シナリオの実行に 10 分かかり、合計で 50 分かかります。 親シナリオ自体のモジュールの実行に 15 分かかります。 合計 65 分（40 分のタイムアウト制限を超える）が経過しても、親シナリオはタイムアウトしません。
タイムアウトを含む、Fusion のパフォーマンスガードレールについて詳しくは、「Fusion パフォーマンスガードレール」を参照してください。
チェーンモジュールの設定手順については、 チェーンモジュールを参照してください。
親シナリオと子シナリオ
- 親 シナリオは、チェーン/子シナリオを呼び出し モジュールを使用して別のシナリオを呼び出します。 子シナリオの出力を受け取り、後のシナリオモジュールで処理できます。
- 子 シナリオは親シナリオによって呼び出されます。 そのトリガーモジュールは、親シナリオからデータを受け取り、出力を親シナリオに返します。
親シナリオには子シナリオからの応答が必要です。 データを返さない子シナリオは、現在サポートされていません。
チェーンシナリオのデータ構造
Workfront Fusion は、データ構造を使用して、親シナリオから子シナリオに情報を転送します。 データ構造は、子シナリオで設定します。 子シナリオを親シナリオから選択すると、子シナリオの入力として使用されるデータ構造のフィールドが親シナリオに表示されます。 これらのフィールドに値をマッピングできます。マッピングは、トリガーされたときに子シナリオに渡されます。
親および子シナリオで設定するモジュールについて詳しくは、 チェーンモジュールを参照してください。
データ構造について詳しくは、 データ構造を参照してください。
データフロー
- データは、親シナリオを通過します。
- データが「子を呼び出し」シナリオモジュールに到達する データは「子シナリオを呼び出し」モジュールのフィールドにマッピングされます。これは、子シナリオのトリガーモジュールで使用されるデータ構造のフィールドに一致します。
- 「子の呼び出し」シナリオのデータは、子シナリオに渡されます。
- 子シナリオはデータを処理し、アクションを実行します。
- 子シナリオは「親に応答を返す」モジュールで終了します。
- 「親に応答を返す」モジュールの出力は、親シナリオに渡されます。
- 「子を呼び出す」シナリオの出力は、子シナリオの出力です。 この出力は、親シナリオで後から処理できます。
ユースケース
シナリオを連結する際の、次のユースケースの例を考えてみましょう。
-
再利用可能なロジック：複数のシナリオで繰り返し使用されるアクションに対して、シナリオを連鎖させることができます。 例えば、コンテンツをアーカイブするシナリオが複数ある場合、「コンテンツのアーカイブ」と呼ばれる 1 つの子シナリオを作成して、コンテンツをアーカイブするワークフローの子シナリオとして使用できます。
-
エラー処理：エラーログをデータストアに送信し、Slack 通知を作成するエラー処理ルートなど、複数のシナリオで同じエラー処理アクションを持つ組織は一般的です。 これらのアクションを持つ子シナリオを作成し、複数のシナリオでのルートのエラー処理でそのシナリオを連鎖させることができます。
-
時間の延長：ファイルのエクスポートやインポートを行う場合など、長時間実行されるアクションを伴う大規模なバッチ操作に対して、連鎖を使用できます。 ファイル数が多い場合、この操作には時間がかかります。 子シナリオは親シナリオのタイムアウトに対してカウントされないので、複数の子シナリオを使用してファイルを書き出したり読み込んだりすると、実行時間を超える可能性があります。
-
イテレータの置き換え イテレータを子シナリオに置き換えると、メモリ不足エラーの原因となる繰り返しの複雑な操作など、メモリの使用量を減らすことができます。 複雑な操作に対して別のシナリオを作成し、イテレータを子シナリオを呼び出しモジュールに置き換えることができます
-
レコードの検索と作成：例えば、ユーザーを検索するシナリオを作成できます。 存在する場合、レビューおよび承認する必要があるアクセス権を持つ承認者としてスキーマによって追加されます。 存在しない場合、シナリオは管理者が新しいユーザーをオンボーディングするためのリクエストを作成します。
連鎖シナリオの実行履歴の表示
チェーンに含まれる各シナリオの履歴を表示すると、チェーンされたシナリオの実行履歴を表示できます。 例えば、親シナリオの実行履歴には、親シナリオで直接処理されるモジュールとデータに関する情報が含まれます。 子シナリオで処理されるモジュールおよびデータの実行履歴を表示するには、子シナリオを開き、実行履歴を表示します。
子シナリオを呼び出しモジュールの「子シナリオに移動」ボタンを使用して、子シナリオにすばやく移動し、実行履歴を表示することをお勧めします。 子シナリオは別のブラウザーウィンドウで開き、親シナリオと子シナリオを同時に表示できます。
エラーと不完全な実行
エラー処理
子シナリオでエラーが発生した場合、親へのデータの取得に影響する可能性があります。
子シナリオでエラー処理を設定することをお勧めします。子シナリオで問題が発生した場合、親シナリオが子シナリオからの応答を待ち続けないようにします。
ベストプラクティス
シナリオを連結する際は、次のベストプラクティスを考慮してください。
シナリオを連鎖する場合は再帰を避ける
再帰は、シナリオが自分自身の新しい実行をトリガーし、新しい実行をトリガーにする場合などに、無限ループで発生します。
再帰を使用すると、再帰シナリオを所有する組織と他の組織の両方でパフォーマンスの問題が発生する可能性があります。
シナリオを連鎖する場合は、再帰を避けるために次のプラクティスに従います。
- 子シナリオは親シナリオをトリガーにできない ことを確認します。 例えば、リクエストの作成時に親シナリオがトリガーされる場合は、子シナリオでリクエストが作成されないようにしてください。
- 子シナリオが互いを呼び出さない ことを確認します。 例えば、子シナリオ A が子シナリオ B を呼び出す場合、子シナリオ B が子シナリオ A を呼び出さないようにします。
- シナリオは自身を呼び出すことができない ことを確認します。 例えば、シナリオは、タスクが作成されるとトリガーされ、そのシナリオでは 2 つのタスクが作成されます。 新しく作成されたタスクでは両方ともシナリオが再度トリガーされ、4 つの新しいタスクが作成されます。 タスクが作成されるたびにシナリオがトリガーされ、シナリオが実行されるたびにタスクの数が 2 倍になります。 タスクの数が指数関数的に増加します。
- シナリオが再帰を引き起こしている場合、パフォーマンスの問題がさらに発生するのを防ぐために、Fusion エンジニアリングチームによって非アクティブ化されます。
- 再帰はシナリオの設計の結果なので、シナリオをトリガーにするアクションがシナリオに含まれないようにシナリオを設計する必要があります。
エラー処理を使用した応答の確認
親シナリオは続行する前に子シナリオからの応答を待機するので、エラーが発生した場合でも応答を提供するように子シナリオが構築されていることを確認する必要があります。