企业官网建设流程全解析

第一次接到这个任务时，我差点以为“启用 Analyze Custom Code”是个伪需求。BTP ABAP environment（也叫 SAP BTP ABAP 环境，社区里常说的 Steampunk）不是开箱自带这个应用吗？后来真正在项目里走了一遍才发现，“自带”和“能看见、能授权、能出报告”之间隔着不少配置细节，而且这个小小的应用，在客户从传统 ECC 往 S/4HANA 和 BTP 迁移时，直接决定了我们要花多少时间面对遗留的自定义开发代码。

这篇文章我会从实际落地角度，把在 SAP BTP ABAP environment 中启用 Analyze Custom Code 应用的完整链路捋一遍：先说清楚它到底解决什么问题，再讲应用入口、用户授权、执行分析、报告使用，最后补几个我踩过的坑。适合正在做 BTP 上云评估、S/4HANA 迁移前期调研，或者被领导要求“把自定义代码情况梳理一下”的顾问、BASIS 和 ABAP 开发同学参考。

1. 一次迁移评估从哪开始：自定义代码清单决定项目进度

接触过传统 ECC 迁移项目的朋友都知道，项目启动会上最常问的一个问题不是“数据库用哪个”，而是“我们到底有多少自开发程序”。客户的答案往往非常统一：很多，但没人能给出准确数字。于是分析自定义代码就成了迁移评估里的第一项硬任务，而 Analyze Custom Code 这个应用，正是 SAP 官方在 BTP ABAP environment 上提供的对应工具。

1.1 自定义代码是上云路上最大的“不确定账单”

传统 ECC 系统里，每家公司都会沉淀大量 Z 开头的程序、类、增强、函数模块。这些代码在旧环境里跑得很正常，但到了 S/4HANA 或 BTP ABAP environment 里，情况就完全不同了：数据库表结构变了，部分标准 API 被标记为废弃，有些增强点被新的 BAdI 取代，还有大量隐式增强是“云环境不允许”的。

我之前参与过一个客户评估，他们 ECC 里的自定义 ABAP 对象超过 7000 个。如果不提前做分析，直接往全新环境迁移，上了生产才发现某个核心库存报表无法激活，那就不只是加班返工的问题，而是整个切换窗口都会被堵死。所以尽早把自定义代码扫描一遍，拿到一张可信的清单，是所有后续计划的基础。

1.2 Analyze Custom Code 到底分析什么

这个应用的核心作用，可以理解为针对 ABAP 自定义代码的“体检中心”。它不会直接告诉你“这段代码删掉”，而是围绕几个关键维度给出数据和提示：

• 代码与 S/4HANA 数据模型的兼容性，比如哪些表被替换、哪些字段不再存在；
• 废弃 API 的使用情况，比如还在调用旧的WRITE列表语句、旧函数模块等；
• 自定义代码在自开发对象之间的依赖关系，方便评估改动的影响半径；
• 代码是否包含不适合云环境的元素，比如直接访问数据库的非标准方式、不合规的增强实现等。

这些维度的输出，直接对应迁移排期里“改代码”的工作量。我习惯把它的报告理解成医生体检报告：颜色不同，代表严重程度不同，但最终怎么治疗，还需要结合业务情况判断。

1.3 与 ATC、Readiness Check 的边界不要搞混

很多同事第一次接触这个应用时会问：这不是和 ABAP Test Cockpit（ATC）重复了吗？我在项目里也经常被问到这个问题。

其实两者的侧重点不一样。ATC 更偏开发规范和质量检查，它可以在源系统里扫描代码，检查语法错误、安全漏洞、性能隐患；而 Analyze Custom Code 在 BTP ABAP environment 里的定位更偏向“上云/迁移兼容性分析”，它会结合 ABAP Cloud 模型和 S/4HANA 的变化点，告诉你哪些自定义代码在目标环境里可能存活不下来。我更愿意把它们看成配合关系：先让 ACC 出兼容性问题清单，再针对有问题的对象回 ECC 里用 ATC 做深入分析。两者不是二选一的关系。

提示：如果你当前要做的是本地 ECC 到 S/4HANA 的升级评估，源系统上通常用 SAP Readiness Check 的 Custom Code Analysis 场景；而本文说的 ACC，是在 BTP ABAP environment 租户里分析云环境自定义代码的入口。两者可以配合，但不要完全混为一谈。

2. 把这个应用找出来：两条访问路径与一个易错点

既然是要“启用”这个应用，首先得知道它在哪里。这里说的启用不是 SAP 官方要额外付费开通，而是指把它从系统默认提供、但没有显式暴露的状态，变成业务用户能访问、能使用的状态。

2.1 “扩展应用”藏在 Fiori Launchpad 的分类里

