Okta Workflowsは、柔軟性と自由度の高いフロー設計を実現した非常に強力なツールです。ただし、フローの設計方法について理解することは重要です。回復力のある設計の考え方を無視してフローを作成すると、将来のトラブルシューティングや修復、復旧が困難になります。

大まかに説明すると、予期しない状況、障害、エラーの発生後に再試行または再開できるようにWorkflowsを構築すると、影響が軽減されます。これを実装する最適な方法はユースケースによって異なりますが、どのような場合でも、さらなる影響を及ぼすことなく再試行または再開できるようにすることが中心となります。

以下では、Workflowsの設計時に考慮すべき回復力のある設計方法の例をいくつか紹介します。

これらの推奨事項はすべての状況に当てはまるわけではありませんが、より優れた回復力を持つようにフローを再設計する際のベストプラクティスの一般的な考え方となります。

• Okta Workflows

注：2025年2月以降 - 顧客がレート制限を超過した場合、Okta APIレート制限の厳格化により、Oktaコネクターカードの実行時間が長くなる可能性があります。

• 顧客がOktaコネクターを介してレート制限に達した場合、Oktaコネクターの基盤となる再試行ロジックは、レート制限がリセットされる推定時間まで待機するようになりました。429エラーのバーストにより、実行時間が長くなる可能性があります。
  • レート制限リセット時間
  • システム制限 - レート制限

推奨される解決策：

アイテムを大きなバッチで一度に処理するのではなく、小さなバッチで反復処理する

• 大きなバッチ（数百、数千、あるいはそれ以上）のレコードをすべて一度に反復処理する複雑な処理では、何か予期しないことが発生すると、プロセス全体が止まってしまう恐れがあります。これは不健全な設計構造であり、問題が発生した場合は復旧が困難です。
• そうではなく、予期しないことが発生した場合に、トラブルシューティングや再試行、停止が容易にできるフロー設計にします。

たとえば、フローで10,000件のユーザーを反復処理する場合、ユーザーを小さなバッチに分け、フローで処理が完了したら対象のユーザーを「処理済み」とマークするようにします。このようにすると、あるバッチで問題が発生しても、残りのバッチは引き続き処理されます。また、Oktaユーザープロファイルのカスタム属性で「処理済み」とマークしているため、再試行が必要なユーザーがわかります。

可能な場合は、更新済みまたはフィルタリング済みのアイテムのリストを取得して反復処理する

• 100件のレコードを処理する際にリストの途中で予期しない問題が発生した場合、処理済みのレコードに基づいてリストをフィルタリングできれば、一からやり直す必要はありません。

たとえば、アプリケーションのリストからユーザーを削除するフローがあり、リストの途中で処理が止まってしまった場合、次にそのユーザーに対してフローを実行するときに更新済みのアプリケーションリストを取得するようにフローを構築します。こうすることで、問題のユーザーに対して手動でフローをトリガーし、元のリスト全体ではなく、引き続き削除する必要があるアプリケーションでのみ処理を行うことができます。

イベントベースのフローとスケジュールされたフローを組み合わせて実装する

• イベントベースのフローはすべてを正常に処理するよう設定されていますが、随時実行されるスケジュールされたフローがあり（通常は1日に1回）、イベントベースのフローで「止まって」しまったものを取得して復旧させます。

たとえば、グループに追加されたユーザーをモニタリングするフローの場合、イベントベースのフローで対象のユーザーが処理された後にグループから削除されるようにすることができます。実行が止まってしまった場合、グループからユーザーが削除されることはありません。その後、夜間にスケジュールされたフローでグループに残っているユーザーを取得し、そのユーザーを処理して、処理が正常に行われるようにします。

［List operation（リスト操作）］の［concurrency（同時並行処理）］の値を慎重に使用して、スループットを向上させる

• ［For Each（それぞれ）］カードなどの同時並行処理が1に設定され、ヘルパーの実行が［In Progress（進行中）］になっている場合、［For Each（それぞれ）］でリストの次のアイテムに移ることができません。この値を少し増やすと、状況は多少改善されます。

たとえば、［concurrency（同時並行処理）］を設定した［List operation（リスト操作）］を使用している場合、［concurrency（同時並行処理）］の値を1ではなく、2～5に設定します。これにより、いずれかのヘルパーフローの実行が進行中に止まってしまっても、リストの残りをヘルパーフローで引き続き処理できます。

注：この場合、親フローは引き続き実行されず、そのほかのヘルパーフローのみが実行されます。

注：［concurrency（同時並行処理）］の値を増やす場合は、複数のヘルパーフローが同時に実行されるため、レート制限（Oktaやそのほかのサービス）に注意してください。

RACEタイプの状態を緩和するためにWAIT FORを追加する

• ワークフローが他のプロセスと連携するシナリオでは、タスク間の依存関係を明確に定義することが不可欠です。アップストリームとダウンストリームのアクションが適切な順序で実行されるようにすることが重要です。そうしないと、誤った結果になる可能性があります。WAIT FORカードは、RACEタイプの条件を緩和するのに役立ちます。

例：

• ツールは、Okta API呼び出しを使用して新しいOktaユーザーを作成し、いくつかの後続のタスクを実行します。
• ユーザーの作成によってトリガーされるOkta Workflowにより、ユーザーが有効化され、アクティベーションメールが送信されます。

ワークフローがユーザーの有効化に失敗することがあるという問題が発生しました。調査の結果、これらの失敗の間、新しいユーザーは正しいステータスにならず、ツールによって開始されたプロセスはアクティブなままであることが明らかになりました。この問題を解決するには、ワークフローの最初のカードとしてWAIT FOR（10秒）を配置します。

関連資料

• Workflowsのシステム制限
• そのほかのWorkflowsのベストプラクティス