SAP Integration Suite：关键决策与生产环境中的取舍

SAP Integration Suite是SAP在SAP BTP上的集成平台：Cloud Integration（前身是CPI），加上API Management、Event Mesh、Integration Advisor、Open Connectors，以及从PI/PO迁移的工具。它是S/4HANA云项目默认的中间件，也是离开PI/PO的路径，而PI/PO的主流维护将于2027年结束。接口延误很少出在技术上。它们来自归属不清、对旧系统未经检验的假设，以及只为“通过”而设计、而不是为发现故障而设计的测试。本文写给集成负责人、架构师和项目经理。内容包括各个组件的用途、标准内容与定制内容的取舍、PI/PO迁移、旧系统和测试风险，以及上线之后的治理。

PI/PO已进入倒计时。SAP Process Integration和Process Orchestration 7.5的主流维护持续到2027年底。可选的延长维护持续到2030年底，之后SAP的支持终止。SAP的迁移参考架构描述了迁移路径。Integration Suite包含一个Migration Assessment应用，用来评估每个PI/PO场景的规模，Cloud Integration中还有基于向导的迁移工具。要分波次迁移：先迁移低风险的SAP到SAP流程，B2B和EDI放在中间，高业务量的订单流程放在最后。在截止日期的压力下强行切换，耗时更长，花费更多。

1. 第一波低风险的SAP到SAP流程先用Migration Assessment评估每个场景的规模
2. 第二波B2B和EDI
3. 第三波高业务量的订单流程
4. 2027年PI/PO 7.5主流维护结束年底。规划好各波次，在此之前完成
5. 2030年可选的延长维护结束年底。之后SAP的支持终止

来源: SAP维护日期和迁移参考架构，2026年10月核对

查清您的云合同涵盖什么。RISE和GROW合同通常包含SAP BTP额度，可以用来支付Integration Suite的费用。在拿Integration Suite和MuleSoft或Boomi只比功能之前，先确认您的授权涵盖哪个版本、多大的消息量。平台已包含在合同里，会改变比较的经济账。

AI正在分阶段到来。Cloud Integration的Premium版本自2024年年中起提供生成式AI流程生成。它生成的是iFlow的结构（步骤、通道、异常子流程），而不是映射或脚本。SAP在2026年3月推出的增强版本增加了文本生成流程和脚本优化，SAP还计划让Joule in Integration Suite在2026年第三季度正式发布。对标准流程有用。涉及深层业务逻辑的复杂编排，仍然需要资深架构师。

Integration Suite是一组服务。为每项工作选对服务，决定了整个系统架构能撑多久。

组件	作用	用错时会出什么问题
Cloud Integration (CPI)	消息流、路由和转换；大多数iFlow的默认选择	一切都塞进CPI，包括API和事件，会变得难以支持和测试
API Management	治理API的对外开放：安全、速率限制、分析	跳过它，点对点调用就会越来越多；治理很难事后补上
Event Mesh	用于解耦触发的异步消息	未被跟踪的队列悄悄变大，没有人收到告警
Integration Advisor	为EDIFACT、X12和IDoc等B2B格式提供映射建议	团队预期覆盖率很高；有一个团队期望80%，结果接近40%
Open Connectors	对接第三方云应用的预置连接器	外部API变更会悄悄弄坏连接器，除非有人监控
Migration Assessment及工具	评估并迁移PI/PO场景	被当作一次性估算，而不是可执行的迁移计划

把Integration Suite当作“带附加组件的CPI”的团队，常常忽略API Management和Event Mesh。这在复杂度追上来之前都行得通。我的SAP CPI指南对Cloud Integration本身讲得更深入。

当流程是标准流程时，SAP预置的集成内容确实有用。用标准流程把S/4HANA连接到SAP Ariba或SuccessFactors，往往非常合适。但真实的业务流程很少会乖乖待在SAP的参考线以内。

下面的情况选标准内容：

1. 场景是SAP到SAP，且接近SAP的参考流程
2. 流程简单，且以单向为主
3. 您能接受SAP的映射，只通过提供的出口进行扩展

