孙玲的空间1. 从“能跑就行”到“不许乱动”：Clean Core 到底在倒逼什么
做过几年 SAP 实施的人都清楚，过去十年我们面对 ERP 的方式，基本可以概括成“能跑就行”。外围系统要对接，直接在 Standard Report 后面塞一段自定义逻辑；业务部门要一个新字段，Process Order 表里加个 ZZ 开头字段；报表不够灵活，干脆把 Function Module 改一改。系统确实能跑，数据也确实在流转，问题也暂时没人追究。但这种“自由发挥”累积到一定量级之后，系统的每一次升级、每一个 Notes 的导入、每一次 S/4HANA 版本迁移，都变成一场赌博。改过的对象、增强过的逻辑、自建的表，随时可能在升级过程中被新标准覆盖，或者干脆和新版本的标准功能产生语义冲突。这个时候，家里一旦决定上 S/4HANA，或者已经在 S/4HANA 上打算持续迭代，董事会和高层自然会问一个问题：我们的 SAP 系统到底干净不干净？还能不能安全地升级？
“Clean Core”这个概念就是在这样的背景下被推到台前的。它的本意很简单：SAP 系统里，标准的部分就保持标准，不要动；个性化的部分，尽量搬到外围；必要留在核心里的扩展，用 SAP 支持的、可持续升级的机制去做，而不是用修改标准对象的方式硬塞。
理念归理念，真正落到项目里，绝大多数企业的第一反应是：行，那我把那些自定义增强都干掉，以后新需求都尽量少往核心塞。但真到了动手拆的时候，就会撞上一堵墙。过去十年、二十年塞进 ECC 的自定义逻辑，不是平白无故长出来的。每一段 ABAP 代码背后，都对应着一条业务规则、一个流程步骤、一次数据转换。你把这些逻辑从核心剥出来，剥到哪里去？原来一个程序内部直接读取数据库、然后内存里算一步、再写回另一个表，这种语言逻辑想要原封不动搬到核心外面，靠什么搬？业务系统之间要实时联动了，靠什么通讯？
这时候就必须面对一个很现实的技术岔路口：你得有一个专门承担集成和扩展的中间层，SAP Integration Suite 和它底下的 API Management 就是 SAP 在这个岔路口上给你准备好的两条车道。很多企业以为 Clean Core 是一个“整理核心”的动作，做着做着才发现，Clean Core 实际上是一个“重建外围”的工程。而这个工程的地基，就是 API 化、事件化、服务化——每一条自定义业务逻辑，都要变成可以被调用、被编排、被监控的独立服务。
所以，说“Clean Core 几乎绕不开 SAP Integration Suite 和 API Management”，不是在帮 SAP 卖产品，而是 Clean Core 的落地路径天然指向了这个方向。你不想让核心里长满杂草，就得把种子挪到花盆里。而花盆与花盆之间、花盆与土地之间的水管，就是集成平台和 API 网关。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 为什么“不动核心”反而需要更庞大的外围设施：集成层被低估的复杂度
很多企业第一次听到 Clean Core 时，有个直觉反应：以后 SAP 系统里的自定义代码少了，运维负担是不是就轻了？这个想法对了一半。核心的升级负担确实会减轻，但整体架构的复杂度并不会消失，它只是换了位置——从 ABAP 编程环境，转移到了集成层和扩展层。换句话说，你少写了几百个 ABAP 程序，但可能要配置几十个 Integration Flow、发布上百个 API、维护一套 API 网关的认证授权策略。两边的技能栈完全不同，人员配置、工具链、监控方式也完全不一样。
2.1 从紧耦合到松耦合，中间的“胶水”并不好熬
过去在 ECC 里做增强，本质上是一种紧耦合。数据源在系统内部，处理逻辑在系统内部，结果也在系统内部。一个财务凭证增强，无非是 BADI 里加几十行代码，读写几张内表，到了月末结账的时候自然触发。这种做法的最大问题是“快”，但快的前提是业务系统本身是一个封闭的宇宙。
Clean Core 要求把非标准的逻辑搬出核心，这就意味着业务逻辑要被拆分到若干个系统上：S/4HANA 负责标准交易处理，外围的扩展应用负责个性化规则，第三方系统负责数据补充。要让这些跨系统的调用协调工作，你需要的并不是“一个接口”，而是一整套的集成基础设施。
这中间涉及的复杂度是很多人一开始没意识到的：
- 协议转换：RFC 时代的 ABAP 程序只需要被 ABAP 环境内部调用；搬到外围之后，可能消费者是 Java 服务、.NET 程序、移动端 App，你的服务需要暴露成 REST、SOAP 或 OData，甚至要支持异步事件。
- 数据映射：核心系统里的字段命名和数据结构，是经过多年标准化沉淀的，而某个外围应用可能需要完全不同的数据模型。映射逻辑放在哪里、由谁维护，是一个必须提前规划的问题。
- 事务边界：原来一个 ABAP 程序里读两个表、写三个表，天然处于同一个 LUW 之下；拆成跨系统调用之后，分布式事务的问题直接冒出来。谁先提交？失败之后怎么补偿？是否需要防腐层？
- 安全模型：内部调用不需要考虑太多，跨系统调用就要考虑 API 的认证方式、权限粒度、证书轮换、审计日志。
这些看起来都是“基本功”，但真正落地的企业大多会发现，自己的团队从来没正经做过这件事。过去的 ERP 里塞了几百个自定义开发，不少企业连完整的接口清单都拿不出来，更不要说实现 API 化管理。Clean Core 等于强制把这些历史欠账翻出来，逼着你把集成层补起来。而 SAP Integration Suite 和 API Management，又是这套集成层里和 SAP 技术栈匹配度最高、顺滑度最好的选择。
2.2 SAP 并非没有给过备选方案：Process Orchestration 与旧集成路线的局限性
聊到集成，老 SAP 顾问可能会想到 SAP Process Orchestration（PO/PI）。确实，过去的十多年里，大量企业的 SAP 集成都是通过 PO 来做的。PO 能连接 A2A/B2B，能管理接口的映射和路由，看起来跟 Integration Suite 干的是同一件事。那为什么 Clean Core 时代，SAP 在集成领域主推的却是 Integration Suite，而不是继续让企业强化 PO？
原因其实并不复杂。PO 和 SAP 核心是紧耦合的，它通常部署在 ABAP 环境中，需要专门的服务器、专门的中间件技能，而且它的开发方式（ESR/IB/CC）非常“老派”，对云原生应用的支持、对开放 API 生态的支持都比较弱。Clean Core 的原则之一是“核心只保留标准功能”，而把一个庞大的中间件（PO）继续放在核心环境旁边，本身就是一种“不干净”的体现，何况这个中间件还需要你持续投入升级维护成本。
SAP Integration Suite 则是基于云原生架构构建的 PaaS 服务，运行在 SAP Business Technology Platform（BTP）上。你可以跨环境连接 S/4HANA Cloud、S/4HANA 私有云、ECC 旧系统，也可以连接非 SAP 的 SaaS 应用（Salesforce、Workday、钉钉、企业微信之类）。它天然是“核心之外”的东西，不往 S/4HANA 里塞任何代码，也就不会给核心升级添堵。
API Management 则是这套集成套件里的网关和控制面。你发布出去的每一个 API，都可以在 API Management 上做生命周期管理、流量控制、认证鉴权、SLA 监控。过去你做一个接口给别人调用，给的是个 URL，至于有多少人调、调得稳不稳、谁在滥用，很多企业基本是睁眼瞎状态。上了 API Management 之后，API 的使用情况、调用量、响应时间、错误率、订阅方、配额消耗，全都可视化。
所以把两者放在一起看，Integration Suite 是“管道”，API Management 是“阀门和水表”。Clean Core 要求你拆掉核心里的复杂逻辑，那拆出来之后的逻辑之间怎么通信、怎么管控，就是这套设施要解决的问题。
2.3 现实场景：没有 API 网关，扩展应用怎么活
说一个我实际见过的场景。某制造企业为了满足销售部门“查看订单实时状态”的需求，原来在 ECC 里写了一个自定义表，把订单状态同步到一个自研的 C# 系统里，每天定时跑批同步。这套逻辑很简单，但问题是：它直接读写 ECC 数据库表，完全绕过了标准的 BAPI/Services。S/4 升级的时候，这张自定义表和 ECC 里的标准表之间隐藏的耦合直接让数据迁移脚本崩了好几次。
后来为了贯彻 Clean Core，项目组把状态查询的逻辑改成了服务的模式：在 S/4HANA 里启用标准的 OData 服务，再通过 API Management 包装成一个对外统一的 API。自研系统不再直连数据库，而是每天通过这个 API 拉取订单变更。这只是一个很小的场景，但它揭示了 Clean Core 的一个铁律：核心里的数据要离开核心，就必须通过 API——而 API 不应该是临时拼凑的接口，而应当是经过设计、注册、受管的资产。
3. SAP Integration Suite 在 Clean Core 里的真实分工：不只是“转发消息”
SAP Integration Suite 不是一个单一工具，它是一整个工具箱。官网上的功能矩阵看多了容易发懵，但落回 Clean Core 的语境里，真正高频用到的也就是几块：Cloud Integration（云集成）、API Management（API 管理）、Open Connectors（开放连接器）、Integration Advisor（集成顾问）。这几块在项目里各自干各自的活，合在一起，才构成了一套完整的“外围扩展支撑层”。
3.1 Cloud Integration：把“管道”本身做扎实
Cloud Integration（CI）负责的是消息层面的处理。它做的事情很像老 PO 里面消息流设计，但长得更现代化，配置界面、连接器、错误处理机制都更友好。在 Clean Core 项目里，CI 最常见的用途是：
- 系统间的主数据分发：比如将 S/4HANA 里的客户主数据、供应商主数据、物料主数据，实时或者准实时地分发到外围的数据中台、MDM 系统、仓储系统。
- 业务事件转发：S/4HANA 里业务单据发生状态变化（例如采购订单审批通过），通过 SAP Business Events 机制把事件推送给下游应用。
- 文件与消息转换：将 SAP 内部格式的 IDoc/XML 转换为外围系统需要的 JSON/CSV，或者反过来。
- 渠道适配：连接微信、钉钉、邮件、SFTP、Kafka/Event Mesh 等外部通道。
CI 和 API Management 并不冲突，两者经常配合使用。简单场景下，API Management 负责暴露接口并做管控，CI 负责做后端的映射与转换。复杂场景下，API 进来之后先走到 CI，由 CI 编排多个后端系统的调用，再把聚合结果返回给 API 网关。
3.2 用 Integration Suite 不只是为了“接得上”，更是为了“拆得动”
Clean Core 项目的根本目标是把大段的 ABAP 函数逻辑拆小、拆散，让每一个业务动作都变成一个可独立演化的服务。这个“拆”的过程，最考验人的并不是写那几行接口代码，而是如何在一个已有大量历史逻辑的系统中，找到合适的拆分边界。
我曾经见过一个项目组，把原来一个 4000 行的 ABAP 报表程序拆成了五个 API 加三个 CI 集成流。每个 API 负责一个相对独立的数据切片，集成流负责把这五个 API 的数据拼装起来，最终给到 BI 展示。拆完之后，核心里的自定义代码确实清掉了，但系统间调用的数量暴增。如果 CI 的监控、日志、告警能力跟不上，出了问题连“哪一段消息卡住了”都找不到，那就欲哭无泪了。所以 Integration Suite 在 Clean Core 里真正意义上的价值，不只是“转发消息”，而是把消息流转的整个过程变成可观测、可追踪的资产。
3.3 一张表理清 Integration Suite 各组件和 Clean Core 的关系
| 组件 | 核心职责 | Clean Core 落地中的典型任务 |
|---|---|---|
| Cloud Integration | 消息路由、映射转换、流程编排 | 把主数据、业务事件从 S/4HANA 分发到外围系统 |
| API Management | API 生命周期管理、鉴权、流控、监控 | 把 S/4HANA 的标准 OData 服务封装为标准 API，供内外消费 |
| Open Connectors | 预构建的非 SAP 应用连接器 | 快速对接 Salesforce、ServiceNow、钉钉等外部系统 |
| Integration Advisor | 基于 AI/ML 的接口映射建议 | 迁移 PO 里的映射逻辑到新平台时，减少人工映射成本 |
| Event Mesh | 异步事件分发与订阅 | 实现 S/4HANA 与外围系统的事件驱动协作 |
3.4 集成顾问（Integration Advisor）：迁移老接口时的隐藏利器
如果你做过 PO 往 Integration Suite 的迁移，就一定知道最痛苦的并不是“重写接口”，而是把过去几年堆积的成百上千条消息映射规则重新配置一遍。每条映射规则都代表一个业务约定：这个字段在源系统里是这种格式，在目标系统里要求另一种格式；这个代码值要从 A 系统翻译成 B 系统。人工去维护这些映射，不仅耗时，而且极易出错。
Integration Advisor 做的事情是帮你把历史接口的映射逻辑“学习”下来，建立一套可复用的映射模型。老接口的报文样本拿出来分析，AI 帮你推荐映射关系，人工确认之后，就可以形成标准化的映射模板。团队再也不用每个接口从零开始配 IFlow，而是基于模板快速生成。对于 Clean Core 项目来说，这东西最大的价值是加快了“从旧集成方式迁到新集成方式”的进程，也相当于把映射规则从核心迁出来之后做了一次资产化整理。
4. API Management 不只是“网关”：Clean Core 架构里的治理枢纽
很多企业对 API Management 的理解停留在“一个代理层，把后端的 URL 转发一下”。这种认知在 Clean Core 场景里远远不够。API Management 在一个健康的核心外扩架构里，扮演的是治理枢纽的角色。你的 API 该怎么起名、如何分组、谁能调、调多久、超时多少、返回什么样式的错误信息——这些都应该通过 API 网关统一收口，而不是靠后端服务的开发者各自发挥。
4.1 把 S/4HANA 的 OData 服务安全地释放给外部
在实际项目里，很多 S/4HANA 系统启用了标准的 OData 服务，但这类服务的默认暴露方式往往不适合直接开放给外部。OData 服务的元数据在 /$metadata 里会暴露大量内部结构；某些标准服务的查询能力过于宽泛，直接给外部使用会带来数据过曝的风险。API Management 在这里承担了“门面”的角色：
- 你可以为一个 OData 服务定义多个 API Proxy，每个 Proxy 只暴露必要的字段和操作。
- 你可以在 API Proxy 层加上额外的安全策略，比如基本认证、OAuth 2.0、客户端证书。
- 你可以在网关层做字段过滤，避免下游调用者拉取到不该看的字段，比如把内部佣金比例、供应商折扣这类敏感字段从响应里剔除。
4.2 用 API 第一的思路重新设计“扩展”
Clean Core 项目中的 API 设计，不应是“把旧逻辑包装成 REST 接口”，而应该遵循“服务契约先行”的思路。也就是说，在拆分业务能力之前，先定义好服务的边界、输入输出结构、错误语义和版本策略，然后再去核心系统里寻找对应的标准能力来组装。
从一个业务能力的角度出发，比如“查询订单履行状态”这个业务能力，它应该暴露成什么 API？路径怎么设计？返回结构包含哪些状态字段？错误码怎么定义？先把这些问题定下来，再去 S/4HANA 里看是用标准 OData 服务、还是用 BAPI、还是用 CDS View 来提供数据支撑。这是一种“以 API 为产品”的思想，跟过去“把 ABAP 函数包装成服务”的做法是完全两种境界。
API 优先的设计还有一个额外的好处：核心系统的内部结构变化不会轻易影响到消费者。今天的 S/4HANA 用的是 CDS View 提供的字段，明天如果要改为事件驱动，API 的对外契约可以保持不变，只调整后端的实现。这就是“核心变干净”这个目标能够长期维持的结构性保障。
4.3 版本、配额、限流的实用策略
API 上线之后，最常遇到的一个坑是“版本管理混乱”。开发的 v1 发布出去没多久，业务方又提了新需求，字段要增加，逻辑要调整。如果没有版本化策略，修改一个接口等于同时影响所有调用方。
在 API Management 里，我的习惯做法是：
- 每个 API 在一开始就定义好版本号，URL 里带 /v1 前缀。
- 向后兼容的变更，直接在原版本上增加可选字段，不新建版本。
- 向后不兼容的变更，新建 /v2，旧版本在预定义的过渡期内继续提供服务。
- 在网关层监测各版本调用量，当低版本调用量降至阈值以下，与调用方确认后下线低版本。
另外，流量配额这块也很有讲究。S/4HANA 本身有性能瓶颈，如果外围系统以很高的频率去轮询接口，很可能拖垮核心系统的数据库。合理的做法是在 API Management 上给每个消费者应用配置配额：比如每分钟允许调用 100 次，或者每天允许调用十万次。配额超限时，网关直接返回 429，而不是把请求打到后端。
5. 三条可行的 Clean Core 集成路线，及其代价对比
说了那么多理论，落到选型的时候，企业通常会面临三条路线。每一条路线都有自己的适用场景和隐性成本，我按实际项目里的接触频率来聊。
5.1 路线一：完全拥抱 SAP Integration Suite + API Management
这套组合拳是“正统”路线，特别适用于标准 S/4HANA（不管是公有云还是私有云）的客户。SAP 对自家产品的兼容性最好，新的 SAP 集成特性、预置连接器、事件服务都能第一时间用上。你不用担心 S/4HANA 升级到新版本、新 SP 之后，某个 IFlow 突然不可用。这是这条路线的最大优势——它在 SAP 的可支持边界之内。
代价也很明显：贵。Integration Suite 的计费模式基于消息数量和 API 调用量，大规模使用的时候，这笔费用不可小觑；同时，Integration Suite 的配置方式和传统 ABAP 开发完全不一样，团队要重新学习 BTP 的开发和运维模型。
5.2 路线二：自建中间件 + API 网关组合
有些企业已经具备很强的 Java/Node.js 技术栈，会选择自建集成服务，再搭一个开源或商业 API 网关（比如 Kong、APISIX）。这套方案在代码级灵活度上更高，企业完全掌控数据流和安全策略，不受 SAP 产品演化方向的影响。但它有一个显著软肋：SAP 的标准接口在快速变化（OData V4、新型 CDS 视图、事件总线），你自建的框架未必能及时跟上 SAP 的更新节奏，每次 S/4 升级，都可能有一些接口细节需要手工适配。
如果你企业内部技术能力强、SAP 使用范围也不深，这条路线可行；但我见过太多案例，自建到一半发现嘴巴说“开放接口”很容易，实际每适配一个新 SAP 标准服务都要加班。如果你选择这条路，务必花时间跟踪 SAP 发布的新接口能力和兼容性说明。
5.3 路线三：混合模式——平衡成本与可控性
混合模式是目前我见过最多大企业中实际采用的路线。核心场景走 Integration Suite + API Management，非核心或不适合云化的场景走自建。比如：S/4HANA 和分支机构系统之间的主数据流用 Integration Suite；和总部的自研数据中台之间，用自研的 Kafka 或其他消息中间件。API 入口统一走 API Management，后端实现可以是云集成流，也可以是本地微服务。
混合模式的挑战在于边界划分。哪些算核心？哪些算非核心？这个答案不能只由 IT 团队来定，必须有业务方参与。比如主数据是企业级资产，任何一次主数据的变更都可能引发多个下游系统的连锁反应，这类数据流走 SaaS 集成平台更稳妥；而一些一次性的、临时性的文件交换，完全没必要上太重的基础设施，自建轻量 FTP/SFTP 作业就够用。
5.4 一条最容易被忽视的量化指标：每条集成的全生命周期成本
讲选型的时候，很多企业喜欢拿“单次连接的成本”来做对比：SAP 网关按调用收费，自己搭一个网关好像只花服务器钱。但这里有个估值陷阱——API 的全生命周期成本远不止“运行时的服务器费用”。API 需要监控日志，需要版本管理，需要应对安全审计，需要在出问题的时候定位链路。这些能力无论是自建还是采购，都是成本。
自建 API 网关的人员成本，通常被严重低估。网上开源方案能帮你省下软件授权费，但从“跑得通”到“跑得稳”之间，隔着一个专职平台团队的好几个季度工作量。考虑到 Clean Core 项目本身工期就紧，选择商业成熟方案往往整体算下来更划算。
6. 落地过程中的真实卡点与排错经验
从设计到落地，中间有大量细节会绊倒人。分享几个我在项目里亲身踩过或者亲眼见人踩过的坑，希望后来者少走弯路。
6.1 第一个坑：把 API 网关放在最后一步再配置
很多项目组上线 S/4HANA 的时候，为了赶进度，先让外围系统直连 SAP 的标准 OData 服务，API Management 的部署一拖再拖。直连一时爽，问题接踵而来。某家客户的移动端应用直接连 S/4HANA 的 OData 服务，某次 S/4 侧针对 OData 做系统更新，意外拖垮了对接口的响应。由于没有网关层缓冲，移动端直接报错给了最终用户，业务部门当天就炸了。
正确的做法应该是：从项目第一天就把 API 网关作为统一入口。外部系统一律不允许知道后端的 SAP 系统地址，所有调用都通过网关。这样后端系统升级、优化、切换时，你只需要在网关上调整路由策略，业务端无感知。
6.2 第二个坑：低估事件驱动改造的复杂度
Clean Core 的长期愿景包含“事件驱动”的能力——业务事件发生后，通过 Event Mesh 分发给多个下游消费者。这个理念很好，但实施时很多企业栽了跟头。原因是 S/4HANA 里不是所有业务动作都有现成的事件；你经常会发现某个传统自定义触发点并没有对应的 SAP 业务事件可订阅。
这种情况下，项目组只能自己定义事件，或者用轮询去模拟事件（通过定期查询相关表），这两种手段都不优雅。一次经验教训是：在规划 Clean Core 架构时，把“哪些业务事件是现成的、哪些需要二次开发、哪些根本没有事件”列一个清单，前置评估，而不是在开发阶段才发现某个事件缺失，然后仓促找替代方案。
6.3 第三个坑：Sky 高可用与灾备没在设计阶段考虑
集成层一旦上线，就成了核心业务链路里一环，它的可用性直接影响业务。但是不少企业把 API 网关当“转发器”来部署，生产上只开了一个实例。某次公有云厂商例行维护重启你的网关实例，结果恰好那几小时有大批量业务文件要通过接口传输，整批任务全部失败。
我的建议是：API Management 和 Cloud Integration 的运行时，至少按高可用模式配置，跨可用区部署；关键集成流要有失败重试和告警机制；本地和云端混合场景下，考虑网络链路的冗余。这些“非功能性需求”必须和功能开发同等对待，否则核心清理得再干净，集成层掉链子一样是生产事故。
6.4 一个提效技巧：API 文档与开发门户要前置
Clean Core 项目往往会吸引外围系统大量接入。如果我们到后期才把 API 文档整理好，外围团队开发联调就会被大量“来来回回的问与答”拖慢。API Management 自带的 Developer Portal 可以帮上大忙：API 文档、试用调用、申请订阅，都集中在一个门户上完成。外围开发人员可以自助取得试运行 API Key、查看调用示例，甚至直接在线测试接口，显著减少协作成本。
7. 从 Clean Core 回头看，集成层的意义被大大低估了
说了这么多，其实我想表达的判断很直接：Clean Core 的成败，不在于你从 S/4HANA 里删了多少行 ABAP 代码，而在于你在核心外面建了多么强壮的外围支撑体系。代码删得再干净，如果系统间的连接还是一团乱麻，那只是把“修改标准对象”的问题，换成了“接口失控”的问题，并没有从根本上变干净。
而 SAP Integration Suite 和 API Management 的价值，恰恰在于为“核心外部”提供了结构化的实现方式。它告诉我们：扩展一个系统，不一定要去改它的内部，你完全可以在它的边缘画一条干净的线，然后用被管理的、可观测的、有契约的 API 来完成一切。
这个道理放到更广的视角也说得通：在熵不断增加的企业 IT 版图里，真正的“干净”并不是静止的整洁，而是动态的有序——每一点变化都有章法、每一条连接都看得见、每一次升级都留有余地。Clean Core 项目做到最后，企业获得的并不仅仅是一个“可以安全升级的 S/4HANA”，还有一个资产边界清晰、演进路径明确的整体架构。这个架构的核心支柱之一，就是集成层与 API 层的规范治理。
最后给自己的亲身体会谈一点：做这类项目，别指望一步到位。先把目标定在“不再让核心长出新的杂草”，再逐步修剪旧的杂草。每拆一个自定义对象，就在 API 层新增一个受管服务；每清掉一个手工表读取，就补上一个事件或接口。稳定持续地推进，比一次性大扫除的失败率低得多。核心清理这件事，本质上是把“勇气”变成“耐心”的过程。