設問
Salesforce のお客様は、Platform Events を用いて外部の AI システムと連携しています。AI システムは Salesforce が受信した各リードに対して「予測スコア」を提供します。予測スコアが受信されると、そのリード情報は Platform Events に保存され、他の処理に利用されます。しかし、本番環境へ展開後、Platform Events の Apex トリガーは常に失敗していました。この連携を監視するために、統合コンサルタントはどの監視を検討すべきだったでしょうか？
選択肢
A. パフォーマンスを監視するために、プラットフォーム イベント トリガーのデバッグ ログを設定します。
B. Salesforce インスタンス全体で、1 時間あたりに作成されるプラットフォーム イベントの制限を監視します。
C. プラットフォーム イベント定義がリード定義と一致することを検証します。
D. Salesforce で作成されたリードの量を監視します。
解答
B. Salesforce インスタンス全体で、1 時間あたりに作成されるプラットフォーム イベントの制限を監視します。
解説
A. パフォーマンスを監視するために、プラットフォーム イベント トリガーのデバッグ ログを設定します。
不正解です。
デバッグログは事後的な診断ツールです。プラットフォームイベントトリガーのデバッグログは「Automated Process」によって作成されますとあり、失敗後の原因調査には有用ですが、事前の監視には適していません。
B. Salesforce インスタンス全体で、1 時間あたりに作成されるプラットフォーム イベントの制限を監視します。
正解です。
トリガー/PBで処理できる公開イベント数の制限は1時間あたり100,000。トリガーの継続的な失敗は、この時間あたりの制限超過が原因である可能性が高く、事前に監視すべきでした。
C. プラットフォーム イベント定義がリード定義と一致することを検証します。
不正解です。
定義の検証は開発時の作業です。プラットフォームイベントが正しく定義されていることを確認とありますが、本番環境での継続的な失敗には制限監視が必要です。
D. Salesforce で作成されたリードの量を監視します。
不正解です。
リード作成量の監視では根本原因を把握できません。各公開イベントは時間あたりの公開制限に対して1単位としてカウントされます。問題はイベント公開制限であり、リード数ではありません。
第28問
こちらをクリック
