Salesforce Certified Integration Architect

**REST API vs SOAP API 选型弄反** —— 这是架构师级考试必出的低级陷阱题。现代集成**默认选 REST API**（轻量、JSON、OAuth、绝大多数新系统支持），SOAP API 只在以下场景选：(1) 对接的老 ERP / Legacy 只暴露 WSDL-strict 接口；(2) 需要 WS-Security 级别的消息签名；(3) 使用老的 SF 工具链依赖 SOAP（如某些 Partner WSDL 场景）。题干里出现 "mobile app" / "JavaScript frontend" / "modern integration" → 一律 REST；出现 "legacy WSDL" / "WS-Security required" → SOAP。

**Platform Events 和 Streaming API（PushTopic）搞混** —— 两者都走 CometD 协议、都是发布订阅、订阅端代码几乎一样，但**定位完全不同**。**Streaming API (PushTopic)** 是给**订阅 SObject 数据变更**用的（老方案，基于 SOQL 查询，近年已被 CDC 取代），没有 Replay ID 的持久化保证。**Platform Events** 是给**自定义业务事件**用的（你自己定义 Event 对象和字段，publish 端用 `EventBus.publish()`），有 Replay ID + 72 小时事件持久化。**Change Data Capture（CDC）** 才是现在 SF 官方推荐的"订阅对象数据变更"方案，完全取代了 PushTopic。考试题要特别注意 "data changes" 现在的答案是 CDC 不是 PushTopic。

**Named Credentials 的存在价值没理解** —— 很多人第一反应是 "我直接在 Apex 里写 endpoint URL + access token 不就行了吗"。**错。** Named Credentials 是 Salesforce 强制推荐的集成安全最佳实践，作用：(1) 把 endpoint URL 和认证信息**从代码里剥离**（避免部署时硬编码）、(2) **自动处理 OAuth token 刷新**（你不用自己写 refresh 逻辑）、(3) **集中管理多环境配置**（dev / uat / prod 用不同 Named Credential 但 Apex 代码不变）、(4) **安全审计**（token 不会出现在 Apex debug log 里）。考试题里任何涉及 "store credentials" / "manage endpoint" / "OAuth token refresh" 的答案都永远是 Named Credentials，不要选 Custom Setting、Custom Metadata、Protected Custom Setting。

**Bulk API 1.0 和 2.0 的限制和适用场景搞错** —— Salesforce 现在**默认推荐 Bulk API 2.0**，因为它自动 chunking（你不用管 batch size）、默认并行、简化的 Job 状态管理、只支持 CSV 格式。**Bulk API 1.0** 仍然保留的原因：(1) 需要 **serial processing mode**（2.0 不支持，只能并行）；(2) 需要 XML 格式输入；(3) 需要细粒度控制 batch size（处理有复杂 Trigger 逻辑的对象避免锁竞争）。考试里题干说 "process 500,000 records as quickly as possible" → Bulk API 2.0；说 "process records sequentially to avoid record locking" → Bulk API 1.0 serial mode。两者的**日 API 限制也不同**：2.0 按 processed records 计（每天 150M records），1.0 按 batches 计（每天 15,000 batches）。

**集成模式（Integration Patterns）选错** —— 这是考试最高权重的失分点。5 大模式的决策矩阵必须死记：(1) **Request-Reply（同步请求响应）**：SF 调用外部、需要立即拿响应、小数据量（<6MB）、实时性强 → Apex Callout + Named Credential；(2) **Fire-and-Forget（异步单向）**：SF 调用外部、不需要响应、可容忍延迟 → Platform Events 或 Outbound Message；(3) **Batch Data Sync（批量数据同步）**：定时大批量双向同步（如夜间同步 500K 订单）→ Bulk API 2.0 + ETL 工具（MuleSoft / Informatica）；(4) **Remote Call-In（外部调 SF）**：外部系统作为发起方写入 SF → REST API / SOAP API / Bulk API；(5) **UI Update Based on Data Changes**：UI 需要实时感知后端数据变化 → CDC 或 Platform Events + LWC 订阅；(6) **Data Virtualization**：不把外部数据复制到 SF、直接"显示"外部对象 → Salesforce Connect + External Objects（OData）。任何场景题先判断"方向 / 数据量 / 时效性 / 是否需要响应"四个维度再下手。

**OAuth 2.0 四种 Flow 的选型混乱** —— (1) **Web Server Flow**：最常用，用户交互式登录（redirect + authorization code）→ 标准 web app 集成；(2) **JWT Bearer Flow**：server-to-server，无用户参与、预先交换公钥证书、不需要 refresh token → 典型用于后台服务调 SF（cron 作业同步）；(3) **Client Credentials Flow**（Salesforce 从 2023 Summer 起正式支持）：纯 system-to-system、不代表任何用户、用 consumer key + secret → 典型用于 MuleSoft 等中间件以"系统账号"身份集成 SF；(4) **User-Agent Flow**：SPA 浏览器端（已过时，不推荐）。题干里 "no user interaction, backend service" → JWT Bearer 或 Client Credentials；"interactive user login" → Web Server。

**以为所有集成问题都该上 MuleSoft** —— 很多人备考 Integration Architect 后会过度推销 MuleSoft。考试的正确答案往往是 **"Salesforce native + Named Credentials + Platform Events 就够了，不需要引入中间件"**。**必须引入 MuleSoft / iPaaS 的场景**：(1) 超过 3 个异构系统需要协调、(2) 需要复杂的数据转换和 orchestration、(3) 需要统一的 API 管理和监控、(4) 需要在集成层做 message transformation 和 error handling。**不需要中间件的场景**：两个系统之间的点对点集成、简单的数据推送、SF 已有的 Platform Events / Named Credentials 能覆盖的场景。题干里出现 "2 systems, simple data sync" → 不要选 MuleSoft，选 Apex Callout 或 Bulk API。