過度のフロー更新を防止する方法Issue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } フローデザイナーを使用すると、トリガーが適切に制限されていないフローを作成できます。開発者が注意しないと、再帰フローによってインスタンスのパフォーマンスの問題が発生する可能性があります。これは、過度に実行されるフローにも当てはまります。開発者は、フローをトリガーする方法と理由を認識する必要があります。 Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Cause<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 通常、このような問題は「更新済み」または「作成済みまたは更新済み」トリガーに関連しています。フロートリガーのリスト 開発者は、フローが再帰的に何度も呼び出されるか、プラットフォームの更新によってさらにフローをトリガーするだけになるロジックチェーンを見逃す可能性があります。 Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 認識のための組み込みのプラットフォーム保護から始めましょう。以下は、フローデザイナーに関するドキュメントからの抜粋です。 直接再帰の防止と間接再帰の制限 インスタンスの機能停止やシステムリソースの消費を防ぐために、フローデザイナーは直接再帰の結果であるフローを開始する要求を無視します。直接再帰は次の条件下で発生します。 アクションが、自分自身が含まれているものと同じフローを呼び出す場合。たとえば、スクリプト ステップからフローへの API 呼び出しを実行する、などです。アクションまたはサブフローによって、フローのトリガーに一致する結果が生成される場合。たとえば、インシデント レコードが更新されたときに実行されるフローに、インシデント レコードを更新するレコード更新アクションが含まれている、などです。 フローデザイナーでは、間接再帰からフローを開始できる回数も制限されています。関節再帰は次の条件下で発生します。 同じフローが一連のサブフロー呼び出しの中で複数回呼び出される場合。たとえば、サブフロー A がサブフロー B を呼び出し、サブフロー B がサブフロー A を呼び出す場合、いずれかのサブフローの呼び出しによって間接再帰が生じます。一連のサブフローで同じフローが複数回トリガーされる場合。たとえば、レコードの作成によってトリガーされる 2 つのフローがあるとします。レコード A を作成するとフロー A がトリガーされ、レコード B が作成されます。さらに、レコード B を作成するとフロー B がトリガーされ、レコード A が作成されます。いずれかのレコード タイプの作成によって間接再帰が生じます。 デフォルトでは、実行カウントが 3 回の間接再帰制限に達すると、フローの実行が停止されます。アドミニストレーターは、システムプロパティ com.glide.hub.flow_engine.indirect_recursion_limit を 1 以上の整数値に設定することで、制限を変更できます。1 未満のプロパティ値は無視され、代わりに 1 回の制限が適用されます。間接再帰の制限を増やすとインスタンスのパフォーマンスに影響を及ぼす場合があるので注意してください。 注意:デフォルトでは、トランザクション割り当てルールにより、フローの実行時間が 1 時間より長くなることはありません。 インタラクティブセッションと非インタラクティブセッションの認識。インタラクティブセッションと非インタラクティブセッション 開発者は、インタラクティブセッションと非インタラクティブセッションがどのように機能するかを理解する必要があります。単純化しすぎて、インタラクティブセッションは人々が行動を起こし、非インタラクティブセッションはプラットフォームや自動化が行動を起こすようなものだと考えてください。フローを作成するときに、レコードの更新ごとにトリガーする場合、ユーザーがそのレコードを更新するか、人間とジョブの両方を更新するかだけを気にしますか? 人々が何をしているかだけを気にするなら。詳細オプションと [フローを実行するタイミング] セクションに移動することを検討してください。その後、このフローをトリガーするユーザーを変更できます。これにより、バックグラウンド更新によってトリガーされるフローの更新回数が長くなるのを防ぐことができます。バックグラウンドジョブが多数のレコードを更新すると、非常に多くのフロー更新がトリガーされるため、パフォーマンスの問題が発生することがわかりました。 フロートリガーのドキュメントから。 注意: それぞれ一意の変更の場合 で実行されるレコードトリガーを持つフローは、非インタラクティブセッションで実行すると再帰を生成する可能性があります。このようなフローがトリガーレコードに変更を加えると、変更がフロートリガー条件を満たし、再帰が生じます。 フローを作成するときに適切なフィルター条件を作成します。 フローを設計するときは、フローの実行が重要な場合の正確な条件を考慮します。たとえば、更新のたびにインシデントフォームのフィールドをチェックするフローがあるとします。そのフィールドに入力しないと、作業エンジニアに通知する必要があります。これは、インシデントのライフスパンにわたってかなり過剰になる可能性があります。そこでユースケースを確認したところ、インシデントが「Work in progress (対応中)」のときにフィールドを設定する必要があることがわかりました。その2番目の部分が重要です。インシデントが「対応中」ステータスかどうかをフローでチェックする必要があります。そうでない場合は、フローの実行を無視できます。 これは 1 回限りの更新にも当てはまります。プラットフォームで提供されているツールを使用していることを確認してください。[トリガーを実行] オプションにはいくつかの選択肢があります。レコードに対してフローを 1 回だけ実行する必要がある場合は、フィルターを適切に設定してから、トリガーを 1 回だけ実行するように設定する必要があります。 開発中は、ユーザーセッションでフローを実行することを検討してください。 テスト中に、詳細オプションのデフォルトのフローの動作を [バックグラウンドでフローを実行] から [フォアグラウンドでフローを実行] に変更するとよい場合があります。これは、開発者がフローの処理を「感じる」のに役立ちます。これにより、トリガーされたフローが終了するまでユーザーセッションが一時停止します。開発者はこれを使用して、一般的なフローや一般的に実行されているフローがシステムにどのように影響するかを理解できます。これはユーザートランザクションで 5 分間のみ実行されますが、フローのパフォーマンスを確認するためにしばらく時間を費やす価値があるかもしれません。実行が表示されない場合、フローの実行回数や実行時間が長すぎていることに気付かない可能性があります。 フローコンテキストまたは「運用ダッシュボード」を使用して、過剰なフローを監視します。 フローの実行を確認するには、フローデザイナーの > 運用ダッシュボードまたはフローデザイナーの>今日の実行を確認して、フローの動作を把握できます。これを確認して、どのフローが長時間実行されているか、または長時間実行されているかを把握することをお勧めします。その後、ログを確認したり、必要に応じてサポートに依頼してフローをレビューしたりできます。