設問
エンタープライズアーキテクトがSalesforce統合アーキテクトに、次の点（図と説明を参照）を確認し、エンタープライズシステムのすべての制約とSalesforceプラットフォームの制限を慎重に考慮した上で推奨事項を提供するように依頼しました。
約3,000人の電話販売員がSalesforce Lightning UIを同時に使用して、顧客が対象となるオファーを受ける資格があるかどうかを確認しています。このサービスを提供する資格システムは複数あり、外部でホストされています。ただし、現在の応答時間は、処理して返すのに最大90秒かかる場合があります（将来的に応答時間を短縮するための議論はありますが、確約されていません）。
これらの資格システムには、ESB（MuleSoft）を介してオーケストレーションされたAPIを通じてアクセスできます。Salesforceからのすべてのリクエストは、顧客のAPIゲートウェイ層を通過する必要があり、APIゲートウェイは9秒後にリクエストをタイムアウトするという制約を課します。
どの3つの推奨事項を行う必要がありますか？（3つ選択してください。）
選択肢
A. 継続コールアウトを使用して、ページの読み込み時にSalesforce Lightning UIから適格性確認リクエストを実行します。
B. キャッシュ/状態管理を備えたESB（Mule）は、外部システムから取得可能な場合にリクエストIDまたは応答を返します。
C. Lightning UIからMule経由で外部システムへの同期Apexコールアウトを推奨し、APIゲートウェイタイムアウト時にポーリングを実装します。
D. Salesforceでリモートコールインを介してプラットフォームイベントを作成し、Muleが応答を受信したときにLightning UIのempAPIを使用して3,000人の同時ユーザーにサービスを提供します。
E. ESBから受信したリクエストIDを渡す「更新の確認」ボタンを実装します（ユーザーのアクションが必要）。
解答
A. 継続コールアウトを使用して、ページの読み込み時にSalesforce Lightning UIから適格性確認リクエストを実行します。
B. キャッシュ/状態管理を備えたESB（Mule）は、外部システムから取得可能な場合にリクエストIDまたは応答を返します。
E. ESBから受信したリクエストIDを渡す「更新の確認」ボタンを実装します（ユーザーのアクションが必要）。
解説
A. 継続コールアウトを使用して、ページの読み込み時にSalesforce Lightning UIから適格性確認リクエストを実行します。
正解です。
継続（Continuation）クラスは長時間実行されるリクエストに対応でき、5秒以上続く同期リクエストのApex制限にカウントされません。継続は最大120秒のタイムアウトを設定でき、APIゲートウェイの9秒タイムアウト後もバックグラウンドで処理を継続できます。
B. キャッシュ/状態管理を備えたESB（Mule）は、外部システムから取得可能な場合にリクエストIDまたは応答を返します。
正解です。
ESBレイヤーでの状態管理により、APIゲートウェイの9秒タイムアウトと外部システムの90秒応答時間の差を吸収できます。MuleSoftは即座にリクエストIDを返し、バックグラウンドで外部システムからの応答を待機できます。
C. Lightning UIからMule経由で外部システムへの同期Apexコールアウトを推奨し、APIゲートウェイタイムアウト時にポーリングを実装します。
不正解です。
同期コールアウトの最大タイムアウトは120秒ですが、APIゲートウェイが9秒でタイムアウトするため、同期コールアウトは失敗します。ポーリングの実装も同期的なアプローチでは効果的ではありません。
D. Salesforceでリモートコールインを介してプラットフォームイベントを作成し、Muleが応答を受信したときにLightning UIのempAPIを使用して3,000人の同時ユーザーにサービスを提供します。
不正解です。
プラットフォームイベントには2,000の同時サブスクライバー制限があり、大規模なユーザー数でempApiを使用すると同時cometDクライアント制限に達します。3,000人の同時ユーザーには対応できません。
E. ESBから受信したリクエストIDを渡す「更新の確認」ボタンを実装します（ユーザーのアクションが必要）。 正解です。
ユーザーエクスペリエンスは理想的ではありませんが、技術的制約を考慮すると実現可能な解決策です。ユーザーは必要に応じて結果を確認でき、システムリソースを効率的に使用できます。
第25問
こちらをクリック
