従来および拡張 Apex インターフェースの違い

どちらのインターフェースでも、1 つのメソッド evaluate(event) が定義されます。このメソッドは、どちらのインターフェースでも同じように機能し、イベントを評価してトランザクションセキュリティポリシーをトリガするかどうかを判断します。どちらの実装でも、evaluate() メソッドをコーディングして、ポリシーがトリガされる場合は true、トリガされない場合は false を返すようにします。これは類似点ですが、次は違いを見てみましょう。

EventCondition.evaluate(event) の event パラメータのデータ型は sObject です。これは開発者に知られている標準の Salesforce API オブジェクトです。sObject を使用すると、Apex クラスのコーディング時の柔軟性が向上します。sObject を使用するには、まず、トランザクションセキュリティポリシーをサポートするイベントオブジェクトのいずれか (ApiEvent や ReportEvent など) に sObject をキャストします。ただし、注意が必要です。sObject を間違ったイベントオブジェクトにキャストすると、ポリシーが評価に失敗します。たとえば、ポリシーが ApiEvent に基づいているのに、sObject を ReportEvent にキャストすると、ポリシーは実行時に失敗します。

拡張ポリシーでは、イベントオブジェクトの項目を使用してイベントを評価するための条件を追加します。イベントオブジェクトのドキュメントは公開されているため、API ドキュメントに目を通せば、条件に必要な項目を簡単に見つけることができます。たとえば、ApiEvent はユーザの API コールを監視します。その QueriedEntities 項目に、ユーザが照会した特定のオブジェクト (Account、Lead など、カスタムオブジェクトも) が含まれます。この項目を使用すると、ユーザが Account オブジェクトを照会したかどうかを判断する Apex コードを簡単かつ自然に記述できます。

1apiEvent.QueriedEntities.contains('Account'))

上記のコードスニペットが contains を使用していることに気が付きましたか? API イベントが複数のオブジェクトを照会する場合、QueriedEntities 項目には、オブジェクト名のカンマ区切りリストが含まれるため、equals ではイベントが見落とされる可能性があります。この動作は、QueriedEntities 項目を持つリアルタイムイベント監視イベントオブジェクトに適用されます。

上記の例は、TxnSecurity.EventCondition インターフェースの別の利点を示しています。それは、従来のフレームワークでサポートされている 5 つのオブジェクト (Lead、Contact、Opportunity、Account、Contact) だけでなく、任意の Salesforce オブジェクトに対するユーザアクティビティを追跡できることです。ただし、この機能は重要な影響を及ぼします。拡張ポリシーは、従来のポリシーよりも頻繁に実行されます。この動作は、Salesforce がすべてのレポート操作と API クエリに対してすべての拡張ポリシーを評価するために発生します。

では、拡張インターフェースの利点を明らかにするために、従来のインターフェースのしくみを簡単に確認しましょう。従来のフレームワークでは、PolicyCondition.evaluate(event) の event パラメータのデータ型は、TxnSecurity.Event です。これは、プロパティを使用するイベントに関する情報が含まれる特殊なクラスです。値が数値または Boolean であっても、すべてのプロパティ値は String です。イベント情報の多くは、data プロパティに含まれます。これは Map<String,String> 型で、実行時に名前-値のペアが入力されます。実行時のこの Map の内容は、評価されるイベントの種別に応じて異なります。そのため、内容は標準ではなく、クラスをコードするときにその��造はわかりません。こうした理由から、イベントデータを取得する Apex コードは乱雑で入り組んだものになりがちです。

TxnSecurity.EventCondition インターフェースでは、いくつかの利点が追加されています。

• evaluate メソッドは汎用的な sObject パラメータを取り込んで、イベントオブジェクトにキャストできるため、1 つの Apex クラスが複数のイベントを処理するようにプログラミングできます。
• TxnSecurity.AsyncCondition インターフェースも実装することで、従来のポリシーを実装するクラス内で非同期 Apex コールを簡単に実行できます。
• 開発者コンソールで EventCondition の実装を記述するときに、オートコンプリートを使用できます。PolicyCondition を使用する場合、有用なデータのほとんどが data Map<> プロパティ内にあり、実行時に入力されるため、オートコンプリートはうまくいきません。

  

• リアルタイムイベント監視イベントオブジェクトのデータモデルには一貫性があります。そのため、より汎用的な Apex を記述して、複数のイベント種別に適用することができます。たとえば、Salesforce でイベント種別が追加され、それを既存のセキュリティポリシーに追加するとします。拡張フレームワークでは、Apex コードに数行追加するだけですむでしょう。従来のフレームワークでは、新しい Apex クラスを記述する必要があります。