下面的情况选定制开发：

1. 多年的内部决策已经让流程偏离了SAP的模型
2. 涉及条件路由、多步骤逻辑或旧系统的怪癖
3. 大量修改会破坏标准包与SAP的支持一致性

要在蓝图阶段做出这个决定。决定得晚，团队会在项目中途发现，某个“标准”iFlow被改得太多，已经失去与SAP支持的一致性，只好在上线压力下重建。我见过项目因此损失数周，原因是团队以为标准内容能同时吸收定制的主数据结构、额外字段和旧系统认证。结果不行。本该在设计阶段完成的分析，拖到了UAT期间才做。

在大型SAP项目里，集成往往最先掉进各工作流之间的缝隙。接口跨越团队边界，却没有人负责协调。我见过两个项目团队为同一个业务伙伴各自建了集成，指向同一个端点，彼此毫不知情。直到UAT，两边都没发现。这是结构性的失败，不是技术性的。

要尽早建立集中的集成治理：

1. 一份对所有工作流可见的共享集成待办清单
2. 每个接口都有指定的负责人，并在交付全程跟踪
3. 每次重大部署之前，各工作流之间设置协调检查点
4. 在做出任何上线承诺之前，先复核接口依赖关系，并在切换计划里为共享的端点和队列排好顺序
5. 在各环境之间自动化部署，并按每个系统环境记录凭证

最难的集成问题，很少出在现代平台上。它们出在处于关键流程中间的老系统上。

旧ERP往往无法处理并发的同步调用。同时发出五个并行的API调用，服务器就会变慢、卡死，或者悄悄丢数据。只有接收系统能处理队列时，异步集成才有帮助，而很多系统做不到。

协议不匹配很常见，而且发现得晚。您按OAuth2和REST来设计；旧系统说的是SOAP，硬编码了30秒超时，令牌刷新处理得也很差。

在一个客户案例里，一条中间件流程每周五都失败，因为第三方薪资系统签发的令牌每周过期一次。直到第二轮UAT才有人注意到。这类怪事很常见，它们会吃掉时间表。

下表列出了设计冻结之前要检查的风险。

风险	常见问题	设计时该怎么做
同步限制	旧系统在并行调用下锁死	使用异步消息；通过Event Mesh或Cloud Integration错开调用
协议不匹配	旧系统拒绝REST或OAuth，或在SOAP上超时	在设计开始前确认协议和超时设置
API速率限制	批处理作业超出第三方的限流	在API Management中限流；在iFlow中加入等待逻辑
令牌过期	流程在非高峰时段悄悄失败	安排刷新周期并监控过期情况
格式僵硬	动态载荷破坏旧系统的解析	用真实的生产样本验证
没有兜底	文件传输失败后不重试，数据卡住	在中间件中缓冲；在iFlow中内置重试和告警

跨云版本的同类问题，请看我写的为什么ERP与Salesforce的集成会失败。

集成出问题的方式，并不是功能测试检查的那种。它在时间压力下失败，在后台作业重叠时失败，在输入成批涌来而不是一条一条到达时失败。功能测试证明的是：一笔事务能过账，日志里能看到一条消息。它没法证明，第一次薪资运行发出大批IDoc时会发生什么。在一个项目里，一个IDoc在系统集成测试里看起来一切正常，真实的薪资数据量一进来，队列就卡住了。只有负载测试发现了它。

接口测试需要覆盖：

1. 真实的数据量，加上并发用户
2. 服务中断和恢复行为
3. 中间件和后端之间的超时与重试
4. 批处理作业与实时调用同时运行
5. 月末和其他高峰期

开发环境是干净的。死锁、竞态条件和限流，会在UAT和预生产环境里出现，因为那里其他系统和批处理窗口都在运行，所以要在那里做负载测试。职责要分清：业务团队验证整条流程的业务结果，集成团队负责日志、重试和异常流程，项目负责人确认覆盖范围。我写的SAP性能测试指南讲的是负载方面。

