コンテキスト: このシナリオでは、従来の B2B (Business-to-Business) 統合について説明します。
外部パートナーとのデータ共有（オプションC）：EDI（電子データ交換）は、異なる組織（取引先）間でビジネス文書（発注書など）を交換するための世界標準です。これは「外部パートナー」の基準に完全に適合します。
同期データ転送（オプションB）：入力ソース（EDIファイル）からデータを取得し、ターゲットシステム（ERP）にマッピング／移動して注文書を作成することが要件です。システムAからシステムBにデータを移動し、整合性を維持するこのプロセスを同期データ転送と呼びます。

課題：マイクロサービスアーキテクチャでは、単一のユーザーリクエストが数十もの異なるサービスを経由する可能性があります。エラーが発生したり、レイテンシが高かったりする場合、1つのサービスのログを確認するだけでは不十分です。
分散トレース: これは、サービス間を移動するリクエストを追跡するために使用される特定のテクノロジーです。
仕組み：エントリポイントでリクエストに一意のトレースID（相関ID）を割り当てます。このIDは下流のすべてのサービスに渡されます。トレースツール（Anypoint MonitoringのTelemetryやJaegerなど）は、パス全体を検証し、リクエストが各ホップで費やした正確な時間を表示します。

水平スケーリング（スケールアウト）：これは、増加した負荷に対応するために、リソースのインスタンス（レプリカ/ノード）を追加することを意味します。KubernetesまたはRuntime Fabricのコンテキストでは、コントローラーが別の「ポッドレプリカ」を追加することを厳密には水平スケーリングと定義します。
垂直スケーリング (スケールアップ): これには、既存の単一インスタンス/ポッド 2 のコピーを追加するのではなく、そのサイズ (CPU または RAM 容量) を増やすことが含まれます。
コンテキスト: MuleSoft の Runtime Fabric (RTF) は Kubernetes 上で実行され、この水平自動スケーリング機能を活用して、高トラフィック時でもパフォーマンスを維持します。

API開発者：APIの実際のコーディングと実装を担当します。Anypoint Studioを使用してMuleフローを構築し、コネクタを設定し、DataWeave変換を記述し、API機能が設計仕様1に準拠していることを確認します。
他の人が間違っている理由:
API デザイナー: 通常は実装が始まる前に、Design Center で RAML/OAS 契約 (仕様) を記述する責任を負います2。
統合アーキテクト: フローの日常的なコーディングではなく、高レベルの設計、パターンの選択、ガバナンスを担当します3。
運用: アプリケーションの構築後の展開、監視、保守を担当します4。

自動 API プロキシ生成: API Manager で API を管理する場合、Anypoint Platform を使用すると、API プロキシ アプリケーションを自動的に生成して CloudHub にデプロイできます。
機能：このプロキシはバックエンド実装（またはMule以外のAPI）の前面に配置され、手動でプロキシ用のコードを記述することなく、ポリシー（レート制限やセキュリティなど）を適用します。これにより、カスタムゲートウェイソリューションを構築する場合と比較して、APIのセキュリティ保護と管理のプロセスが大幅に高速化されます。