設問
ある顧客が、古いレガシーシステムからSalesforceへの移行を進めています。モダナイゼーションの一環として、現在レガシーアプリケーションと連携している既存のすべてのシステムをSalesforceと統合したいと考えています。統合アーキテクトが統合パターン／メカニズムを選択する際に考慮すべき制約と問題点は3つありますか？（3つ選択してください。）
選択肢
A. 報告とユーザビリティの要件
B. データ量と処理量
C. 多言語および多通貨の要件
D. エラー処理メカニズム
E. システムタイプ API、ファイルシステム、電子メール
解答
B. データ量と処理量
D. エラー処理メカニズム
E. システムタイプ API、ファイルシステム、電子メール
解説
A. 報告とユーザビリティの要件
不正解です。
報告とユーザビリティは主にUI/UXレベルの考慮事項であり、統合パターンの技術的選択には直接影響しません。これらは統合後のアプリケーション設計で対処すべき事項であり、統合メカニズムの選択における制約とはなりません。
B. データ量と処理量
正解です。
データ量とメッセージサイズはSalesforceのガバナー制限（DML制限、API呼び出し制限など）に直接影響します。大量データにはバッチ処理パターン、少量データにはリアルタイム処理パターンを選択する必要があり、統合設計の根幹となる制約です。
C. 多言語および多通貨の要件
不正解です。
多言語・多通貨機能はSalesforceの標準機能として提供されており、Translation WorkbenchやMulti-Currency設定で対応可能です。これらは統合パターンの選択に特別な技術的制約を与えないため、考慮事項から除外されます。
D. エラー処理メカニズム
正解です。
統合では認証エラー、タイムアウト、データ不整合など様々なエラーが発生します。適切なエラー処理とリトライ戦略は統合の信頼性に不可欠であり、同期/非同期パターンの選択やトランザクション管理方法に直接影響する重要な制約です。
E. システムタイプ API、ファイルシステム、電子メール
正解です。
レガシーシステムの接続方法（REST/SOAP API、FTP、SMTP等）により利用可能な統合パターンが制限されます。APIベースならリアルタイム統合、ファイルベースならバッチ処理、メールベースなら非同期処理など、システムタイプが統合アーキテクチャを決定します。
第64問
こちらをクリック
