第一次接到这个任务时我差点以为“启用 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 CockpitATC重复了吗我在项目里也经常被问到这个问题。其实两者的侧重点不一样。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-client100#ExApp-ACC不同版本和配置下这个链接会有差异最稳妥的做法是在 Fiori Launchpad 上找到应用磁贴用浏览器右键复制链接地址看实际跳转的对外路径。不要把 URL 在团队之间死记硬背因为它和你的子账户、实例、区域强相关。还需要留意一点直接 URL 访问虽然方便但应用能否打开、打开后能分析多大范围最终还是取决于登录用户的权限。URL 能打开不代表这个用户有执行分析的资格这点很关键。2.3 在 BTP Cockpit 里核对实例信息如果你对 URL 没把握或者想确认这个 ABAP 环境实例的完整服务地址可以回到 BTP Cockpit 操作进入你的子账户Subaccount在左侧菜单找到“服务实例”Service Instances找到 ABAP environment 对应的实例条目在实例详情页面可以看到连接信息、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字样来确认。实际操作步骤我可以总结成四步打开 ABAP 环境实例进入“身份与访问管理”选择“业务用户”选中要进行授权的分析用户进入其业务角色分配页签如果没有合适的角色先创建一个业务角色在角色中添加包含 Analyze Custom Code 应用的业务目录保存角色并分配给用户让用户重新登录 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 环境分析软件组件里的对象有上万条第一次直接全量导出浏览器页面卡了近一分钟导出文件有几十 MBExcel 打开后筛选一次转三圈。我的建议是导出前先按严重级别或按包缩小范围分批导出再在本地用数据透视表汇总。既不要让浏览器承载过大数据量也不要让一个 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 应用没有太多神秘感但它确实是迁移评估和云环境代码治理里最好用的抓手之一。把应用路径、权限、分析执行、报告导出这四件事做扎实后续代码改造和上线规划就有了可靠的依据。希望这篇实战记录能帮你少走我走过的弯路。 
长河君 · 2026/10/9 4:24:51 · 阅读 1.2k SAP BTP ABAP环境启用Analyze Custom Code实战指南
第一次接到这个任务时我差点以为“启用 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 CockpitATC重复了吗我在项目里也经常被问到这个问题。其实两者的侧重点不一样。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-client100#ExApp-ACC不同版本和配置下这个链接会有差异最稳妥的做法是在 Fiori Launchpad 上找到应用磁贴用浏览器右键复制链接地址看实际跳转的对外路径。不要把 URL 在团队之间死记硬背因为它和你的子账户、实例、区域强相关。还需要留意一点直接 URL 访问虽然方便但应用能否打开、打开后能分析多大范围最终还是取决于登录用户的权限。URL 能打开不代表这个用户有执行分析的资格这点很关键。2.3 在 BTP Cockpit 里核对实例信息如果你对 URL 没把握或者想确认这个 ABAP 环境实例的完整服务地址可以回到 BTP Cockpit 操作进入你的子账户Subaccount在左侧菜单找到“服务实例”Service Instances找到 ABAP environment 对应的实例条目在实例详情页面可以看到连接信息、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字样来确认。实际操作步骤我可以总结成四步打开 ABAP 环境实例进入“身份与访问管理”选择“业务用户”选中要进行授权的分析用户进入其业务角色分配页签如果没有合适的角色先创建一个业务角色在角色中添加包含 Analyze Custom Code 应用的业务目录保存角色并分配给用户让用户重新登录 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 环境分析软件组件里的对象有上万条第一次直接全量导出浏览器页面卡了近一分钟导出文件有几十 MBExcel 打开后筛选一次转三圈。我的建议是导出前先按严重级别或按包缩小范围分批导出再在本地用数据透视表汇总。既不要让浏览器承载过大数据量也不要让一个 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 应用没有太多神秘感但它确实是迁移评估和云环境代码治理里最好用的抓手之一。把应用路径、权限、分析执行、报告导出这四件事做扎实后续代码改造和上线规划就有了可靠的依据。希望这篇实战记录能帮你少走我走过的弯路。