2.5 ユーザー・アクティビティ・ランタイムAPIコールの順序の理解

この項では、OARMがユーザー・アクティビティを処理し、クライアント・アプリケーションからAPI操作の値を提供する方法を示します。

次に、APIコールの一般的な順序を示します。

1. createSession (セッションPOST API)を使用してOARMセッションを作成します。これにより、カスタム・ユーザー・アクティビティの作成APIに必要なrequestIdが作成されます。
2. 次に、クライアント・アプリケーションは、(ステップ1で作成されたrequest IDを使用する)カスタム・ユーザー・アクティビティの作成APIを呼び出して、カスタム・ユーザー・アクティビティに関する情報を提供します。
3. レスポンスからトランザクションIDを取得する前に、カスタム・ユーザー・アクティビティの作成のステータスが成功であることを確認します。
4. クライアントは、processRules APIをコールして、トランザクション・チェックポイントに関連する不正なポリシー/ルールをトリガーできます。このステップにより、該当するチェックポイントに関連しているポリシーやルールを実行するルール・エンジンがトリガーされ、関連したルールがトリガーされた場合はアラートが作成されます。このAPIの出力は、ポリシーやルールによって返される一連のアクションおよびリスク・スコアです。
5. processRules APIコールの結果に基づき、クライアント・アプリケーションは、カスタム・ユーザー・アクティビティの更新APIをコールしてトランザクション・ステータスを設定するか、既存のトランザクションのデータを更新するかを選択できます。

   ノート:

   カスタム・ユーザー・アクティビティのステータスが更新されていることを確認します。これは、一部のルールで前のトランザクション(ユーザー・アクティビティ)のステータスがデータ・ポイントとして使用される可能性があるためです。
6. 場合によっては、クライアント・アプリケーションは、最初のトランザクション前のチェックポイントと、トランザクションの作成後に実行する必要のあるポリシーまたはルールが割り当てられているトランザクション後のチェックポイントを使用して、processRules APIを実行するように選択できます。これは、アプリケーションでトランザクションが実行に適しているかどうかを特定し、実行後に必要な追加のルールを把握するのに役立ちます。