在 BTP ABAP environment 里，Analyze Custom Code 通常以“扩展应用”的形式随环境提供。你登录环境自带的 Fiori Launchpad 后，不一定会在初始页面上直接看到它的磁贴，默认情况下它往往被分配到一个叫“扩展应用”的目录分类里。

我第一次找的时候就在首页翻了半天，后来才意识到要去“应用查找器”或者按名称搜索。如果你在启动板右上角搜索框输入 “Analyze Custom Code” 或缩写 “ACC”，一般能在搜索结果里看到对应的应用卡片。如果搜索结果都没有，那就不是“没启用”，而是你的用户角色里根本没有包含该应用的业务目录，这个问题我在第 3 部分详细说。

2.2 直接 URL 访问的正确姿势

如果通过查找仍然看不到，或者你只想给顾问快速开个临时入口，还可以直接通过 URL 方式访问。BTP ABAP environment 的常见地址格式是：

https://<你的实例ID>.abap.<区域>.hana.ondemand.com/ui2/nwbc?sap-client=100#ExApp-ACC

不同版本和配置下这个链接会有差异，最稳妥的做法是：在 Fiori Launchpad 上找到应用磁贴，用浏览器右键复制链接地址，看实际跳转的对外路径。不要把 URL 在团队之间死记硬背，因为它和你的子账户、实例、区域强相关。

还需要留意一点：直接 URL 访问虽然方便，但应用能否打开、打开后能分析多大范围，最终还是取决于登录用户的权限。URL 能打开不代表这个用户有执行分析的资格，这点很关键。

2.3 在 BTP Cockpit 里核对实例信息

如果你对 URL 没把握，或者想确认这个 ABAP 环境实例的完整服务地址，可以回到 BTP Cockpit 操作：

1. 进入你的子账户（Subaccount）；
2. 在左侧菜单找到“服务实例”（Service Instances）；
3. 找到 ABAP environment 对应的实例条目；
4. 在实例详情页面可以看到连接信息、URL 等关键参数。

这里我建议直接把实例的“应用程序”信息页截屏存档，因为后续配置 Fiori 启动板、发布应用给用户时，经常需要反复回到这里核对地址。另外要养成良好的习惯：拿到一个新环境先确认 ABAP 版本和组件版本，因为 ACC 的分析能力会随着 ABAP 环境版本升级而增强，老版本的界面字段、结果类别可能比新版本少。

3. 启用关键一步：把 ACC 使用权限交到分析人员手里

说句实在话，前两步找到应用本身并不难，这个项目里的坑绝大多数出在权限上。很多人进入 BTP ABAP environment 后，用管理员账号登录启动板，发现什么都能看到；但是换给普通的 ABAP 顾问账号登录后，应用就消失了。这不是应用没启用，而是角色分配没有做好。

3.1 先有一个能登录 ABAP 环境的业务用户

在 BTP ABAP environment 里，用户管理逻辑和传统 ECC 不太一样。ABAP 应用的用户由 ABAP 环境内的“业务用户”（Business User）来维护，而不是在 BTP Cockpit 里直接建个用户就能登进去。

如果你要为分析人员创建用户，路径大致是：ABAP 环境实例左侧菜单中，找到“身份与访问管理”，维护业务用户，然后创建用户并分配业务角色。如果你是用已有的用户，也要确认这个用户至少拥有一个可以访问 Fiori 启动板和 ACC 应用的业务角色。

我自己经历过一种情况：客户临时分配了一个 System 用户给顾问做分析，结果怎么都打不开应用，后来才发现业务用户与系统用户类型不同，系统用户主要用于通信场景，不应该拿来代替业务用户的日常登录。

3.2 分配业务角色：常见最小授权

ACC 应用对应的业务目录，在不同版本里具体名称可能有差异。你可以在“身份与访问管理”里的“业务目录”（Business Catalog）中搜索关键词 “Custom Code”、“Analysis” 或直接看目录 ID 是否包含ACC字样来确认。

实际操作步骤我可以总结成四步：

1. 打开 ABAP 环境实例，进入“身份与访问管理”，选择“业务用户”；
2. 选中要进行授权的分析用户，进入其业务角色分配页签；
3. 如果没有合适的角色，先创建一个业务角色，在角色中添加包含 Analyze Custom Code 应用的业务目录；
4. 保存角色并分配给用户，让用户重新登录 Fiori Launchpad。

如果你的系统使用 SAP 预置的业务角色模板，可以检查当前角色里是否包含“扩展应用”相关的目录。比如业务角色模板SAP_BR_ANALYST在某些版本里会包含分析类应用，但不代表一定包含 ACC，所以要逐个目录检查，不能想当然。

提示：角色修改后，用户重新登录时不一定立即生效。如果发现仍然看不到应用，等待几分钟再刷新，或者确认是否需要在 ABAP 环境的“用户缓存刷新”里做处理。这个点很容易让第一次做权限配置的同事误判为配置失败。

