SRM 供应商管理系统如何对接其他系统？API、主数据与同步机制设计

集成前的架构决策：主数据归属与责任边界

在企业信息化体系中，SRM 供应商管理系统从来不是孤立运行的。它必须与 ERP、OA、PLM、QMS、财务系统甚至 MES 交换数据。然而，许多项目在集成阶段暴露出一个根本性问题：主数据属于谁？

供应商主数据——包括名称、税号、银行账号、联系人、资质文件——在多数企业中被视为 ERP 的核心主数据。但采购流程的发起、供应商绩效评估、资质到期提醒等业务又发生在 SRM 中。如果两个系统各自维护一套供应商数据，很快就会产生不一致：ERP 中供应商状态为“已冻结”，SRM 中却显示“正常”；OA 中审批通过的供应商变更，SRM 三天后才收到通知。

从架构角度看，主数据的归属取决于企业的数据治理策略。常见做法有两种：

• **ERP 作为供应商主数据源**：供应商创建、变更、冻结、删除均在 ERP 中完成，SRM 通过接口实时同步。这种方式适合 ERP 已深度嵌入财务核算、应付账款流程的企业，SRM 主要负责采购协同和绩效管理。
• **SRM 作为供应商主数据源**：供应商注册、资质审核、信息变更在 SRM 中完成，通过接口推送至 ERP 和财务系统。这种方式更适合以供应商生命周期管理为核心的企业，例如制造型集团或零售连锁企业。

无论选择哪种模式，决策的关键不是技术难度，而是业务归属。如果财务部门要求供应商必须在 ERP 中创建才能进行付款流程，那么 SRM 就不宜作为主数据源。反之，如果采购部门希望掌控供应商从注册到退出的全生命周期，SRM 作为主数据源更合理。

在 SystemDo 过往的项目中，一家中型制造企业最初选择 ERP 作为主数据源，但发现供应商资质到期提醒功能在 ERP 中实现成本极高，最终改为 SRM 提供资质数据、ERP 仅同步核心字段的混合方案。这个案例说明：主数据归属不是非此即彼，关键字段可以按业务需求做拆分。

API 设计原则：RESTful 与事件驱动如何选择

确定了主数据归属后，下一步是定义系统间的交互方式。目前企业集成中主流的选择是 RESTful API 和事件驱动架构，两者并非互斥，而是适用于不同场景。

**RESTful API 适合查询和命令式操作**。例如 SRM 向 ERP 查询供应商应付余额、SRM 向 OA 发起供应商变更审批流程。这类交互需要立即返回结果，且调用方明确知道需要什么。设计时应注意：

• 使用版本号管理 API，例如 `/v1/suppliers`、`/v2/suppliers`。版本号应放在 URL 或请求头中，避免无版本控制的接口在升级时破坏旧调用方。
• 每个接口只做一件事。不要设计一个 `/supplier-sync` 接口同时处理创建、更新、删除和查询。应拆分为 `POST /v1/suppliers`、`PUT /v1/suppliers/{id}`、`DELETE /v1/suppliers/{id}`、`GET /v1/suppliers/{id}`。
• 响应结构统一。成功时返回 `{ "code": 0, "data": {...} }`，失败时返回 `{ "code": 40001, "message": "供应商税号已存在" }`。code 为 0 代表成功，非 0 代表业务错误，HTTP 状态码仅反映传输层状态。

**事件驱动架构适合异步通知和状态同步**。例如供应商资质文件更新后，SRM 需要通知 QMS 重新审核；供应商等级变更后，SRM 需要通知采购系统更新价格策略。这类场景如果使用 RESTful API，调用方需要轮询或等待回调，增加了耦合度。

事件驱动的实现通常借助消息队列（如 RabbitMQ、Kafka）或云服务的事件总线（如 AWS EventBridge、Azure Event Grid）。SRM 在发生关键业务事件时发布消息，订阅方根据自身逻辑处理。设计要点包括：

• 事件结构应包含事件 ID、事件类型、发生时间、业务对象 ID 和关键字段快照。例如：

