ポーリング監視イベント

ポーリング監視は、Webhookイベントフローのサポートが利用できない、または望ましくない場合に、オンラインサービスがスケジュールに基づいて情報を交換するためのメカニズムです。

リモートサービスで特定のイベントが発生すると、そのイベントは追跡されて記録されます。そして、スケジュールされたポーリング監視フローが実行されると、Oktaがリモートサービスにクエリを実行し、リモートサービスが最後に呼び出された後に記録されたすべての情報を取得します。

このメカニズムは、プロセスを自動化し、手動での継続的な介入を必要とすることなく、さまざまなシステムを同期させるためによく利用されます。

ポーリング監視の概要

ポーリング監視フローの構成は、いくつかの一般的な手順から成ります。

  1. ポーリング監視をセットアップします。ポーリング監視は、スケジュールされた実行ごとに更新される時間ベースのフィルターを使用して特定のAPIリソースを呼び出すGET要求を作成します。

    たとえば、Oktaの管理者は、自社がWorkdayに追加した新しい従業員に関する通知を毎日受信するためのポーリング監視をセットアップできます。

  2. カーソルと呼ばれる、保存された増分値を設定します。この保存値は、スケジュールされたポーリング監視が実行される度に更新されます。Okta Workflowsでは、この保存値（通常はタイムスタンプ）はカーソル関数カードを使用して更新およびアクセスされます。フローはGETリクエストを作成するたびに、この値を使用してリモートサービスからレコードを取得します。実装の詳細については、カーソル関数カードを参照してください。

  3. イベントトリガーをスケジュールします。ポーリング監視は、スケジュールされたフローと同じ構成ダイアログを使用します。ポーリング監視を設定して、5分～30日の任意の頻度でリモートサービスを呼び出すことができます。

  4. ペイロードを取得します。Oktaはフィルタリングされたクエリを含むGET要求をリモートサービスに送信し、リモートサービスから指定された時間枠内に発生したレコードのペイロードが返されます。

  5. ペイロードを処理します。受信側アプリは、GET要求によって返されたレコードを処理します。JSONペイロードを解析し、イベントフローを完了します。

    ペイロードを処理する場合、2つの側面を考慮してください。

    • 要求の集約：受信ペイロードは、収集されたアイテムのバッチとして受信されます。

    • 要求のバッチ処理：受信ペイロードが収集バッチとして届いても、イベントフローは各アイテムを個別に処理することも、バッチ全体を1つのアイテムとして処理することもできます。

    「ポーリング監視の実行モードを有効化する」を参照してください。

ユースケース

ポーリングモニターイベントの最も簡単な実装は、保存されたタイムスタンプをリモートサービスのAPIへのクエリの一部として使用することです。このメソッドは、保存されたタイムスタンプ以降に作成または更新されたすべてのレコードを返します。

タイムスタンプクエリがサポートされていない場合は、すべてのレコードを取得し、コレクションを手動でフィルター処理する必要がある場合があります。また、削除されたユーザーを追跡するなど、より複雑なシナリオでは、ポーリングモニターの実行間で追加のメタデータを保持する複雑なカーソルオブジェクトが必要になる場合があります。

作成されたレコード

このユースケースでは、APIに送信されるフィルタークエリには、開始日（前回の実行タイムスタンプ）と終了日（現在の実行タイムスタンプ）が含まれます。APIは、指定された期間内にリモートサービスによって追加されたすべてのレコードを返します。

ポーリングモニターのフローは次の例のようになります。startDateは、Cursorから取得された前回の実行タイムスタンプです。endDateは現在の時刻です。これらの値はComposeカードに追加され、クエリ文字列が作成されます。文字列はConstruct（構築）カードに送信され、Call Flowカードのクエリ入力が作成されます。

クエリは、Call Flowカードのbody（本文） 内のバッチ オブジェクトとしてレコードを返し、それが リターンオブジェクトカードに渡されます。カーソルカードは、ポーリングモニターイベントの次回の実行で使用するために新しいタイムスタンプで更新されます。