3.3 权限不到位时的典型报错

权限问题最常见的表现有三种，你可以对照自查：

• Fiori 启动板可以正常打开，但搜索不到 Analyze Custom Code，原因通常是业务目录缺失；
• 能看到应用磁贴但点击后报“无授权”或 403 错误，可能是角色里的授权对象不完整；
• 能进入应用但看不到任何分析所需的数据，需要检查用户是否有对应软件组件的读取权限。

我遇到最多的是第一种。有一次我连续检查了修改后的角色分配，怎么都想不通，最后发现角色分配到了用户的某个特殊用户组上，而该用户登录时用的不是那个用户组。所以排查时不要只盯着角色内容本身，也要确认用户登录场景的默认角色上下文。

4. 正式执行一次分析：选择范围、跑后台、看报告

功能和权限都准备好了，接下来进入最核心的部分：真正跑一次完整的自定义代码分析。这个环节不难，但很多同事第一次操作时对着空荡荡的界面不知道该点什么。我尽量把操作路径写具体。

4.1 进入 ACC 首页：先分清两个入口

打开 Analyze Custom Code 应用，通常你会看到主界面和分析相关的内容。如果系统里同时提供“应用程序日志”，不要混淆：应用日志是查看后台分析作业执行情况和报错信息的，而主界面才是创建分析、查看结果的入口。

我的建议是第一次使用时，先花两分钟打开应用日志，确认当前环境是否已经有历史分析作业。如果发现之前有人跑过，直接在旧报告基础上操作，比重新全量扫描省时间。分析作业本身比较重，全量扫描大对象集可能要跑很久，能复用就复用。

4.2 选择分析范围：按包还是按软件组件

创建新的自定义代码分析作业时，你可以选择分析范围。常见的选择维度包括按软件组件（Software Component）和按包（Package）来筛选对象。我的经验是，项目初期建议按软件组件全量跑一次，把家底摸清楚；后续想跟踪某个业务域的重构进度时，再按包的范围做增量分析。

选择范围时还要确认是否包含“使用量统计”之类的选项。如果有相关选项，建议一并打开。单纯看代码兼容性是一回事，但影响度判断离不开数据：如果一个废弃 API 只有一个程序在用，和一个废弃 API 被上百个程序引用，处理优先级完全不同。

4.3 提交后台作业与进度检查

设置好范围后提交分析任务，系统一般会以异步方式运行，别指望像运行一个报表那样秒出结果。尤其是几千个对象的大租户，往往要等十几分钟甚至更久。

这个等待过程里，你可以定期回到应用日志或者分析作业列表里查看任务状态。如果发现任务长时间停在“排队”或“运行中”，不要立刻重复提交，先检查运行日志，看看是不是上一次分析没有释放资源。同一个环境下同时跑多个全量分析，很可能互相拖慢，我见过客户在高峰期连续提交三次全量扫描，结果全部卡住的情况。

第一个全量报告出来后，建议立刻做两件事：一是记录任务的运行时长，后面做定期分析时就知道正常时间范围；二是把报告数据尽早导出到本地，避免下次登录时因为数据量大、加载时间过长导致不方便翻阅。

4.4 数据导出：让报告离开 Web 页面进入项目层

导出的价值非常直接：在线界面适合单点查看，但项目层面需要给开发顾问、项目经理分派任务，必须把报告转成 Excel、CSV 这类可筛选、可排序的文件。

ACC 导出功能通常支持把分析结果下载为本地文件。我在实际项目中会把导出的报告作为迁移跟踪表的输入物，每个有问题的 ABAP 对象后面接一个状态字段：待评估、已修改、已验证、无需处理。这样每周例会直接看表，不用每次都打开系统。

需要留意的是，导出数据量受当前视图筛选条件影响。如果你只想导出某个包下的问题对象，先在界面上把筛选范围缩小，再点导出，否则可能导出几十万行数据，Excel 打开都吃力。

5. 报告结果怎么用：从技术告警排到上云工作量

拿到报告只是开始，真正有价值的是把报告读透。我第一次看到完整结果时，对着几百个红色、橙色条目有点手足无措，后来慢慢总结出一套处理逻辑，这里分享给你。

5.1 结果分类三层：阻断、警告、提示

ACC 的分析结果通常会按严重级别划分。我的习惯是把它们简化理解为三层：

• 阻断级别：这类对象在目标环境里很可能无法激活或无法正确运行，比如引用了已经不存在的表字段、调用了被移除的后台功能。这类必须优先处理；
• 警告级别：代码可以运行或激活，但存在兼容性风险或性能隐患，比如使用了废弃 API，短期内能用，但后续升级可能出问题；
• 提示级别：更多是建议性信息，比如可以换成更优写法，不换也不影响上线。

