設問
下の図では、Salesforce 組織、ミドルウェア、履歴データストアが相互に接続されています。
履歴レコードは Salesforce からアーカイブされ、履歴データストア（2,000 万件以上のレコードを格納し、増加中）に移動され、検索クエリのパフォーマンスに合わせて最適化されています。Salesforce を使用するコールセンターのエージェントは、まれに発生する特殊なケースを確認する際に、送信されたケースに関連する過去のケースデータへの閲覧アクセスを要求しています。
宣言的（コード不要）の構成を最大限に活用するには、どのようなメカニズムとパターンが推奨されますか？
選択肢
A. リクエストと返信パターンを備えた ESB ツールを使用して、ESB エンドポイントへのリアルタイム Apex コールアウトを実行し、ケース オブジェクトに関連するカスタム Lightning コンポーネントで履歴データを取得して表示します。
B. Fire and Forget パターンを備えた ESB ツールを使用して、要求された履歴データのプラットフォーム イベントを公開します。
C. バッチ データ同期パターンを備えた抽出、変換、ロード (ETL) ツールを使用して、履歴データを Salesforce およびケース オブジェクトに関連するカスタム オブジェクト (履歴データ) に移行します。
D. データ仮想化パターンを備えた ESB ツールを使用して OData エンドポイントを公開し、Salesforce Connect を使用してケース オブジェクトと一緒に外部オブジェクトを消費および表示します。
解答
D. データ仮想化パターンを備えた ESB ツールを使用して OData エンドポイントを公開し、Salesforce Connect を使用してケース オブジェクトと一緒に外部オブジェクトを消費および表示します。
解説
A. リクエストと返信パターンを備えた ESB ツールを使用して、ESB エンドポイントへのリアルタイム Apex コールアウトを実行し、ケース オブジェクトに関連するカスタム Lightning コンポーネントで履歴データを取得して表示します。
不正解です。
ApexやLightningコンポーネントはコード開発が必要であり、「宣言型の構成を最大限に活用」という要件に反します。カスタム開発は保守コストも高くなります。
B. Fire and Forget パターンを備えた ESB ツールを使用して、要求された履歴データのプラットフォーム イベントを公開します。
不正解です。
Fire and Forgetやプラットフォームイベントは一方通行の非同期通知に適しています。エージェントがデータを「閲覧アクセス」する要求-応答シナリオには適していません。
C. バッチ データ同期パターンを備えた抽出、変換、ロード (ETL) ツールを使用して、履歴データを Salesforce およびケース オブジェクトに関連するカスタム オブジェクト (履歴データ) に移行します。
不正解です。
2,000万件超の履歴データをSalesforceに移行すると、ストレージコストが膨大になり、管理も複雑になります。「時折」アクセスするデータには非効率的です。
D. データ仮想化パターンを備えた ESB ツールを使用して OData エンドポイントを公開し、Salesforce Connect を使用してケース オブジェクトと一緒に外部オブジェクトを消費および表示します。
正解です。
この方法は、大量の外部データをSalesforceにコピーせず、必要な時にリアルタイムで参照できます。Salesforce ConnectはODataをサポートし、宣言的な設定で外部データをSalesforceオブジェクトのように扱えるため、要件に最適です。
第18問
こちらをクリック