```json
{
"eventId": "evt-20260714-001",
"eventType": "supplier.qualification.expired",
"occurredAt": "2026-07-14T10:00:00Z",
"data": {
"supplierId": "SUP-001",
"qualificationType": "ISO9001",
"expiredDate": "2026-07-13"
}
}
```

• 避免在事件体中携带过多数据。仅包含业务对象 ID 和触发事件的关键字段，完整数据由订阅方通过 RESTful API 查询。这能减少消息体大小，也避免了数据不一致。

选择哪种方式取决于实时性要求和调用方的处理能力。如果下游系统需要在秒级内响应，RESTful API 更直接；如果下游系统需要按自身节奏处理，或需要多个系统同时响应，事件驱动更合适。

幂等设计：防止重复操作导致的数据错乱

在系统集成中，网络超时、服务重启、消息重投是常态。如果没有幂等设计，同一个创建供应商请求被重试两次，系统中就会出现两条相同税号的供应商记录；同一个更新资质请求被重试多次，资质有效期可能被错误覆盖。

幂等设计的核心是让接收方能够识别重复请求并安全地忽略它。常见实现方式有三种：

**1. 业务唯一标识去重**

调用方在每次请求中携带一个全局唯一的业务 ID（例如请求 ID、幂等键），接收方在数据库中记录已处理的 ID。当收到相同 ID 的请求时，直接返回上一次的处理结果而不是重新执行。

这种方式适用于创建类操作。例如 SRM 向 ERP 创建供应商时，请求体中包含 `idempotencyKey: "req-20260714-001"`。ERP 处理前先查询该 key 是否已存在，如果存在则返回已创建的供应商 ID，如果不存在则创建并记录 key。

**2. 业务字段唯一约束**

对于供应商创建场景，税号通常具有唯一性。在数据库层面为税号字段建立唯一索引，重复创建请求会触发数据库约束异常，系统捕获后返回“供应商已存在”而非崩溃。

这种方式实现简单，但只能处理特定字段的唯一性，且无法区分是真正的重复请求还是不同供应商使用了相同税号（后者属于业务校验问题，不应由幂等机制处理）。

**3. 乐观锁或版本号**

适用于更新类操作。供应商记录中维护一个 `version` 字段，每次更新时要求调用方传入当前版本号。接收方执行 `UPDATE supplier SET name = ?, version = version + 1 WHERE id = ? AND version = ?`。如果版本号不匹配，说明数据已被其他请求修改，拒绝更新。

这种方式能防止并发更新导致的数据覆盖，但要求调用方先查询最新版本号再发起更新，增加了交互次数。

在实际项目中，通常组合使用上述方法。创建类操作使用业务唯一 ID 去重，更新类操作使用版本号控制。重试机制本身也需要幂等：调用方在重试时应使用相同的幂等键，而不是每次都生成新的。

重试与补偿：处理失败的工程策略

集成不可能永远成功。网络抖动、数据库锁冲突、下游系统维护都可能导致接口调用失败。设计重试与补偿机制时，需要区分暂时性失败和永久性失败。

**暂时性失败**：例如 HTTP 503 Service Unavailable、数据库连接超时。这类失败在重试后可能成功。策略包括：

• 指数退避重试：第一次失败后等待 1 秒重试，第二次 2 秒，第三次 4 秒，最大等待时间建议不超过 60 秒。重试次数建议 3 到 5 次，超过后进入死信队列或告警。
• 重试时使用相同的幂等键，避免创建重复数据。
• 对于批量同步任务，应记录失败的具体记录 ID，而不是整个任务重跑。例如同步 100 条供应商数据时，第 50 条失败，重试时只重试第 50 条，而不是从第 1 条开始。

**永久性失败**：例如 HTTP 400 Bad Request（参数错误）、404 Not Found（资源不存在）。这类失败重试也无法成功，应直接记录错误并告警，而不是无意义地重试。

