複数のシナリオの連結
シナリオを連鎖させ、あるシナリオが別のシナリオをトリガーできるようにし、2番目のシナリオで出力されたデータを最初のシナリオに戻すことができます。 これにより、複数のシナリオでシナリオセクションを複製する必要がない、よりモジュール化されたシナリオ作成が可能になります。
親シナリオから複数の子シナリオを呼び出すことができ、複数の親シナリオから子シナリオを呼び出すことができます。 子シナリオをネストして、別のシナリオを呼び出すこともできます。
親シナリオが子シナリオがデータを返すのを待っている場合、その時間は親シナリオのタイムアウトに対してカウントされません。 例えば、親シナリオは5つの子シナリオを呼び出し、それぞれが実行するのに10分かかり、合計50分かかります。 親シナリオ自体のモジュールの実行には15分かかります。 合計65分が経過しても、親シナリオはタイムアウトしません。これは、タイムアウト制限の40分を超えています。
タイムアウトを含むFusionのパフォーマンスガードレールについて詳しくは、Fusionのパフォーマンスガードレール を参照してください。
チェーンモジュールの設定方法については、 チェーンモジュール を参照してください。
親シナリオと子シナリオ
- 親 シナリオは、チェーン > 子シナリオの呼び出し モジュールを使用して別のシナリオを呼び出します。 子シナリオの出力を受け取り、後のシナリオモジュールで処理できます。
- 子 シナリオは、親シナリオによって呼び出されます。 トリガーモジュールは、親シナリオからデータを受け取り、出力を親シナリオに返します。
親シナリオには、子シナリオからの応答が必要です。 データを返さない子シナリオは現在サポートされていません。
連鎖したシナリオにおけるデータ構造
Workfront Fusionでは、データ構造を使用して、親シナリオから子シナリオに情報を転送します。 データ構造は、子シナリオで設定されます。 親シナリオから子シナリオを選択すると、子シナリオの入力として使用されるデータ構造のフィールドが親シナリオに表示されます。 これらのフィールドに値をマッピングできます。このフィールドは、トリガーされたときに子シナリオに渡されます。
親シナリオと子シナリオで設定するモジュールについて詳しくは、 チェーンモジュール を参照してください。
データ構造について詳しくは、 データ構造を参照してください。
データフロー
- データは親シナリオを通過します。
- データは子シナリオモジュールを呼び出しに到達します。 データは、子シナリオの呼び出しモジュールのフィールドにマッピングされます。このフィールドは、子シナリオのトリガーモジュールで使用されるデータ構造内のフィールドと一致します。
- 「子シナリオを呼び出し」シナリオのデータが子シナリオに渡されます。
- 子シナリオは、データを処理し、アクションを実行します。
- 子シナリオは、親モジュールへの応答の返りで終了します。
- 親モジュールへの返品応答の出力は、親シナリオに渡されます。
- 子シナリオの呼び出しの出力は、子シナリオの出力です。 この出力は、後で親シナリオで処理できます。
ユースケース
連鎖シナリオの次の使用例を考えてみましょう。
-
再利用可能なロジック：複数のシナリオで使用される繰り返しアクションのシナリオをチェーンできます。 例えば、コンテンツをアーカイブする複数のシナリオがある場合、「コンテンツをアーカイブ」という1つの子シナリオを作成し、コンテンツをアーカイブするワークフローの子シナリオとして使用できます。
-
エラー処理：複数のシナリオで同じエラー処理アクションを行うことが一般的です。例えば、エラーログをデータストアに送信し、スタック通知を作成するエラー処理ルートなどです。 これらのアクションを使用して子シナリオを作成し、複数のシナリオでルートを処理する際にそのシナリオをチェーンできます。
-
時間の延長：合計処理時間が1つのシナリオの実行制限の40分を超える大規模なバッチ操作にチェーンを使用できます。 ただし、このパターンは慎重に扱ってください。複数の長時間実行中の子シナリオに連鎖する親シナリオには、全体的なタイムアウト境界はありません。 子シナリオがハングしたり、プラットフォームの問題が発生した場合、親はエラーを表示することなく無期限に待機します。
チェーンを使用して実行時間を延長する前に、バッチサイズを小さくできるか、頻度を増やすか、長いシーケンシャルチェーンを避けるために設計を再構築するかを検討します。 以下の ベストプラクティス を参照してください。
-
イテレーターの置き換え イテレーターを子シナリオに置き換えると、イテレーションでメモリ不足エラーが発生する複雑な操作など、メモリ使用量を削減できます。 複雑な操作のために別のシナリオを作成し、イテレータを子シナリオモジュールの呼び出しに置き換えることができます
-
レコードを検索して作成：例えば、ユーザーを検索するシナリオを作成できます。 スキーマが存在する場合、レビューと承認が必要なアクセス権を持つ承認者として追加されます。 ユーザーが存在しない場合、管理者が新しいユーザーをオンボーディングするためのリクエストがシナリオによって作成されます。
連鎖シナリオの実行履歴の表示
チェーンに含まれる各シナリオの履歴を表示することで、チェーン化されたシナリオの実行履歴を表示できます。 例えば、親シナリオの実行履歴には、親シナリオで直接処理されるモジュールとデータに関する情報が含まれます。 子シナリオで処理されたモジュールとデータの実行履歴を表示するには、子シナリオを開き、そこで実行履歴を表示します。
子シナリオモジュールを呼び出す ボタンを使用して、子シナリオに素早く移動し、実行履歴を表示できるようにすることをお勧めします。 子シナリオは別のブラウザーウィンドウで開き、親シナリオと子シナリオを同時に表示できます。
エラーと不完全な実行
エラー処理
子シナリオでエラーが発生した場合は、親にデータを返す場合に影響する可能性があります。
子シナリオでエラー処理を設定して、子シナリオで何か問題が発生した場合に、親シナリオが子シナリオからの応答を待ったまま停止しないようにすることをお勧めします。
ベストプラクティス
シナリオを連鎖させる際には、次のベストプラクティスを検討します。
シナリオを連鎖させる際の繰り返しを避ける
再帰は、シナリオが自身の新しい実行をトリガーし、それが新しい実行をトリガーにする場合などに、無限ループで発生します。
再帰が再帰シナリオを所有する組織と他の組織の両方でパフォーマンスの問題を引き起こす可能性があります。
シナリオを連鎖させる場合は、次の方法に従って繰り返しを避けます。
- 子シナリオが親シナリオをトリガーできないことを確認します。 例えば、リクエストの作成時に親シナリオがトリガーされる場合、子シナリオがリクエストを作成していないことを確認します。
- 子シナリオが互いに呼び出さないようにしてください。 例えば、子シナリオ Aが子シナリオ Bを呼び出す場合、子シナリオ Bが子シナリオ Aを呼び出さないようにします。
- a シナリオが自分自身を呼び出せないことを確認します。 例えば、シナリオは、タスクが作成されるとトリガーされ、そのシナリオでは 2 つのタスクが作成されます。 新しく作成されたタスクでは両方ともシナリオが再度トリガーされ、4 つの新しいタスクが作成されます。 タスクが作成されるたびにシナリオがトリガーされ、シナリオが実行されるたびにタスクの数が 2 倍になります。 タスクの数が指数関数的に増加します。
- シナリオが再帰を引き起こしている場合、Fusion エンジニアリングチームによって非アクティブ化され、パフォーマンスの問題の発生を防ぎます。
- 再帰はシナリオの設計の結果なので、シナリオをトリガーにするアクションがシナリオに含まれないようにシナリオを設計する必要があります。
- 親子シナリオ間の関係の図を表示できます。
手順については、連鎖シナリオ関係の表示を参照してください。
エラー処理を使用して応答を確保する
親シナリオは子シナリオからの応答を待ってから続行できるので、エラーが発生した場合でも応答を提供するように子シナリオが構築されていることを確認する必要があります。
「トリガーを最後に確定（CTL）」設定は使用しないでください
チェーン付きシナリオで「トリガーを最後に確定（CTL）」設定を使用することはお勧めしません。 チェーンを使用するシナリオで再試行動作が必要な場合は、定義された最大再試行回数を持つエラー処理ルートを使用して明示的に実装します。
ネスティングの深さを制限
チェーンされたシナリオネットワークの深さを2つのレベル（親→子）に制限します。 3つ以上のレベル（親→子→孫）でネストされたシナリオは、複雑さを大幅に増加させ、観察可能性を減らし、エンジニアリングサポートなしで故障を診断することを困難にします。
設計に詳細なネスト化が必要な場合は、実稼動にデプロイする前にチェーンマップ全体を文書化し、監視が適切に行われていることを確認します。
火を使って慎重に忘れる
子シナリオモジュールを呼び出しで火と忘れが有効になっている場合、親シナリオは子をディスパッチし、応答を待たずにすぐに続行します。 親は、子シナリオが実行されたか、成功したか、失敗したかを把握できません。
次の場合にのみFireとForgetを使用します。
- 子シナリオは、親シナリオのロジックに影響を与えないロギング、通知、または監査書き込みを実行します
- サイレントの子エラーを検出するための独立した監視を使用できます
次の場合は、FireとForgetを使用しないでください。
- 子シナリオは、親が依存する書き込みを実行します
- 親が続行する前に子シナリオが成功したかどうかを知る必要があります
- ワークフローが取引関係であるか、処理保証が正確に1回必要です
イテレーター内の子シナリオを大量に呼び出さないようにします
BasicFeederまたはその他のイテレーター内に子シナリオモジュールを呼び出しを配置すると、処理されたすべての項目に対して子シナリオがディスパッチされます。 アイテム数が多い（実行ごとに数百以上）場合、これによりディスパッチのオーバーヘッドが大幅に増加し、プラットフォームの信頼性の問題が発生する可能性が高くなります。
このパターンを使用する前に：
- 子シナリオのロジックを親シナリオに直接モジュールとしてインライン化できるかどうかを検討します
- アイテムごとにチェーンコールをディスパッチするのではなく、イテレーター外のイテレーションごとに同じ値を返すルックアップを事前に計算します
- 実稼動にデプロイする前に、現実的な最大項目数を確認し、管理者に確認してください