这个划分不仅帮助团队聚焦，也能向上汇报时用一句话说清现状：“有 15 个对象是阻断级别，3 个属于核心流程，预计需要两周改造。”比甩出一张上千行 Excel 给管理层效果好太多。

5.2 导出报告后如何汇总成上线优先级

报告里每个问题对象都有对应的文件路径、包名、对象类型等基础信息。拿到导出数据后，我会额外加两列：一是业务影响，二是改动工作量。

优先级的判断我常用三维度打分：

按这个思路给清单排序后，你会发现有时候黄色警告比红色提示更值得先处理。比如一个每天被调度 50 次的接口程序使用了废弃 API，即使不阻断，也应该放在高优先级，因为它在生产里每天都在运行，风险敞口更大。

5.3 从分析结果转化为代码改造任务

报告出来之后，每个问题对象要落到具体的开发顾问手里。我在项目里的做法是：把导出结果按包拆分，不同包分配给不同模块开发，每人对自己负责的包做复核。

复核过程中，顾问要结合业务上下文判断“改”还是“弃”：有些自定义代码本身已经没有业务流程在用了，直接标记为废弃删除，比花费精力改造更划算；有些代码功能与标准功能重复，可能只需要调整参数配置就能替代。ACC 给出的是技术事实，但技术事实最终要由熟悉业务的人决策，这一点是分析和改造之间的桥梁。

提示：改造完成后，不要急着把 ACC 报告里的结果手动改成“已修复”，最可靠的方式是重新跑一次该包范围的增量分析，让系统告诉你结果。手动状态维护一多，很容易变成人情账，最后没人知道真实情况。

6. 我踩过的坑和经验法则

最后这部分不讲标准化流程，说说我在客户现场实际踩过的坑。这些坑看起来都很小，但每一个都让项目多耗过时间。

6.1 坑一：应用看不到，不是“没启用”，是角色没配好

前面提过，最容易误导人的就是“有系统管理员账号就能看到 ACC，换成业务顾问就消失”。我见过不止一个团队因为这个现象，误判为“这个环境没有启用自定义代码分析应用”，去开了工单、查了半天文档，其实只是业务角色里的目录缺失。

以后遇到应用消失，先按顺序排查：用户类型是否正确、是否分配了业务角色、角色中是否包含 ACC 目录、登录后是否缓存没刷新、启动板搜索词是否拼写准确。按这个顺序查，基本十分钟内能定位。

6.2 坑二：对象多到导出失败/界面卡死

真实生产租户里，自定义代码可能远超你想象。有一年我帮客户做某大型制造企业的 BTP 环境分析，软件组件里的对象有上万条，第一次直接全量导出，浏览器页面卡了近一分钟，导出文件有几十 MB，Excel 打开后筛选一次转三圈。

我的建议是：导出前先按严重级别或按包缩小范围，分批导出，再在本地用数据透视表汇总。既不要让浏览器承载过大数据量，也不要让一个 Excel 文件承载全量明细。分批导出的好处是，每批结果可以直接分给相应模块的负责人，任务边界清晰。

6.3 坑三：误把 ACC 当成源系统代码的“远程扫描器”

这是一个认知上的坑。BTP ABAP environment 里的 Analyze Custom Code，分析的对象是这个云环境租户里的开发内容，而不是帮你远程扫描公司本地 ECC 里的所有 Z 代码。很多人以为在 BTP 里点一下就能把源 ECC 扫干净，这是错误的。

如果你要做本地 ECC 的存量代码评估，需要用源系统侧对应的工具链（ATC、SAP Readiness Check 等），分析完再把结论作为迁移输入。ACC 解决的是“云环境自定义代码”这半边，两边并不是互相替代。把两者的边界理清楚，项目才不会在评估阶段就漏掉一大部分代码。

6.4 经验：可以建立“定期分析”的节奏

最后分享一个让我后来省了很多事的习惯：不要把 ACC 当成一次性工具。迁移项目上线后，开发往往还会继续，今天新提交的自定义代码，背后可能同样藏着兼容性问题。我后来在项目里会按固定节奏重新跑一次分析，比如每迭代结束跑一次包级分析，把新增的问题在下一迭代里消化掉。

这种节奏化的做法，让自定义代码的“体检”变得常态化。相比一次全量扫描后的忙碌修复，持续的定期扫描虽然每次改动不大，但避免了问题积压。经历过一次客户在 UAT 前夜发现批量问题之后，我对代码体检这件事的态度就是：不要太相信口头承诺，让系统定期给你答案。

在 BTP ABAP environment 里，启用 Analyze Custom Code 应用没有太多神秘感，但它确实是迁移评估和云环境代码治理里最好用的抓手之一。把应用路径、权限、分析执行、报告导出这四件事做扎实，后续代码改造和上线规划就有了可靠的依据。希望这篇实战记录能帮你少走我走过的弯路。