“已连接”，不是一个合格的系统集成验收标准

设想您的网店显示 120 笔已付款订单，仓库却只有 117 笔。连接器仪表板一片绿色，却没人能指出少了哪三笔。

这是一个假设例子，却很适合检验您购买的是什么。集成系统应帮助工作人员找到这些订单、解释其状态，并安全恢复。连接测试成功，并不能证明这些能力。

如果我评审这份方案，会希望签字验收前先看到恢复演示。这项工作应包含在最初范围里。

这一周的变化让问题更具体

9 月 16 日，Shopify 公布了 Events 载荷、订阅配置和投递头的变化，明确说明传统 Webhook 订阅不受影响。Events 当时处于开发者预览阶段，因此这是针对采用者的具体变化，并不证明所有 Shopify 集成都出了故障。

另一个例子是 Atlassian 的 9 月 17 日开发者通知：9 月 15 至 17 日的 Marketplace 合作伙伴发票报告不完整。通知称根本问题已修复，排队数据正在回填，没有数据丢失，并建议恢复完成后重新获取受影响报告。

一个涉及接口变化，另一个涉及报告延迟。对买方而言，两者都指向实际问题：使用集成的工作人员，如何知道输出还不完整？

让缺失订单有一个可追踪的身份

回到 120 笔订单的例子。先确认两边统计的是同一件事：一边可能包含取消订单，或报告时间窗口用了不同的时区。数量不符说明需要调查，并不直接证明连接器丢了数据。

统一定义后，系统应能比对真实订单编号。哪些被仓库接受？哪些在等待？哪些未通过验证？只记录“请求已发送”，会留下最有价值的问题没有回答。

我会要求一个工作人员无需开发者控制台也能使用的运营视图，展示相关订单、最后确认的步骤、确认时间及下一步操作。如果目的系统没有确认收到，就如实显示。不要把未知结果标为让人安心的成功。

这个视图不需要复制整条订单记录。除非工作确实需要，常规日志不应包含客户详情；访问权也应只给需要的人。

要求演示故障情况下会发生什么

请团队在测试环境演示几种常见故障：

• 同一订单到达两次。证明第二次不会产生额外发货或客户通知。
• 接收应用停止响应。展示未完成工作在哪里等待、何时告警，以及如何恢复。
• 旧更新晚于新更新到达。证明过时消息不会悄悄覆盖当前状态。
• 请求可能成功，但确认丢失。展示系统在重复有实际后果的操作前，如何核对目的端。

这些是建议的验收检查，并不意味着每种集成都需要同样架构。夜间报告数据流能容忍的延迟，仓库发货流程可能无法容忍。

Shopify 的投递指南提醒 webhook 可能重复到达。其概述还说明顺序和投递并不保证，并建议定期检查源数据以恢复一致性。围绕这些行为设计，是正确使用平台的一部分。

恢复必须明确哪些操作可以重复

核对源端和目的端通常称为对账。业务需要决定多久检查一次、什么差异值得处理，以及由谁处理。

对于假设网店，比对编号和预期状态可以发现三笔未确认订单。但把所有旧消息重新灌入流程，是危险的恢复方案。订单可能已经发货，客户可能后来取消了订单，或接收系统中已经存在退款。

恢复路径必须区分“记录缺失”和“操作已完成但确认丢失”。目的端支持稳定操作编号时，应利用它识别重复请求；不支持时，应规定操作员重试前如何核实结果。有些异常应保留人工处理。

用业务语言约定可接受延迟。“承运商取件前，我们必须知道哪些发货未确认”，能给设计和测试明确目标。“做到实时”则留下太多解释空间。

把持续维护写进方案

集成依赖别人可以修改的系统。需要有人阅读相关通知、维护凭据、测试更新并响应故障。明确负责人，以及维护安排包含哪些工作。

方案应与规模相称。低量流程可能只需每日异常报告和有文档的人工修正；高量或时间敏感流程则可能需要队列、自动核对和告警。漏执行或重复执行的后果，应决定选择。

Rosecraft 的集成和现代化工作从业务所需流程出发。对于现有连接器，技术评估能帮助确认哪些状态可见，哪些恢复步骤仍只是推测。

验收前，请团队故意让一笔测试订单无法到达，再展示接下来会发生什么。这个演示，比绿色勾号能说明更多。