曾有一个企业客户从老版本 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 ToolsADT做开发在 IDE 里打开某个类或方法左侧能看到一个细小的“状态”标识有的是绿色对勾有的带黄色感叹号。绿色通常说明这个对象或其中某些 API 已经是 Released 状态非 Released 的话SAP 会标注为“内部使用”或“受限”在有些版本里直接显示一个锁的图标提示你不要在自己的代码里去调用它。更硬核的检查手段是 ATC 检查ABAP Test Cockpit。我在项目里要求所有开发人员提交代码之前必须用默认的 Check Variant 跑一遍 ATC。如果代码里调用了非 Released APIATC 会直接报一条类似“使用非发布 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 的人都该早点建立的习惯。