补偿机制则用于处理业务逻辑上的不一致。例如 SRM 向 ERP 创建供应商成功，但后续向 OA 同步供应商联系人失败。此时 ERP 中已存在供应商，但 OA 中缺少联系人，导致后续审批流程无法流转。补偿方案包括：

• 事务性消息：使用本地消息表或事务消息，确保本地数据库操作和消息发送原子性。如果消息发送失败，通过定时任务扫描未发送的消息并重试。
• 回滚接口：如果下游系统提供反向操作接口，例如 ERP 提供 `DELETE /v1/suppliers/{id}`，SRM 可以在检测到后续步骤失败后调用回滚接口。但回滚本身也可能失败，因此需要人工介入的兜底机制。
• 人工对账：对于非核心业务，允许一定时间窗口内的数据不一致，通过每日对账脚本发现差异并自动修复。例如每天凌晨比对 SRM 和 ERP 中的供应商数量、字段值，输出差异报告后自动同步。

成本方面，实现完整的重试与补偿机制需要额外的开发工作量。对于核心业务（如供应商创建、订单同步），建议投入资源实现；对于非核心业务（如供应商备注更新），可以接受最终一致性，依赖定时对账修复。

同步与异步的权衡：实时性 vs 可靠性

集成设计中最常见的争论是：应该实时同步还是异步批量同步？答案取决于业务对实时性的要求。

**实时同步（同步 API 调用）**：

• 适用场景：供应商创建后立即在 ERP 中可用、采购订单审批后即时通知财务系统。
• 优点：数据一致性高，下游系统能立即感知变化。
• 缺点：增加调用方的响应时间，如果下游系统不可用，上游业务可能阻塞或失败。对下游系统的可用性要求高。

**异步同步（消息队列或定时任务）**：

• 适用场景：供应商资质文件更新后通知 QMS 审核、供应商等级变更后更新价格策略。
• 优点：解耦上下游系统，上游系统不依赖下游的可用性。可以批量处理，减少接口调用次数。
• 缺点：存在延迟，通常秒级到分钟级。需要处理消息丢失、重复消费等问题。

一个务实的做法是：对实时性要求高的操作使用同步 API，但设置超时时间和熔断机制。例如 SRM 调用 ERP 创建供应商时，设置 5 秒超时，如果 ERP 在 5 秒内未响应，SRM 应返回“创建中”状态，并将请求放入异步队列后续处理，而不是让用户等待。

对于实时性要求不高的操作，优先使用异步同步。例如供应商资质到期提醒：即使延迟 5 分钟通知，对业务影响也不大，但异步方案能显著降低系统耦合度。

在 SystemDo 参与的一个项目中，客户最初要求所有集成都使用实时同步，结果在 ERP 升级维护期间，SRM 的供应商创建功能完全不可用。后来改为：核心字段（名称、税号、银行账号）实时同步，非核心字段（联系人、备注）异步批量同步，既保证了关键业务的可用性，又降低了系统依赖风险。

监控与告警：集成链路的可见性

没有监控的集成是不可靠的。当 SRM 与三个系统通过十多个接口交互时，任何一个环节的故障都可能被淹没在日志中。建立集成监控体系需要覆盖三个层面：

**1. 接口可用性监控**

对每个集成接口实施定时心跳检测。例如每 5 分钟调用一次 ERP 的供应商查询接口，如果连续 3 次失败则触发告警。告警级别应根据接口重要性区分：核心接口（供应商创建、订单同步）告警至电话或短信，非核心接口（供应商备注更新）告警至邮件或企业微信。

**2. 数据一致性监控**

定时比对 SRM 与下游系统的关键数据。例如每小时比对一次 SRM 和 ERP 中的供应商数量、状态字段。如果发现差异，自动记录差异详情并尝试修复，无法修复的生成工单通知运维人员。

比对频率取决于数据变化量。对于每天新增几十条供应商的企业，小时级比对足够；对于每天新增上千条的企业，可能需要分钟级比对。

**3. 业务错误监控**

