在SAP项目里待久了，你会发现一个很现实的问题：不管当初开发计划排得多周密，系统上线三五年之后，ABAP开发对象一定会有大量冗余。Y报表、Z程序、临时接口、实验性类，像衣柜里过季的衣服一样越堆越多。更麻烦的是这些旧对象不是你想删就能删，删了怕某个没人知道的报表突然在用，不删又让系统越来越臃肿，传输请求也变得难维护。我见过不少团队被这个问题卡住，最后只能把整个开发包标记成“废弃”，丢在一边眼不见为净。
其实，ABAP开发对象的废弃有一套正规且成熟的做法，涵盖了依赖分析、传输管理、版本记录和团队协作规则。这篇文章我会把整套流程拆开讲清楚，从为什么不能直接删除，到具体怎么标记、怎么删、怎么留记录，再到增强、接口、CDS视图这些特殊对象该怎么处理，一次性讲透。无论你是刚接手老项目的ABAP新人，还是正在做系统清理的技术顾问，都能直接拿去用。
1. 先搞清楚“废弃”到底是什么意思
1.1 废弃不等于删除，也不等于“不活动”
很多开发人员听到废弃，第一反应就是直接进SE80把对象删掉，或者更粗暴一点，把程序属性里的“不活动”勾上就算完事。这两种做法都不完整。ABAP开发对象在SAP系统里不是孤立存在的，它上面挂着传输请求、版本记录、授权对象、应用数据甚至下游接口的引用。直接删除会让这些关联全部断掉，运气不好就是生产事故。
在SAP的世界里，废弃（Retirement）应该被理解成一套受控的退场流程：先确认对象不再被任何业务路径引用，再通过标准的传输机制将改动带到生产系统，同时在对象历史中保留痕迹，让后来的人能查到这个对象存在过、为什么被废弃、被什么替代了。这个流程的核心目标有两个，一是降低系统复杂度，二是保证可追溯性。审计也好、下一次做系统升级也好，你都得说得清楚每一个被废弃对象的来龙去脉。
1.2 为什么不能直接删除旧对象
我遇到过不少新同事问我同一个问题：这个报表明明没人用了，为什么不能直接删掉？我说“没人用”这四个字你得先证明给我看。你怎么证明全公司几百个用户里没有人通过自定义菜单、后台Job、其他程序的Call Transaction去调用它？怎么证明这个报表没有在月末某次导出中被财务手动执行过？你怎么证明某个后台作业在特定月份才运行一次，恰好这个月还没跑到？
更深一层的问题在于业务审计和合规要求。SAP系统是很多企业的核心业务系统，所有开发对象的历史版本和变更记录都承载着审计价值。你今天觉得没用的报表，可能记录了去年某个政策调整期间的业务逻辑历史。彻底删除之后，如果审计需要回溯当时的处理逻辑，你没办法恢复。这时候保留废弃对象比删掉它更有价值。所以很多规范化做得好的企业，对旧对象的第一选择是“标记不活动”和“移入废弃开发类”，而不是删除。
还有一个很现实的工程原因：传输请求和版本管理的约束。ABAP对象的删除动作本身也是一个变更，它要走传输请求，要经过测试，要发布到生产。一旦你在生产系统删掉一个对象，而某个自定义代码或SAP标准功能还在运行期动态生成对它的调用，系统会直接报运行时错误LOAD_PROGRAM_NOT_FOUND或CX_SY_DYN_CALL_ILLEGAL_METHOD。这种错误发生在月末结账或者生产高峰期，场面会非常难看。
2. 废弃前的依赖分析：不是“我觉得没用”就算数
2.1 用Where-Used List查引用关系
开始废弃任何对象之前，第一件必做的事是查它的“使用位置清单”（Where-Used List）。在SE80里选中对象，菜单“Goto -> Where-Used List”，或者在SE38里直接按Shift+F7，系统会扫描整个ABAP代码库，找到所有引用了这个对象的代码位置。这个信息能告诉你，当前对象被哪些程序、类、方法、函数组或者数据库视图引用，是静态引用还是动态调用。
这里要多说一句：Where-Used List查的是静态引用，也就是代码里直接写死对象名的地方。对于动态调用，比如用GENERATE SUBROUTINE POOL、CALL TRANSACTION 'ZPP001'、CALL METHOD (l_class_name)=>method这类写法，静态扫描工具是看不到的。所以依赖分析不能只看Where-Used结果，还要配合全文本搜索。我自己的经验是，在SE38里用“Search String”功能搜索对象名的子串，比如把报表名去掉前导“Z”之后的特征值扔进去搜，能捞出一些动态拼名的调用。搜出来的结果可能有很多无关数据，但宁可多花十分钟人工过滤，也好过漏掉一个隐藏调用方。
2.2 用Code Inspector做静态扫描
说罢手动方式，再介绍SAP官方的静态检查工具 Code Inspector（事务码SCI）。有些项目从没配过SCI，这很可惜。SCI可以自定义检查变式（Check Variant），把性能、安全性、语法兼容性、废弃API使用等检查项目组合起来，定时跑一遍全库扫描，输出的结果会明确指出代码哪里用了该废弃的接口、哪里调用了不存在的对象。在做对象级废弃清理时，我通常会在SCI里建一个专门的检查变式，只勾选“对象引用完整性”和“废弃对象使用”相关的检查类，然后针对候选废弃对象列表里的每一个对象单独执行检查。
实际执行方式有两种，简单一点的在SCI界面里选“Object Set”指定某个开发包或某个对象列表，复杂一点的是通过程序RS_SCANNER_GET_USAGES结合ABAP代码批量扫描所有开发对象对目标对象的引用。后者更适合要一次性清理几十上百个对象的大项目。用SCI的好处是它有标准化的输出格式，可以直接导出成清单，发给业务签字确认“这个报表真的没用了”。做系统清理这种事，留一份业务签字的确认记录，能帮你规避掉绝大多数后期扯皮。
2.3 借助运行时日志确认真实使用情况
静态扫描解决的是“能不能找到引用”的问题，运行时分析解决的是“实际有没有被调用过”的问题。如果静态扫描的结果是零引用，但你觉得不放心，可以用SAP的运行时分析工具（事务码SAT，旧的SE30）对关键流程做一次性能追踪，或者用ST05启用SQL跟踪，观察一段时间内是否有请求命中目标表或目标程序。更直接一点的做法是查看ABAP应用服务器日志（事务码SM21）和系统审计日志，找可疑的访问记录。
针对接口类废弃对象，我强烈建议先统计生产系统的接口调用日志，看过去6到12个月内有没有外部系统还在调这个RFC或Web服务。如果日志数据保留周期不够长，就主动在代码的入口处加一条临时的日志记录，记录调用方系统标识和调用时间，在接口正式废弃前部署一个“观察期”版本，观察一到三个月。这段观察期数据就是废弃决策最硬的依据。
2.4 制定废弃清单和优先级
依赖分析做完之后，你会发现候选对象可以分成几类。第一类是完全没有引用、日志里也查不到调用的，这类是“安全废弃”；第二类是引用方极少（比如只有一两个无关紧要的测试程序）的，这类需要处理掉引用方再废弃；第三类是还在正常使用的，这类要么不废弃，要么先做替换再进入废弃流程；第四类是引用方式很隐晦，查不清的，这类先挂起观察，不轻易动它。
我会按这个分类给每个对象标上P0、P1、P2的优先级。P0表示“可以立即处理”，P1表示“处理前需要清理引用方”，P2表示“暂缓处理，定期复查”。这份清单连同每项的分析依据、处理方式一起形成文档，作为整个废弃流程的输入资料。这个文档不单是给自己看的，更是给项目组同事、给IT审计看的。
3. 标准化的废弃操作：不活动和删除的正确打开方式
3.1 程序的“不活动”标记与传输策略
对报表程序、函数模块、类等ABAP开发对象，最简单也最稳妥的废弃方式是在属性层面标记“不活动”。以报表程序为例，打开SE38输入程序名，进入属性页（Attributes），把“Status”从“已保存”改成“不活动”（Inactive）。保存后这个程序在开发系统中会灰显，运行时如果被调用，系统会向错误日志写入一条记录，但不会立刻终止调用。这个温和的“护栏”能让你在真实业务中观察到是否还有调用方冒出来，而不是一刀切杀干净。
标记不活动之后，程序会进入一个传输请求。很多项目会有一个专门存放废弃对象的开发类或者传输层，你可以创建一个名为ZLEGACY或者ZDEPRECATED的开发包，把这些废弃对象统一移动到里面。移动对象用SE03的“Move Object”功能（事务码SE03里有很多对象移动和传输辅助功能），把对象从一个开发包移到另一个开发包，一并纳入传输请求。给废弃对象一个专门的开发包，最大的好处是后续做系统拷贝、做开发包级传输、做系统翻版时有清晰的边界，不会误带一些废弃代码进新环境。
3.2 类的废弃：保留“壳”比删得干净更重要
面向对象ABAP里的类，废弃策略要更精细一点。一个类里可能有几十个方法，其中有几个还被人用着，其余都过时了。这种场景强制删除整个类并不合理。我的建议是：对还需要的方法保留在线；对确定没有调用的方法，在方法级别的注释块里写明@deprecated标记，并在方法第一行日志记录调用情况；对完全没有使用方的类，可以整体标记为废弃。
特别注意一点，一个类一旦被标记为不活动或者处于“已删除但未激活”状态，运行期任何动态创建该类实例的代码都会抛异常。所以类的废弃不能走“先删掉试试”的路子，一定要确保所有引用点都处理干净。处理旧类还有一个常见的替代思路，就是保留类定义，但让所有废弃方法直接抛出CX_STATIC_CHECK异常，并提示业务方改用新类。这样的好处是调用方程序代码不用全改，运行时一旦触发废弃方法，立刻能看到明确的报错提示，知道该去哪迁移。很多企业在做ABAP新语法迁移时，就是用这种方式把老的MOVE、COLLECT写法对应的辅助类逐步替换掉的。
3.3 表与结构的废弃：先处理数据再处理定义
表和结构是ABAP开发对象里最敏感的一类，因为底下压着业务数据。废弃一张自定义表（Z表）之前，必须先确认表里的数据还有没有保留价值。有归档需求的，用SAP标准归档工具（事务码SARJ）或者自定义归档程序把数据导到归档存储，留下归档索引；没有保留价值的，也要在删除前做一次完整的数据备份，导出成文件存档，再在系统中执行删除。我经手过一个库存相关的Z表，废弃前看着只有几千行，删完第二天业务说还要补一个月的追溯报表，幸好当时做了物理备份才没酿成大祸。
表的删除在DDIC层面用SE11操作，删除时会弹出一堆确认窗口，包括“这个表正在被程序引用，确定要删除吗”之类的警告。这里不建议直接强删，稳妥做法是先删除表对应的维护视图、搜索帮助、表类型等附属对象，再删除表本身。表的附属对象删除顺序错了，系统会提示“对象被其他对象使用”，而且报错信息还不一定直观，光靠试错会浪费很多时间。结构（Structure）的废弃类似，但影响范围更大，因为结构往往被函数模块、类方法、ALV输出引用的很广，动之前务必做一轮完整影响分析。
3.4 删除操作的正确方式与传输注意事项
真正要彻底删除对象时，SAP提供了标准的删除流程。在SE80的对象树里，选中对象右键选择“删除”，系统会弹出提示，要求将这个操作分配到一个传输请求。删除动作本身不会立即生效，会先标记对象为“已删除未激活”状态，等你释放传输请求并传到生产系统后，删除才会落实。
这里有一个非常容易踩的坑：删除对象后，它的传输请求里可能同时包含了你这次做的其他改动。如果你在同一个请求里既改了程序A又删除了程序B，运输到生产后，程序B的删除生效，程序A的修改也生效，但这两个操作的测试范围完全不同。一旦生产出问题，回滚时要么两个一起回，要么一起不回。所以我自己做删除操作时，永远单独开一个传输请求，并且打上“Delete Only”的标题说明，跟其他正常开发请求完全分开。理由很简单，删除对象的回滚策略和普通代码修改不一样，单独隔离能极大降低生产事故的影响面。
4. 特殊对象的废弃细节：增强、接口、CDS和RAP
4.1 增强（Enhancement）的废弃
SAP ABAP里的增强有隐式增强（Implicit Enhancement）和显式增强（Explicit Enhancement）之分，显式增强又分Enhancement Spot和Source Code Enhancement，另外还有老的BADI实现和新的Enhancement Implementation。废弃增强最容易犯的错是只删掉增强实现，忘了把入口点（Enhancement Point/Spot）一起清理。入口点还在的话，业务代码里就留着一个“可以插入代码但不生效”的钩子，后续做系统升级或者代码扫描时会出现一堆误导性告警。
使用事务码SE19可以看到所有BADI实现，SE18查看BADI定义，增强的启用和停用也在这两个事务的界面里操作。操作时先禁用实现，再删除实现，最后判断入口点和增强点是否还需要保留。对没有继承者的旧增强，我的经验是入口点也别急着删，因为它影响面极小，但能保留一份代码级的历史痕迹，将来做代码回溯时有据可查。真正要删的只是实现里边的代码逻辑。
4.2 接口对象的废弃策略
接口类是另一个重灾区。老项目里往往有大量历史RFC函数模块，当年给外围系统调用的，如今外围系统早就换成了REST/API，但这些RFC函数模块还在系统中躺着。接口类废弃绝对不能只盯着ABAP这一侧，需要跟外围系统的负责人确认对方的调用配置已下线。我在一个项目上处理过一批废弃RFC，本地分析结果干干净净，传到生产后不到一周，就有一个外围系统的定时任务因为RFC不存在而告警。事后查原因，发现对方系统的接口配置发了新版本但没部署，老版本还在轮询我们的RFC。
正确处理流程分三步。第一步，在接口实现中加入调用日志并设置告警，观察一到两个月。第二步，跟外围团队拿到书面的“已停用确认”。第三步，把接口状态在SAP端标记为“废弃”，必要时修改接口的ABAP侧文档说明，但不是删除。对于替换类的接口，比如从RFC迁移到OData或RAP服务，还需要保留旧接口一段时间做兼容，新旧并行，直到新接口的稳定性得到确认。很多企业会定义六个月的兼容期，这个数字没有标准答案，跟业务风险承受能力挂钩。
4.3 CDS视图和RAP BO的废弃
随着SAP BTP和S/4HANA的推广，CDS视图和RAP（ABAP RESTful Application Programming Model）对象越来越多，它们也进入了需要废弃的范畴。CDS视图的废弃有个特殊麻烦：CDS视图之间存在复杂的依赖关系，一个视图可能被好几个其他视图或者行为定义（Behavior Definition）引用，删除时系统给出的报错提示经常只能定位到第一层依赖，需要一层层手工往下找。
处理CDS视图废弃，我通常先在Eclipse的ABAP开发工具（ADT）里查看该视图的“Where-Used”导航，把多层依赖全部展开，形成一张依赖树。然后从依赖树的最底层往上逐层废弃，保证每个视图被删时已经没有任何上游引用。RAP BO的废弃相对简单，因为RAP对象在Fiori应用里都会有配套的服务绑定和服务发布，先取消服务发布，再删行为定义、投影视图、CDS实体，企稳后再清理UI层的Fiori磁贴和目录。RAP对象的废弃一定要走完整的Fiori服务生命周期管理，只删ABAP侧对象而不清理前端配置，会造成Fiori应用启动后白屏或者数据加载失败。
5. 流程与规范配套：让废弃工作可管理、可审计
5.1 建立废弃对象清单模板
做任何一次系统清理，我都会先建立一个废弃对象清单，格式类似这样：
| 对象类型 | 对象名称 | 废弃原因 | 替代对象 | 分析方式 | 优先级 | 操作方式 | 传输请求号 | 操作日期 | 操作人 | 状态 |
|---|---|---|---|---|---|---|---|---|---|---|
| 报表程序 | ZRPT_OLD_INV | 被ZRPT_NEW_INV替代，业务确认停用 | ZRPT_NEW_INV | Where-Used+SCI+业务签字 | P0 | 标记不活动 | S4DK900123 | 2025-01-15 | ZhangSan | 已完成 |
| 函数模块 | ZRFC_OLD_SYNC | 外围系统切换接口 | ZODATA_NEW_SYNC | 观察期+外围确认 | P1 | 保留但标记废弃 | S4DK900134 | 2025-02-01 | LiSi | 观察中 |
| 数据库表 | ZT_STALE_LOG | 业务数据已归档 | 无 | 备份+业务签字 | P1 | 先归档后删除 | S4DK900145 | 2025-02-10 | WangWu | 待传输 |
| CDS视图 | ZCDS_OLD_VIEW | 被新视图替代 | ZCDS_NEW_VIEW | ADT依赖分析 | P2 | 逐层删除 | 未分配 | 未执行 | 未执行 | 待处理 |
这张表是整个废弃工作的项目看板。每一项的“分析方式”必须写明判断依据，“操作方式”写明具体动作。有了这张表，你在每周例会上报进度时心里完全有底，审计来查时也能直接提供完整的操作链路。清单我建议放到一个共享文档里，不要只存在于某一个人的本地Excel。
5.2 版本管理与代码备份
不管用哪种方式废弃对象，保留历史代码版本都是底线。SAP的版本管理在事务码SE03里有专门的版本查看功能，也可以直接用SE38或SE80的“版本管理”菜单查看程序历史版本。不过这里要特别提醒：SAP的版本管理只保留“激活版本”之间的差异历史，如果对象刚创建完就一直没改过，然后直接删除，版本历史里可能只有几个很早期的版本，无法还原到最新状态。
所以在删掉对象之前，我会把源代码文件从系统中直接导出到本地版本库或公司代码仓库。导出程序源码用SE38进入编辑界面，菜单“程序 -> 导出 -> 保存到文件”，选择ASCII或ANSI编码。函数模块、类等对象也能用类似方式导出或者用ABAP程序自动下载。导出的文件存放在统一的归档目录里，命名规则跟废弃清单保持一致，比如ZRPT_OLD_INV_20250115_废弃前源码.txt。这么做虽然麻烦一点，但好处是即使以后需要逆向还原，也有完整的源码可以用。
5.3 定义项目的“完成定义”
团队合作时最关键的一个动作，是在废弃工作开始前就定义什么是“完成”。我见过太多开发一删了之然后继续写新功能的情况，过几个月又来问“那个对象删了之后，是不是把认可文档也更新一下”。为了让废弃工作真正闭环，我建议至少定义以下几项为必须完成的操作：
- 废弃对象清单已更新，且每个对象都填写了操作结果和传输请求号
- 业务方已在确认文件中签字，确认该对象已实际停用
- 相关源代码和数据结构已做归档备份
- 废弃操作已通过单独传输请求发布到生产系统
- 生产系统运行观察期（至少两个星期）内没有关联业务告警
- 项目文档和运维手册中已移除对已废弃对象的引用
哪天这六条全部打勾，这项废弃工作才算真正结束。否则最多算“做了一半”。
6. 实际操作中会遇到的麻烦与排查思路
6.1 对象删除时报“无法删除，因为对象被使用”
这是最常见的报错。遇到这个提示，别急着强行删除。SAP给出的“被使用”往往不是业务层引用，而是技术性引用，常见的有程序里的INCLUDE语句、函数组的包含对象、后台作业里的步骤、变式（Variant）中的引用、以及授权对象里的权限设置。逐个排查的方式是先用SE80的Where-Used查一遍，再看报错信息里带了哪些对象类型，然后用单独的搜索事务（比如SE38的搜索功能、SE16N查变式表VARID和VARIT）把引用找出。
如果实在找不出引用但系统还是提示占用，有一个容易被忽略的坑：对象在传输请求中还没有释放，处于“已检出”状态。SE03里有“释放请求”和“删除过期请求”的功能，把这个对象从挂起的请求中释放掉，再试删除通常会成功。
6.2 传输请求包含太多无关对象
之前提到的单独请求问题，在实际操作中反复出现。原因在于很多开发人员习惯在一个请求下连续工作好几个小时，期间顺手做了多个对象的操作，删除也混在里面。想避免这种状况，最好在每次删除操作前检查一下当前请求里都有哪些对象，确认没有夹带私货再放行。如果发现请求里已经有不相关的对象，打开SE03的“修改请求”功能，把对象从请求里抽出来分到正确的请求中。
这里我想分享一下自己的习惯：我平时在开发系统中会建一个命名规则为K9K9DELETE+日期的传输请求，专门用来做对象删除或移动。每次动手前，在SE03里查看这个请求是否为空，确认是空的才执行删除。这样不仅操作路径清晰，后续查看传输记录时也一目了然。
6.3 生产系统里对象“删不掉”的错觉
有时候开发系统删除后传到生产系统，发现目标对象还在。先别急着怀疑SAP删除逻辑不生效，多数情况是传输没有真正完成。检查STMS（传输管理系统）里的导入队列，看看导入是否报错。经常会遇到的一个情况是：生产系统中该对象正在被某个进程锁定，比如还在使用的程序被某个月结作业加载到共享内存，删除导入被系统拒绝。这种锁定通常不会永久持续，等业务低峰期重新导入一次就能解决。
还有一种情况比较隐蔽：对象虽然删除了，但生产系统客户端缓存或者共享内存里还残留着旧版本。这种状态一般不影响系统运行，但如果你马上做一个动态调用，系统可能还会用缓存里的旧代码执行一次，然后才报找不到对象的错误。处理方式是在完成删除传输后，用事务码SCC1或执行一次客户端缓存刷新，让系统彻底清理旧对象的内存残留。
6.4 我总结的几个避坑习惯
做ABAP开发对象废弃处理这些年，我踩过不少坑，最后养成了几个固定习惯，这里一并分享给大家。
第一，删除前永远先导出源码和数据结构，而且导出文件放到公司统一的代码仓库，不放在个人电脑上。第二，一个对象废弃完成后，立刻在废弃清单里打勾并记录传输请求号，不拖延，好记性不如烂笔头。第三，废弃操作传输到生产后，设置一个两周左右的观察期，期间每天检查一次系统日志（SM21）和后台作业日志（SM37），有任何异常先回滚再说。第四，对一切有业务数据依托的对象，永远先备份数据再动定义，备份文件要保留足够长时间，建议至少保留一个季度。
这些习惯看起来都是不起眼的小动作，但在真正出问题的时候，能帮你省下一个通宵排查的时间。我做系统清理项目时，最怕的不是清理工作量太大，而是清理完之后业务突然说“少了什么东西”。有了这些习惯，我可以很肯定地回答：数据在，源码在，日志在，随时可以还原。
这个事情的后续扩展空间也不小。S/4HANA迁移时做代码整流、ABAP新语法替换时做老代码退役、甚至做系统合并时清理重复对象，本质上用的都是同一套废弃方法论。把这套流程跑顺了，以后再遇到什么对象退场，心里就会有完整的底气，不会再陷入“删还是不删”的纠结里。
