説明
変更データキャプチャは、Salesforceレコードの変更（作成、更新、削除、削除取り消しなど）をほぼリアルタイムで取得できる機能です。変更データキャプチャは、イベントバスに変更イベントを最大3日間保持するため、障害発生時点からデータレプリケーションを再開できます。また、変更データキャプチャは、カスタムトリガーやコードを必要とせずに、外部システムとデータの変更を同期するための一貫性と信頼性のある方法も提供します。参考：Salesforce統合アーキテクチャデザイナーリソースガイド、24ページ

エージェントが顧客に通知するために、新規に作成された銀行口座IDをリアルタイムで受信する必要があることは、同期依存関係を意味します。コアバンキングシステムが口座作成を確認し、生成されたIDを返すまで、エージェントはビジネスプロセスを完了できません。
このユースケースには、リクエスト＆リプライパターンが適切な推奨パターンです。このパターンでは、以下のことが行われます。
* リクエスト: Salesforce は、顧客のデータを含む同期コールアウト (REST または SOAP) をコアバンキング システムに送信します。
* 待機: Salesforce スレッドは開いたままになり、外部システムがリクエストを処理するのを待機している間、ユーザー インターフェースには通常、読み込みインジケーターが表示されます。
* 返信: コアバンキングシステムから新しいアカウント ID が返され、Salesforce のサポートエージェントにすぐに表示されます。
オプションA（プラットフォームイベント）とC（ストリーミングAPI）は、非同期のイベントドリブンパターンです。スケーラビリティは高いものの、エージェントの画面を新しいIDによる非同期コールバックまで待機させるネイティブな方法がないため、この特定の「即時」要件には適していません。リクエストとリプライは、エージェントが顧客とのやり取りを完了するために必要な情報を、単一の連続したフローで確実に取得できるようにします。

API要件が異なる複数の外部サービスプロバイダー（異なる地域の配送業者など）を扱う場合、最もスケーラブルなアーキテクチャの選択肢は、エンタープライズ・サービス・バス（ESB）またはミドルウェア・ソリューションです。このシナリオは、典型的な「オーケストレーション」と「変換」のユースケースを示しています。
ESB は次の点で優れています:
1. ルーティング/仲介: ESB は、Salesforce から単一の標準化されたリクエスト (「配送料の取得」) を受信し、ビジネス ロジックを使用して、どの地域の運送業者の API を呼び出す必要があるかを決定できます。
2. 変換：運送業者ごとに異なるXMLまたはJSONスキーマを持つ可能性があります。ESBは、Salesforceから送信された共通データモデルを、選択した運送業者が要求する特定の形式に変換できます。
3. プロトコル ブリッジング: 1 つの出荷元が SOAP を使用し、別の出荷元が REST を使用している場合、ESB がこれらの技術的な違いを処理し、Salesforce が単一の簡素化されたインターフェースで対話できるようにします。
オプションA（Apex REST）では、Salesforceチームが新しい配送業者を追加するたびにカスタムコードを管理する必要があり、技術的負債の増加とメンテナンスの課題につながります。オプションCは誤りです。ESBはバックエンドのインフラストラクチャコンポーネントであり、ユーザーインターフェースツールではないためです。
Northern Trail OutfittersはESBを活用することで、Salesforceを配送業者のAPIの複雑さから切り離しています。この「ハブアンドスポーク」モデルにより、将来的に新たな地域の配送業者を追加する場合でも、Salesforceにコード全体をデプロイする必要はなく、ESB内での設定のみで済みます。これにより、グローバルな小売事業に必要な俊敏性とアーキテクチャの分離が実現します。