接口返回的 HTTP 200 不代表业务成功。例如 SRM 调用 ERP 创建供应商，ERP 返回 HTTP 200 但响应体中包含 `"code": 40001, "message": "税号格式错误"`。这类业务错误需要被监控系统捕获并告警，而不是被忽略。

实现方式是在 SRM 的集成模块中统一记录每次接口调用的请求、响应和业务状态码，通过日志分析平台（如 ELK、Loki）或 APM 工具（如 SkyWalking、Datadog）设置告警规则。

告警阈值需要根据业务量调整。如果每天调用 10000 次，失败 10 次可能正常；如果每天调用 100 次，失败 10 次就需要立即关注。建议设置相对阈值（如失败率超过 5%）和绝对阈值（如连续失败 5 次）的组合。

风险清单与应对策略

集成项目常见的风险包括：

• **接口变更风险**：下游系统升级后接口参数或响应结构发生变化，导致 SRM 调用失败。应对策略：所有集成接口必须使用版本号管理，下游系统变更旧版本时需提前通知。SRM 端应实现接口适配层，将下游接口的变化隔离在适配层内，避免影响核心业务逻辑。
• **数据量增长风险**：初期集成时数据量小，同步任务运行顺畅。随着供应商数量增长到数万甚至数十万，批量同步接口可能超时或内存溢出。应对策略：所有批量查询接口必须支持分页，且分页大小可配置。同步任务应支持断点续传，避免每次从头开始。
• **时区与编码风险**：跨国企业可能面临不同系统使用不同时区或字符编码的问题。应对策略：所有时间字段统一使用 UTC 存储，展示时转换为用户时区。所有文本字段统一使用 UTF-8 编码，避免 GBK 与 UTF-8 混用导致乱码。
• **安全风险**：接口暴露在网络上可能被未授权访问。应对策略：所有集成接口必须使用 HTTPS，并采用 API 密钥或 OAuth 2.0 进行身份验证。敏感数据（如银行账号、联系人手机号）应在传输时加密。

成本与周期估算

集成开发的工作量取决于系统数量和接口复杂度。以下估算基于中型企业（SRM 与 ERP、OA、QMS 三个系统集成，接口数量 15 到 25 个）：

• 主数据归属分析与架构设计：1 到 2 周。需要与业务部门确认数据治理策略，确定每个字段的归属和同步方向。
• 接口开发与联调：4 到 8 周。包括 API 设计与实现、幂等与重试机制、事件发布与订阅。联调阶段需要协调各系统厂商参与，实际耗时往往取决于对方配合度。
• 监控与告警部署：1 到 2 周。包括心跳检测、数据比对脚本、告警规则配置。
• 测试与上线：2 到 4 周。包括集成测试、压力测试、回滚演练。

总周期通常在 8 到 16 周。成本方面，如果企业内部有开发团队，主要是人力成本；如果外包给第三方，费用通常在 15 万到 40 万人民币之间，具体取决于接口数量和系统复杂度。上述估算的前提是各系统均提供标准 API 接口，如果某个系统需要定制开发接口或开放平台对接，周期和成本可能翻倍。

集成项目的风险往往不在技术本身，而在组织协调。不同系统由不同部门管理，接口联调时可能需要多次沟通确认。建议在项目启动时明确各系统的接口负责人和响应时间，避免因等待对方配合而延误工期。

总结：从集成到协同

SRM 与第三方系统的集成，本质上是在解决企业数据孤岛问题。主数据归属决定了数据流向，API 设计决定了交互效率，幂等与重试机制决定了可靠性，监控告警决定了可维护性。这四个环节缺一不可。

对于正在规划 SRM 集成的企业，建议先完成主数据梳理，再设计集成方案。不要一开始就追求所有接口实时同步，而是根据业务优先级分阶段实施。核心业务（供应商创建、订单同步）优先走实时同步并做好重试和告警，非核心业务（资质文件更新、备注修改）可以接受异步同步和最终一致性。

最后，集成不是一次性工作。随着业务发展和系统升级，接口需要持续维护和优化。在选型时，优先考虑支持标准 API 和事件驱动架构的系统，能显著降低未来的集成成本。