堅牢でスケーラブルな統合アーキテクチャを設計するには、Salesforce アーキテクトがまずデータフローの技術的な範囲と「配管」を定義する必要があります。
統合アーキテクチャのニーズを解決するための最も重要な詳細は次のとおりです。
* ソース システムとターゲット システム: 関係するシステムを特定することで、利用可能な API (REST、SOAP など) と必要なセキュリティ プロトコルが決まります。
* 方向性: 統合が単方向 (Salesforce から System X) か双方向かを知ることは、レコードのマスタリングを管理し、データ同期における「無限ループ」を回避するために不可欠です。
* データ量と変換の複雑さ: 大量のデータには、Bulk API による非同期バッチ処理が必要になる場合があります。また、複雑な変換 (カスタム外部 ID を Salesforce アカウント番号にマッピングするなど) には、MuleSoft などのミドルウェア レイヤーを「中枢神経系」として機能させる必要がある場合があります。
オプションAは、UI/UXとライセンスに焦点を当てています。これらはアーキテクチャ統合要件ではなく、プログラム全般に関する懸念事項です。オプションCはプロジェクト管理とガバナンスに焦点を当てています。これらは実行には重要ですが、リクエスト・リプライ・パターンとファイア・アンド・フォーゲット・パターンのどちらを選択するかの判断材料にはなりません。システム、データ方向、そして変換の複雑さに焦点を当てることで、アーキテクトはプラットフォームの制限内でビジネス要件を満たす適切なパターンとツールを選択できます。

回答Dは有効です。データの挿入とクエリの両方にBulk API 2.0を使用することで、1日に大量のデータの読み込みと抽出という要件を満たすことができます。Bulk API 2.0は、CSVファイルまたはJSONファイルのアップロードまたはダウンロードによって、数百万件ものレコードを非同期で作成、更新、削除、またはクエリできるRESTful APIです。Bulk API 2.0には、Bulk API 1.0に比べて以下のような利点があります。
これは、24 時間あたり 5,000 バッチという 1 日あたりの制限にはカウントされません。
クエリの PK チャンクをサポートしており、主キーに基づいて大規模なデータ セットを管理しやすいチャンクに自動的に分割します。
これにより、ジョブのライフサイクルが簡素化され、一括操作の実行に必要な API 呼び出しの数が削減されます。
回答Aは無効です。データの挿入にBulk API 2.0を使用し、データのクエリにREST APIを使用することは、1日に大量のデータを処理するのに最適なソリューションではありません。REST APIは、HTTPメソッドを使用して個々のレコードまたは少量のレコードのバッチを作成、更新、削除、またはクエリできる同期APIです。
REST API には、このユースケースでは次のようないくつかの制限と欠点があります。
これは、24 時間あたり 15,000 件の API リクエストという 1 日あたりの制限にカウントされます。
クエリの PK チャンク化はサポートされていないため、大規模なデータ セットではクエリのタイムアウトまたはヒープ サイズの制限を超える可能性があります。
一括操作を実行するには、Bulk API 2.0 よりも多くの API 呼び出しと処理時間が必要になります。
回答Bは無効です。データの挿入とクエリの両方にBulk API 1.0を使用することは、1日に大量のデータを処理するには現実的なソリューションではないためです。Bulk API 1.0は、XMLファイルまたはCSVファイルのアップロードまたはダウンロードによって、数百万件ものレコードを非同期的に作成、更新、削除、またはクエリできるSOAPベースのAPIです。Bulk API 1.0には、Bulk API 2.0と比較して、次のようないくつかの制限と欠点があります。
これは、24 時間あたり 5,000 バッチという 1 日あたりの制限にカウントされ、それぞれ 9,000 万件と 3,000 万件のレコードをロードして抽出するには不十分な可能性があります。
データ ファイルの JSON 形式はサポートされていないため、一部の外部システムやアプリケーションと互換性がない可能性があります。
ジョブのライフサイクルを管理し、エラーや再試行を処理するには、Bulk API 2.0 よりも多くの API 呼び出しと複雑な処理が必要になります。
回答Cは無効です。データの挿入にBulk API 1.0を使用し、データのクエリにREST APIを使用することは、1日に大量のデータを処理するのに適切または信頼できるソリューションではないためです。前述のように、Bulk APIとREST APIの両方が
1.0 および REST API には、統合のパフォーマンス、効率、およびスケーラビリティに影響を及ぼす可能性のある制限と欠点があります。

ユーザーが即時の確認を必要としない統合を設計する場合、アーキテクトは同期の「リクエスト・リプライ」パターンから非同期の「ファイア・アンド・フォーゲット」16または
「バッチ処理」パターン。このようなシナリオでは、最も重要なアーキテクチャ上の制約は、レイテンシ要件の定義です。
レイテンシは、統合ツールの技術的な選択を左右します。フルフィルメントシステムが高速ピッキングプロセスを開始するために、注文作成後数秒以内に処理する必要がある場合、アーキテクトはSalesforceアウトバウンドメッセージングまたはプラットフォームイベントによってトリガーされるApexコールアウトを選択するでしょう。システムが1時間に1回または夜間に1回しか注文を処理できない場合は、バッチETLプロセスの方が適しています。許容できる遅延（レイテンシ）を理解することで、リアルタイム性が必要ない領域に過剰なエンジニアリングを施すことなく、ビジネスの期待に応えるソリューションを実現できます。
オプションB（アウトバウンドメッセージング）は有効な技術的機能ですが、初期設計フェーズを左右する高レベルの「システム制約に関する質問」ではなく、具体的なソリューションです。オプションC（アドレス検証）はデータ整合性に関する機能要件ですが、レイテンシほど効果的に統合のアーキテクチャフレームワークを定義するものではありません。レイテンシのしきい値を特定することで、アーキテクトは統合をほぼリアルタイム、時間ごと、または日ごとのいずれにすべきかを決定でき、これはシステムがエラー回復、再試行、およびトランザクション量を処理する方法に影響を与えます。

バッチデータ同期パターンは、Salesforceとスケジュールシステム間で大量のデータを一括転送できるため、このビジネスユースケースに最適です。これにより、ワークショップ登録のリクエストの急増にも対応でき、システムに過負荷をかけたりパフォーマンスに影響を与えたりすることはありません。バッチプロセスは、システム間のデータ同期のために、定期的に実行することも、オンデマンドで実行することもできます。
1: バッチデータ同期パターン