更新された記録

作成されたレコードのポーリングと同様に、APIがlastUpdatedタイムスタンプを使用したフィルタリングをサポートしている場合は、更新されたユーザーを見つけるために前後のタイムスタンプを指定できます。

このユースケースのフローの唯一の違いは、構成関数カード文字列がクエリにcreatedではなくupdatedを使用することです。

実行されると、ポーリングモニターは最後の更新以降のすべてのユーザー変更を取得します。

削除されたレコード

より高度なシナリオでは、ポーリングモニターを使用して、リモートサービスで削除されたユーザーを追跡します。次の例では、カーソルをオブジェクトとして使用し、実行を追跡するためのタイムスタンプとともにユーザー情報を保存する、このユースケースを処理する1つの方法について説明します。

カーソルのサイズ制限は10KBです。カーソルを使用して大量のデータを保存すると、ユーザーがフローを再度有効にしてカーソルをリセットしなければならないエラーが発生する可能性があります。

このポーリングモニターイベントカードを構成すると、カードの出力は静的出力グループオブジェクトとして設定されます。返される削除済みユーザーオブジェクト内の各ユーザーは、テキスト値としてユーザーIDを使用して定義されます。

APIクエリは/v1/usersエンドポイントをポーリングして、リモートシステム上の現在のすべてのユーザーを含むオブジェクトのリストを返します。情報が返された後、フローは次の手順を実行します。

  1. APIクエリのbody（本文）で返されたユーザーのリストは、Pluck関数カードに渡されます。

  2. Pluckカードは、usersリスト内のIDキーを使用して、現在のユーザーID値のリストを出力として返します。このcurrentUserListには、リモートシステムでアクティブなユーザーのみが含まれます。

  3. カーソルオブジェクト（フローのポーリングモニターカードからドラッグ）には、userListの場所にあるユーザーのリストも含まれています。このカーソルプロパティオブジェクトはオブジェクト - GET関数カードの入力です。この関数カードは、リモートシステム上の既知のすべてのユーザーを含む previous list of IDsというリストオブジェクトを生成します。

  4. 比較操作では、フローは以前のIDリストと現在のIDリストの違いを比較します。現在のリストに見つからないIDは、削除されたユーザーIDという新しいリストに送信されます。この出力リストは、リモートシステムに存在しないすべてのID値で構成されます。

  5. 次に、フローはフロー制御 - カーソルカードに渡すオブジェクトを作成します。オブジェクト - 構築関数カードは、現在のタイムスタンプと新しく作成された現在のユーザーのリストの両方を入力として受け取ります。

  6. 出力オブジェクトは、カーソルカードのProperties（プロパティ）フィールドに渡されます。カーソルオブジェクトは、このポーリングモニターの次回の実行のためにメタデータとして保存されます。

  7. ただし、削除されたユーザーIDリストは、ポーリングモニターユーザーに返されるオブジェクトのリストとしてフォーマットする必要があります。これを行うには、フローにリスト - マップ関数カードが含まれます。このケアは、削除されたユーザーIDリスト内の各エントリに対して、削除されたユーザーの再形成と呼ばれる小さなヘルパーフローを呼び出します。

    削除されたユーザーの再形成ヘルパーフローは、削除されたユーザーIDリスト内の各項目を処理します。フローに渡される各ID値は、オブジェクト - 構築カードに送信されます。これにより、各ユーザーに対して、{ "User ID" : "ID" }という形式の一意のオブジェクトが作成されます。

  8. 削除されたユーザーIDリスト内の各エントリが処理されると、フローはそれをオブジェクトの再形成された出力リストに追加します。

  9. ヘルパーフローが完了すると、オブジェクトの再形成された出力リストがフロー制御 - 戻り出力カードに渡されます。これは、ポーリングモニターカードで定義された出力と一致し、ポーリングモニターの実行を完了します。ユーザーは、リモートサービスから削除されたユーザーの予想されるリストを受け取ります。