ポーリング監視イベント

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

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

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

ポーリング監視の概要

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

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

たとえば、Oktaの管理者は、自社がWorkdayに追加した新しい従業員に関する通知を毎日受信するためのポーリング監視をセットアップできます。
カーソルと呼ばれる、保存された増分値を設定します。この保存値は、スケジュールされたポーリング監視が実行される度に更新されます。Okta Workflowsでは、この保存値（通常はタイムスタンプ）はカーソル（Cursor）関数カードを使用して更新およびアクセスされます。フローはGETリクエストを作成するたびに、この値を使用してリモートサービスからレコードを取得します。実装の詳細については、カーソル関数カードを参照してください。
イベントトリガーをスケジュールします。ポーリング監視は、スケジュールされたフローと同じ構成ダイアログを使用します。ポーリング監視を設定して、5分～30日の任意の頻度でリモートサービスを呼び出すことができます。
ペイロードを取得します。Oktaは、フィルタリングされたクエリを含むGET要求をリモートサービスに送信し、リモートサービスから指定された時間枠内に発生したレコードのペイロードが返されます。
ペイロードを処理します。受信側アプリは、GET要求によって返されたレコードを処理します。JSONペイロードを解析し、イベントフローを完了します。

ペイロードを処理する場合、2つの側面を考慮してください。
- 要求の集約：受信ペイロードは、収集されたアイテムのバッチとして受信されます。
- 要求のバッチ処理：受信ペイロードが収集バッチとして届いても、イベントフローは各アイテムを個別に処理することも、バッチ全体を1つのアイテムとして処理することもできます。
ポーリング監視の実行モードを有効化するを参照してください。

ユースケース

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

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

作成されたレコード

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

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

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

更新されたレコード

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

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

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

削除されたレコード

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

注:

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

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

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

APIクエリのbody（本文）で返されたusersのリストがPluck関数カードに渡されます。
Pluckカードは、usersリスト内のIDキーを使用して、現在のユーザーID値のリストを出力として返します。このcurrentUserListには、リモートシステムでアクティブなユーザーのみが含まれます。
カーソルオブジェクト（フローのポーリングモニター（Polling Monitor）カードからドラッグ）には、userListの場所にあるユーザーのリストも含まれています。このCursor Propertiesオブジェクトはオブジェクト（Object） - Get関数カードの入力です。この関数カードは、リモートシステム上の既知のすべてのユーザーを含む previous list of IDsというリストオブジェクトを生成します。
比較操作では、フローは以前のIDリストと現在のIDリストの違いを比較します。現在のリストに見つからないIDは、Deleted User IDsという新しいリストに送信されます。この出力リストは、リモートシステムに存在しなくなったすべてのID値で構成されます。
次に、フローはフロー制御（Flow Control） - カーソル（Cursor）カードに渡すオブジェクトを作成します。オブジェクト（Object） - 構築関数カードは、現在のタイムスタンプと新しく作成された現在のユーザーのリストの両方を入力として受け取ります。
outputオブジェクトは、カーソルカードのプロパティ（Properties）フィールドに渡されます。カーソルオブジェクトは、このポーリングモニターの次回の実行のためにメタデータとして保存されます。
ただし、Deleted User IDsリストは、ポーリングモニターユーザーに返されるオブジェクトのリストとしてフォーマットする必要があります。これを行うに、フローにリスト（List） - マップ関数カードが含まれています。このケアは、Deleted User IDsリスト内の各エントリに対して、Reshape Deleted Usersと呼ばれる小さなヘルパーフローを呼び出します。

Reshape Deleted UsersヘルパーフローはDeleted User IDsリスト内の各項目を処理します。フローに渡される各ID値は、オブジェクト（Object） - 構築カードに送信されます。これにより、各ユーザーに対して、{ "User ID" : "ID" }という形式の一意のオブジェクトが作成されます。
Deleted User IDsリスト内の各エントリが処理されると、フローはそれをオブジェクトのReshaped Outputsリストに追加します。
ヘルパーフローが完了すると、オブジェクトのReshaped Outputsリストがフロー制御（Flow Control） - 返答出力（Return Outputs）カードに渡されます。これは、ポーリングモニター（Polling Monitor）カードで定義された出力と一致し、ポーリングモニターの実行を完了します。ユーザーは、リモートサービスから削除されたユーザーの予想されるリストを受け取ります。