Integration Advisor为结构化的B2B格式提出映射建议。对遵循严格规范的合作伙伴，它确实能节省配置时间。对于涉及旧系统、自定义字段、条件逻辑和未成文规则的企业级集成，它只是一个起点。

我合作过的一个团队，期望映射覆盖率达到80%。实际覆盖率大约是40%。其余部分只能定制，再与业务确认，并手工测试。

它解决不了多年里非正式积累下来的业务逻辑（付款条件、价格类别、单位惯例），解决不了依赖业务背景的条件规则，也解决不了标准格式之外的例外情况。这些都需要业务人员的输入。没有这些输入，接口在技术上完成了映射，在个别情形下逻辑却是错的。

上线之后，一旦文档与实际脱节、归属又不正式，集成质量就会下降。有用的文档涵盖字段映射和转换逻辑，也涵盖认证细节，例如端点、令牌刷新和凭证轮换。它还要涵盖错误处理、兜底规则，以及月末和发薪等关键时段的业务量预期。检验标准是：下周新加入支持团队的人，能否只靠文档排查一个出故障的接口？

每个接口，哪怕业务量很小，都需要一位指定的负责人，管监控、升级和生命周期变更。没有负责人，故障就会在Basis、中间件和业务团队之间来回踢皮球，业务只能干等。过了特别支持期（hypercare），监控往往会逐渐松懈。要建立定期的错误日志复查、从项目到支持的正式交接，以及业务与IT之间约定的服务级别。被忽视的集成，是许多延迟过账、缺失发票和对不上的财务报告背后的原因，这些问题往往在上线几周后才浮出水面。

什么是SAP Integration Suite，它与CPI有什么区别？

Cloud Integration，前身是SAP Cloud Platform Integration（CPI），只是Integration Suite中的一项能力。这套产品还增加了用于受治理的API开放的API Management，以及用于异步消息的Event Mesh。它还包括提供B2B映射建议的Integration Advisor、对接第三方云应用的Open Connectors，以及PI/PO的评估和迁移工具。把它当作换了名字的CPI的团队，常常跳过API Management和Event Mesh，事后在治理缺口上付出代价。

SAP PI/PO的支持什么时候结束？

SAP Process Integration和Process Orchestration 7.5的主流维护持续到2027年底。客户可以选择延长维护到2030年底，之后SAP的支持终止。Integration Suite包含Migration Assessment应用，用来评估每个场景的规模，也有迁移工具可以半自动地迁移各类对象。先做一份分波次的计划，不要等到截止日期才动手。

SAP集成什么时候用标准内容，什么时候用定制开发？

场景是SAP到SAP、接近SAP的参考流程且相对简单时，用标准内容。流程已经偏离SAP的模型、旧系统的怪癖需要特殊处理，或者条件逻辑和多步骤逻辑会迫使您大幅改动标准包时，用定制开发。要在蓝图阶段做决定；在上线压力下重建一个被改得面目全非的标准流程，比一开始就干净地定制开发代价更高。

复杂项目中，SAP集成失败的原因是什么？

多数是结构性原因。监控和错误处理没有指定负责人，故障在团队之间来回推。两个工作流各自建了共用同一个端点或队列的集成，却互不知情。旧系统无法承受并发调用，直到负载下才被发现。还有测试，单独运行时一切顺利，却从未模拟过批处理重叠或高峰业务量。

SAP Integration Suite的集成测试应该怎样安排？

除功能测试之外，还要覆盖真实的业务量，例如第一个月末或第一次薪资运行。要测试批处理作业与实时接口同时运行、下游系统不可用时的恢复，以及批量作业期间的第三方速率限制。要在与生产环境相近的环境里做负载和性能测试，因为干净的开发系统会掩盖问题。

上线之后，SAP集成应该怎样治理？

给每个接口指定一位负责人，管监控、升级和变更。保持文档最新：映射、认证与凭证轮换、错误处理和业务量预期。再建立长期的支持模式，包括定期的错误日志复查、从项目到支持的正式交接，以及约定的服务级别。变得“看不见”的集成，就会被忽视。