曾有一个企业客户，从老版本 ECC 往 S/4HANA 迁移，立项之初还挺乐观，结果一盘点代码库，发现过去十多年里在标准程序上直接改了 300 多处。消息传出来，项目工期直接从 12 个月变成了 20 个月，预算翻了一倍多，业务天天来催，IT 负责人愁得嘴上都起了泡。这场景我见过太多次了，根子不在迁移动作本身，而在于早些年“遇事不决改标准”的开发习惯。现在 SAP 把Released API和Clean Core抬到战略高度，很多人还觉得就是个理念，其实这两件事直接决定未来升级一次要花多少钱、AI 能力能不能接进来、审计那一关过不过得去。这篇文章我就用项目视角把这两件事讲透，讲清楚它们是什么、为什么重要、以及团队里怎么一点点把系统“洗干净”。
适合读这篇文章的人，主要是 SAP 开发顾问、ERP 系统负责人、以及负责数字化转型的架构师。如果你现在正维护一套被“黑代码”折磨的系统，或者准备上 S/4HANA，又或者只是想在团队里立一套可长期执行的开发规矩，这篇文章都能给你一套可落地的方法，而不是停在概念层面。
1. 先搞清楚 Released API 到底是什么
1.1 为什么 SAP 突然强调“已发布”这个概念
SAP 这几年反复讲 Released API，翻译成大白话就是：我官方承诺，这些接口从今天起保持稳定，未来升级不会变，你只管放心用。
以前老开发们习惯用哪些东西？RFC 函数、BAPI、直接读透明表、甚至去调那些没有公开文档的类方法。这些在老 ECC 时代能跑，但那会儿 SAP 没承诺过它们永远不改。等系统版本一升级，函数接口参数变了、表结构调整了、某个标准类方法内部实现重写了，你的代码就“断裂”了——编译过不去，或者运行结果完全不对。
而 Released API 相当于一份“接口稳定契约”。SAP 给它定义了发布状态（Release State），凡是标记为 Released 的类、方法、接口、CDS 视图、OData 服务，SAP 都保证在后续版本里保持行为兼容。这里面分两层：C1 表示在本地部署环境可用，C2 表示在云环境也可用。换句话说，你只要构建在这类 API 之上，未来升级 S/4HANA、甚至迁到 RISE 这种云订阅模式，代码基本不用动。
我用个生活类比帮你记。假如你家水龙头坏了，物业告诉你：只能用带“官方认证”标记的配件，别去五金店买那些便宜杂牌。杂牌配件今天能装上，但以后水管改造可能就拧不上了。Released API 就是那批官方认证件，贵一点，但未来各种改造都兼容。
1.2 在代码层面怎么识别一个 API 是否 Released
开发的时候怎么知道某个类或方法到底可不可靠？总不能在 SAP 文档里翻半天吧。其实工具链早就把信息暴露出来了。
如果你用 ABAP Development Tools（ADT）做开发，在 IDE 里打开某个类或方法，左侧能看到一个细小的“状态”标识，有的是绿色对勾，有的带黄色感叹号。绿色通常说明这个对象或其中某些 API 已经是 Released 状态；非 Released 的话，SAP 会标注为“内部使用”或“受限”，在有些版本里直接显示一个锁的图标，提示你不要在自己的代码里去调用它。
更硬核的检查手段是 ATC 检查（ABAP Test Cockpit）。我在项目里要求所有开发人员提交代码之前，必须用默认的 Check Variant 跑一遍 ATC。如果代码里调用了非 Released API，ATC 会直接报一条类似“使用非发布 API”的警告或错误，并链接到对应 API 的发布状态说明。这样相当于在“菜出锅前”就拦了一道，而不是等客户上线之后被升级事故教育一顿。
有一点容易踩坑：不是所有 Released 都长一个样子。有的 API 是整类发布，有的只是其中某几个方法发布。你在 ADT 里点开某个类，看到类本身是 Released 状态，但内部某方法可能明确写着“内部使用”。所以检查不能只看类级别，要精确到方法级别。我们团队就遇到过这种情况：开发同事看到类标了绿色，放心写代码，结果调的方法恰恰是没发布的内部方法，ATC 一跑就红了。
2. Clean Core 不是什么“洁癖”，是战略底线
2.1 Clean Core 的定义与行业背景
Clean Core 这个概念，最早是从 S/4HANA Cloud 那边推出来的。因为云环境的升级节奏跟本地部署完全不一样，软件是 SAP 统一控制的，客户没有权限去改标准程序。如果每个人都在标准代码上“开洞”，云环境下根本没法升级，甚至别的租户出个补丁都会受影响。所以 SAP 逼出了一个原则：标准系统保持干净，业务差异化通过受支持的扩展点去实现。
这个原则后来放到了本地部署的 S/4HANA 上，并且写进了官方评估体系。做 SAP 审计或者升级前评估的时候，咨询顾问会专门查你的系统里改了多少标准对象、在多少标准程序里做了隐式增强、直接修改了多少 SAP 交付的类和方法。如果统计结果是一长串，基本可以判断这个系统离 Cloud Ready 还有很长的路要走。
说白了吧，Clean Core 的核心不是“不许碰标准”，而是**“允许你扩展，但要按规定的姿势扩展”**。就像公寓楼里你可以自己装修房间，但承重墙不能砸，公共管井不能动，改变房屋外立面更不行。你的“家”可以乱一点，但“楼体结构”必须稳。
2.2 三层扩展模型怎么落地
SAP 官方把扩展方式分了三种，重要性从上往下递进：
第一种：In-App Extensibility（应用内扩展）。就是在标准应用里做有限度的自定义，比如给标准字段加校验规则、在标准界面加个自定义字段、在标准流程里挂一个自己的逻辑。这些扩展通过 SAP 提供的增强点（Enhancement Point / BAdI）来落地，代码虽然写在系统里，但不会直接改动 SAP 的标准对象。升级的时候，SAP 会专门保护这些扩展点，尽量保留你的逻辑。
第二种：Key User Extensibility（关键用户扩展）。这是给业务人员用的，不用写代码，直接在界面上通过“自定义字段”或“自定义逻辑”功能，给标准的 Fiori 应用增加字段和简单校验。好处是极轻量，升级基本零风险。很多企业上了 S/4HANA 之后，IT 团队教几个关键用户自己拖字段，效果比提需求给开发还快。
第三种：Side-by-Side Extensibility（并行扩展）。就是说不把逻辑写进 SAP 系统里，而是放到旁边的外围平台，通过调用 Released API 与 SAP 交互。例如把复杂业务流程搬到外部服务里，SAP 只保留核心数据，两者用 OData、事件或消息队列通信。这是 Clean Core 里最彻底的一种，也是 SAP 向云时代迁移时最推崇的模式。
这三种扩展模式的差异，我用一张表直接对比：
| 维度 | 改标准程序 | 应用内增强（BAdI/扩展点） | 并行扩展（Side-by-Side） |
|---|---|---|---|
| 升级风险 | 极高，可能直接被覆盖或冲突 | 低，SAP 提供增强契约保护 | 极低，外部系统与核心隔离 |
| 开发门槛 | 较低但危险 | 中等，需懂增强框架 | 较高，需懂集成与外部技术栈 |
| 灵活性 | 很高，但不可维护 | 中高，受扩展点范围限制 | 极高，可实现复杂领域逻辑 |
| Clean 程度 | 全污染 | 基本干净 | 最干净 |
我在实际项目里见过太多团队，一开始图省事走了第一种路线，觉得直接改标准程序最快。等到做升级评估的时候才发现，SAP 把所有被修改的标准对象列了一份清单，交到客户手里，那份清单几乎成了“病历本”。这才回头去重构，成本高到可以再做一个新项目。
2.3 不 Clean 的代码会带来什么后果
既然 Clean Core 是战略底线，那触碰底线的代价是什么？我说三个最常见也最疼的后果。
第一个是升级阻塞。SAP 不可能让每个客户都停留在老版本，安全补丁、法律合规更新、新功能都跟版本挂钩。但每次升级，最虚的就是那一堆直接改过的标准代码。我参与过一个模拟评估项目，客户的系统里改过一个销售订单的标准 BAdI 实现，内部大量依赖某个非 Released 的内部类。升级前测试时那个类的方法签名变了，结果订单流程直接“坏”了。最后项目组花了整整两周来适配新版本，业务停摆期间损失无法估量。
第二个是创新碰壁。SAP 现在把生成式 AI、自动化流程、预测分析这些能力放在新的云底座上，很多新能力只开放了标准 API，而且云环境只能接 Released API。如果你本地系统的扩展都是“黑代码”，那这些新能力根本没法顺利接进来。不是技术接不了，而是数据源头被污染了，AI 模型跑出来的结果你都不敢信。
第三个是审计与合规过不了。现在很多企业内部合规或者外部监管，开始明确要求“核心 ERP 系统的扩展应以受支持方式实现”。如果你的系统里有一堆未知来源的代码修改，解释成本会变得极高。我在项目上见过客户被审计问询，一份关于标准对象修改的清单就要写几百字的变更说明，还未必能提供当年为什么改的详细设计文档。
3. 项目里怎么把“不够干净”的系统掰回来
3.1 第一步：先盘出自己有多少“脏代码”
不要一上来就“重构”，先摸清家底。改造一项技术债务之前，你得知道负债规模有多大。
最扎实的第一步是用 ATC 跑一遍全局代码分析，把所有与 Released 状态相关的警告和错误收集出来。注意，ATC 的 Check Variant 有很多，默认的那个可能不会把所有规则都打开。我在项目上会单独建一个自定义检查变体，把这几类规则打开：非 Released API 调用、废弃语法使用、权限检查缺失、FORM 子程序未封装。跑完之后导出 Excel，按程序名排序，这就是一份很直观的“污染地图”。
第二步是查标准对象的修改历史。在 SE03 或者事务代码 SE11 里都能找到对象目录条目，但更直接的方法是查版本管理或传输记录。我们常用一个数据库表 TADIR，结合更新的请求号，找出那些 SAPP 开头的标准包下面，曾经被修改过的对象清单。清单出来后，按优先级排一下：直接影响核心业务流程（销售订单、采购、财务）的先动，别的可以往后放。
第三步是检查隐式增强。这个容易漏。很多人觉得自己没“改”过程序，只是加了段逻辑。但隐式增强挂载在标准代码的缝隙里，升级时照样可能出问题。我见过一个最极端的案例：某公司的增强点挂在标准函数内部，且从 ADT 视图看没有归属的包，升级时 SAP 的标准对象全部被覆盖，增强逻辑直接“蒸发”，业务发现某个校验突然没了，追查了两天才想起来这回事。
3.2 第二步：把“改标准代码”迁移到“释放的 API”
摸清家底之后，接下来就是动刀了。核心思路是：凡是直接改标准程序的地方，只要 SAP 提供了受支持的扩展点或 Released 接口，就把它替换掉。
拿一个真实场景举例。客户原先在某个标准报表里加了一段逻辑：从自定义表里读取额外费用项，再拼到输出结果里。这种需求在 ABAP 里最常见的实现方式，是直接拷贝标准报表到自定义程序里改，或者改标准程序源代码加上一段 READ TABLE。这既不 Clean，升级也容易出问题。
替代方案是什么？SAP 在 S/4HANA 里提供了大量针对特定业务的扩展 BAdI。比如销售订单流程有专门的 BAdI，可以影响价格、文本、单据复制；物料管理有采购订单增强点。把原来的“直接写死逻辑”改成挂载到一个 BAdI 实现类里，通过接口拿到上下文（如抬头、项目、数量），再执行自己的校验或数据处理，最后通过 RETURN 结构把结果传回去。这就不碰标准代码了，升级风险完全可控。
再拿调用数据做个例子：以前大家习惯直接读透明表，比如从 MARA、MARC 里自己 Join。现在 SAP 发布了不少 CDS 视图作为 Released 接口，带好语义和权限控制，直接用 SELECT * FROM 某个已发布的 CDS 视图 反而更安全。风险在于有些老业务很依赖未公开表格的字段，如果确实没有对应 CDS 视图，那就通过 RFC 调用 BAPI，或者通过 OData 服务走标准暴露逻辑。
我强烈建议团队在替换时做一个“迁移清单”，每项写清楚：原实现方式、改造方案、替代接口名称、测试要点、上线时间。这会让整个改造变成可追踪的项目，而不是随缘修修补补。
提示：不要试图一次性把所有“脏代码”都替换光。要按业务的支付意愿和风险排序，一年拆成几个迭代逐步做。Clean Core 是一个目标状态，不是一天能到位的终点。
3.3 第三步：定规矩，防止再犯
好不容易把系统洗干净，如果团队开发习惯不改，三个月之后又脏回来了。所以最后一步，是把“只能使用 Released API”变成一条硬性开发规范，并且用技术手段强制执行。
首先在开发规范文档里写清楚：项目中所有自定义 ABAP 代码，均不得调用非 Released API；若因业务确实需要调用，必须先发起豁免申请，说明原因、替代方案评估、风险缓解措施，由架构组审批。这个流程看起来多一道，但它能极度减少“图省事”的调用。
其次把 ATC 检查嵌到 CI/CD 流水线里。现在很多 SAP 项目已经用 Deploy 管道管理传输，可以在管道里加一步：跑 ATC，统计新增错误数量。如果本次发布引入了新的非 Released API 错误，管道直接 fail。这样不是靠人盯着，而是让工具把红线立起来。
第三个规矩是关于“扩展包”设计。建议团队内部约定：所有自定义代码一律放在 $ 开头的命名空间下，且必须有独立的软件组件或包结构。这样以后做审计、做 ATC 筛选都方便。我们项目里会专门把所有自定义包挂到一个传输请求下，用 SE03 能一眼看到所有传给业务对象的请求，排查问题效率高很多。
4. 常见问题与排查技巧实录
4.1 ATC 报错“使用了非 Released API”，怎么办
这个是最常见的报错了。很多年轻顾问第一反应是“既然是内部 API，那为什么我还能调用？”答案是：ABAP 语言本身没有在编译期禁止调用非 Released API，只是 SAP 通过 ATC 规则来约束你。也就是说，代码能跑，但会被“记录在案”。
处理方式分两步。第一步是评估：这个非 Released API 是否真的无可替代。打开 SAP 的 API 文档（或者在浏览器搜 “Release State API”），看看有没有功能相近的 Released 版本。大多数时候都是有的，只是参数不太一样，稍微适配一下就行。第二步是如果没有替代品，就发起豁免：写清楚为什么必须用、影响范围、未来何时替换，交给架构评审。记住，豁免不是免责，只是“有记录的容许”，还是要定时回头复查。
4.2 升级时发现标准对象被改，怎么评估影响
很多老系统在做 S/4HANA 升级评估时，会突然发现自己改过哪些标准对象。此时不要慌，先把清单下载下来，按功能模块分类：哪些改的是逻辑（比如销售订单的 Pricing 计算）、哪些改的是界面（屏幕布局）、哪些改的是数据字典（表追加字段）。其中，屏幕和数据字典层面的修改往往可以考虑用“平台迁移”的思维来处理——重新做成自定义字段或 Side-by-Side 扩展；逻辑层面的修改则需要逐个分析，看 SAP 新版本里是否已经有对应标准功能，如果有，直接移除自己的修改，启用新功能。
这里要特别注意：不要拿着老版本的理解去判断新版本“有没有这个功能”。S/4HANA 里很多逻辑大改过，以前你要改成标准程序来实现的，现在可能内置的配置项就搞定了。最好的做法是先跑一遍业务流程，逐个确认新系统的标准行为，再决定是否保留旧逻辑。
4.3 某些需求官方没有提供 Released API，怎么做扩展
确实，不是所有需求都有官方接口。比如某些企业内部非常冷门的行业特殊流程，SAP 没有标准功能，也没有现成的 BAdI。这种时候我做过的合理方案是：如果在应用内扩展点都找不到，那就把这块逻辑彻底挪到外部系统，用并行扩展的方式实现。定义一个对外接口（OData/RFC），从 S/4HANA 侧通过标准 Released 服务（如 API Business Hub 上公开的接口）把主数据或业务数据发出，在外面算好结果，再通过标准接口写回来。外部环境技术选型就自由了，也不污染核心。
还有一种“次优”但常见的选择：在自定义程序里“复制”标准数据逻辑。比如某些数据只存在于标准表，但标准程序未公开视图，你可以用 BAPI 读取数据后再在内部做计算。虽然比直接读表多一道转换，但至少你用的是 Released 的 BAPI，升级不会出隐患。
4.4 隐式增强要不要清理
不少人问：隐式增强既不是改标准代码，又能实现很多需求，为什么也要清理？答案是：隐式增强挂靠在标准对象内部，升级时 SAP 不保证它一定兼容。它不像 BAdI 那样是官方定义的扩展点，SAP 只保证“增强点所在的位置在新版本中依然存在”，但没法保证增强里调用什么内部结构不换。
所以我的建议是：短期可以保留，但长期要迁移。凡是只能在隐式增强里做的需求，先纳入“技术债清单”，排期逐步改成正式的 BAdI 或者 Side-by-Side 扩展。别嫌麻烦，一旦升级碰上隐式增强失效，排查代价比现在重构高一个数量级。
4.5 常见问题速查表
| 症状 | 可能原因 | 处理建议 |
|---|---|---|
| ATC 报非 Released API 错误 | 代码直接调用了内部类/方法 | 优先替换为 Released 版本，必要时走豁免流程 |
| 升级测试时某流程崩溃 | 直接修改了标准程序，SAP 升级覆盖逻辑 | 回退自定义修改，重新评估新版本标准行为 |
| 隐式增强逻辑消失 | 标准程序被覆盖，增强代码丢失 | 立即排查版本管理，重建并制定迁移计划 |
| 无法从标准表读取数据 | 表结构或权限模型变化 | 改用 Released CDS 视图或 BAPI 访问 |
| 审计要求提供扩展清单 | 系统里自定义代码分散无归属 | 建立自定义包结构，用 ATC 和 TADIR 生成清单 |
5. 我的一些实操建议
做这些评估和迁移这么多次，我个人最深的体会是：技术问题往往不是最难解决的，组织习惯才是最难的。很多团队明明知道直接改标准代码是饮鸩止渴，但项目压力一来，还是选择“先上线再说”。所以如果要让 Clean Core 真正落地，第一件事不是在代码层面动手，而是先跟管理层讲清楚“现在用几周改造，远比未来用几个月补救便宜得多”。拿一两个真实升级案例做铺垫，效果比讲一百条道理都强。
另外有一件小事值得马上做：让团队每个人都养成“打开 ATC 检查”的习惯。我在自己的环境里把保存前自动检查都开着，代码一 Save，如果引用了非 Released API，立刻就红色波浪线。这个习惯建立起来，比任何 Review 流程都好用。
如果你所在的系统已经特别脏，不要想着一年内全改成 Clean Core。先挑一个核心业务模块，比如订单到收款（OTC），把这一条线里面所有非 Released 调用全部清干净，做成一个“示范样板间”。下次审计或者升级前评估，拿这个模块出来讲，说服力极强。踩过几次坑之后你会认同：Release API 和 Clean Core 不是文档里飘着的概念，而是每个还在用 SAP 的人都该早点建立的习惯。
