フロー構築のベストプラクティス
Workflowsの最良のパフォーマンスを保証するため、フローを構築するときはベストプラクティスに従ってください。
APIエンドポイントの効果的な使用
Workflows APIエンドポイントにより、外部クライアントがHTTP上でフローを起動できます。これは、組み込みのコネクターライブラリによって開始されるもの以外にもフローを拡張できる、強力な機能です。ただし、これらのフローは正常に完了したことを確認する必要があります。「APIエンドポイントフローの呼び出し」を参照してください。
APIエンドポイントのタイムアウト
APIエンドポイントを使用するときの主な問題は、Workflowsエンジンにレイテンシーの保証がないことです。つまり、フローはほとんどの場合は高速に実行されますが、フローの実行時間が10倍またはそれ以上に変化する可能性があります。
APIエンドポイントはクライアントへの接続を60秒でクローズするため、操作にそれ以上の時間がかかるとフローは失敗します。APIエンドポイントフローを起動する一部のHTTPクライアントは、デフォルトのAPIタイムアウトよりさらに短い時間でタイムアウトすることもあります。たとえば、Oktaインラインフックのデフォルトタイムアウトは3秒です。
フローの非同期構造化
APIエンドポイントフローを操作するときのベストプラクティスは、フローが非同期に処理される構造にすることです。つまり、呼び出し元（HTTPクライアント）が特定の応答を待つ必要がないように設計します。
これは、Oktaフックと統合する場合に特に重要です。たとえば、同期登録やインポートインラインフックから始まるフローを考えてみましょう。このような場合は、非同期のUser CreatedおよびUser Okta Profile Updatedイベントカードを使用するOktaイベントを使ってフローを再構築できます。非同期パターンへの移動は、どちらのシステムでもさらに利点があります。一般的な例は、新しいユーザーの登録とインポートを第3のシステムで記録する場合です。この操作を即時に行うことが絶対に必要でない限り、非同期パターンを使用した方が良好なエクスペリエンスが得られます。
APIコネクターのクローズカードを行の先頭に配置
タイムアウトのリスクを管理する方法の1つは、HTTP接続を可能な限り早く閉じることです。ベストプラクティスの1つは、フローの最初のカードとして API Connector Closeカードを追加することです。これにより、Workflowsエンジンは呼び出し元（HTTPクライアント）へのHTTP接続を即座に解放できます。その後、Workflowsエンジンはフローの残りの部分を非同期で処理します。「Close」を参照してください。
もう1つのベストプラクティスは、Call Flow AsyncカードとFlow Control Return Rawカードを組み合わせて使用することです。これにより、処理の動作を非同期に開始でき、HTTP応答に対して粒度の細かいコントロールが可能になります。「Call Flow Async」と「Return Raw」を参照してください。
同期フローを単純で高速に維持
クライアントが同期応答を必要とするときは、フローのアーキテクチャに十分な注意を払い、不要なレイテンシーやタイムアウトのリスクが生じないようにしてください。
-
外部ネットワーク呼び出しは避けます。呼び出しには、外部のサービスタスクでデータの処理に要する時間を含めなくても、数百ミリ秒のレイテンシーが発生する可能性があります。外部呼び出しはコネクターカードとHTTPカードで発生します。外部ネットワーク呼び出しが必要なときは、ヘルパーフローを作成し、Call Flow Asyncカードを使って同期フローから呼び出しを排除します。
-
応答の準備が整ったら、ただちに返します。フローの他の部分が処理を続けている間に、API Connector Closeカードを使用して値を返すことができます。
Workflowsエンジンの有効な利用
Workflowsエンジンでは、少数の大きなアクションより、多数の小さなアクションの方が効率的に実行されます。過剰な量のメモリを使用するフローは、システムリソースを保護するために制限または停止されることがあります。フローのパフォーマンスを向上し、メモリ不足、調整、実行の遅延、実行のスタック、その他の問題を回避するための重要な技法があります。
ヘルパーフローを使用して大きな処理ジョブを分割
複数の非同期フローを構築する際に、Workflowsエンジンはフローが可能な限り早く完了するように、作業をインテリジェントにスケジューリングします。親フローから行う非同期作業が大量に存在する場合、Call Flow Asyncカードの使用がベストプラクティスになります。このカードは、親フローの処理を続けながら、入力に指定されたヘルパーフローをエンジンで同時に実行します。
大量のアイテムのリストがあり、リストの各アイテムを処理する場合、For Each - Ignore Errorsカードの使用がベストプラクティスになります。このカードはリストを受け付け、そのリストの各アイテムについてヘルパーフローを実行し、オプションとして同時並列処理も行います。カード名はエラーの無視を暗示しますが、これは親フローから見た場合にのみ該当します。エラーはヘルパーフロー内で処理できます。「For Each - Ignore Errors」を参照してください。
複雑なエラー処理ブロックは避ける
複雑なエラー処理が原因で解析エラーが発生することを避けるために、OktaではIf Errorブロックのネスト数を3までに制限することをお勧めします。
大きなセットのフィルタリング
リストのアイテムの一部だけを処理する場合、ヘルパーフローを早期に停止する代わりに、Filterカードを使ってフィルタリングを行います。「Filter」を参照してください。
単一の大きなフローですべての処理を行うよりも、ヘルパーフローの方が好ましい方法ですが、ヘルパーフローの作成と実行がオーバーヘッドになることに留意してください。処理を必要としないジョブではヘルパーフローの作成を避けられれば、より効率的にフローを実行できます。
ヘルパーフローにリストを渡すことを避ける
アイテムのリストに対して操作を行い、For Eachカードを使用するときは、［With the following values（次の値を使用）］セクションを使ってヘルパーフローに必要なデータのみを渡します。個別のアイテムを取り出すインターフェイスにより、繰り返し処理を行うリストから個別のデータアイテムを取り出して、渡すことができます。たとえば、ユーザーのリストに対して操作を行う場合、ヘルパーフローにはユーザーオブジェクト全体ではなく、単一ユーザーの必要フィールドのみを渡します。
可能な限りストリーミングアクションを使用
ストリーミングアクションは結果のリストを受け取り、各アイテムについてヘルパーフローを自動的に非同期で実行します。この処理は最適化されているため、親フローはデータをページ単位で処理し、メモリ消費量を抑えてヘルパーフローを作成できます。
ストリーミングでない結果セットのオプションを使用すると、フローメモリの使用が増えることに留意してください。［Resuts Set（結果セット）］フィールドにStream Matching Recordsオプションがあるカードは、ストリーミングアクションをサポートしています。Oktaコネクタ用のFind Users、List Users with Search、List Users Assigned to Applicationsアクションカードはリストを返し、ストリーミングをサポートしています。「ヘルパーフローを使ったレコードのストリーミング一致」を参照してください。