升级前拍胸脯升级后拍脑袋——这句话放在 SAP 系统升级里十次有八次都栽在用户的 Fiori 砖块Tile消失或者点击业务角色里的应用直接报权限不足这类问题上。表面看是权限配置不对实际排查翻到最后几乎都会落到一个共同根源Business Catalog业务目录在升级后变成了废弃状态但没人去接管和治理。我用业务顾问加权限顾问的双重身份带着这个问题在 ECC 升 S/4HANA、以及一个个 Support Package 升级项目里反复折腾过好几轮。这篇就是把为什么废弃、怎么发现、怎么接管、怎么长期治理讲透核心覆盖 PFCG 角色维护、Fiori Launchpad 内容管理、目录替换的实操命令与路径以及最容易踩的坑。适合正在做 S/4HANA 转换、或做了 Fiori 后端升级的 Basis、权限顾问、以及负责业务角色运维的同事参考。1. 升级后为什么会出现废弃 Business Catalog机制拆解1.1 一套目录体系的底层逻辑先厘清几个概念不然后面全是浆糊。Business Catalog 是 Fiori Launchpad 里用来对应用程序应用、Tile、报表、事务代码做分组的一组应用清单。它不是权限对象本身而是应用清单这个中间层。业务角色Business Role在 S/4HANA 环境的 PFCG 里通过引用 Catalog 来获得一组应用访问入口。经典场景是这样的Catalog 负责告诉 Fiori Launchpad我这个分组下面有哪些 Tile角色负责引用 Catalog这个角色的人能看到哪些分组、哪些 TilePFCG 生成授权时Catalog 又映射到一堆底层授权对象OData 服务S_SERVICE、传统事务代码S_TCODE等。所以 Catalog 的地位相当于菜单门禁卡二合一既决定了用户在 Launchpad 上看见什么也决定了访问后端服务时系统认不认。1.2 一场升级如何搅动目录SAP 每发布一个新的支撑包Support Package或者做一次大的版本跃迁比如从 ECCGateway 转 S/4HANA或者从 S/4HANA 1909 升到 2022、2023应用层的变化非常大。常见的变化有一类特别典型老的 FIORI App 被拆成几个新 App或者 App 变了编号于是承载这些应用的 Catalog 也要重组。SAP 的处理方式不是原地修改老 Catalog通常是直接给出一批新 Catalog同时把老 Catalog 打上deprecated废弃标记。于是系统里就出现了两种角色共存的尴尬画面老 Catalog 还在角色还继续引用它新 Catalog 已经激活但没有任何角色引用用户打开 Launchpad 时老 Tile 要么直接消失要么点进去报错要么 App 查找器里找不到入口。更让人头疼的是废弃 Catalog 不会在升级当天自动从角色里移除。SAP 的设计逻辑是给客户一段缓冲期让你自己评估完业务影响后再手动完成替换和清理。这个设计是合理的但如果没人接手就变成了半年后权限一堆脏数据谁也不记得哪个目录该留、哪个该删。我自己的体会搞懂这个机制比急着做操作重要得多。你在 PFCG 里看到的目录引用实际上是角色→目录→应用这条链路的中间态。升级后的目录替换本质是让链路从旧目录平滑切换到新目录同时不丢任何一个应用入口。抓住这个主线后面所有操作都有章可循。2. 接管前必须做的一次全量体检识别与影响分析2.1 三种最靠谱的查找方式接管的第一步是搞清楚项目里到底有多少废弃 Catalog各自被哪些角色引用。我常用的方式就三种按效率排序一种是从 PFCG 入手。打开一个业务角色切到 Fiori 标签页老版本叫 Business Catalog 页签系统会在已经废弃的 Catalog 旁边给出提示或者直接以灰底显示。这种方式适合角色数量少、目标明确的场景几十个角色还能靠人工翻几百个角色就废了。另一种是用/UI2/FLPD_CONFFiori Content Manager即 Fiori 内容管理器。进入后切到 Catalog 列表按系统提供的废弃标记筛选。这个界面的好处是能看到全部 Catalog还能对比几个平替目录缺点是看不到哪个角色在引它。最有用的是把两者结合起来跑一遍整体检查先通过内容管理器拿到废弃目录清单再把这些目录 ID 丢进 SE16N 这类底表查询工具里的角色目录分配表里捞一圈看看哪些角色引用了。我不建议你在没有 ABAP 基础的情况下直接去翻底表——表名在不同版本里会有差异而且 Fiori 相关数据很多是跨客户端的直接操作容易误伤。稳妥的路径是请 Basis 或开发同事帮忙写个简单查询或者导出 PFCG 所有角色的目录引用报表。2.2 影响评估看四个数拿到清单后别急着做替换。下面这四个数必须算清楚这是给业务方拍的证据也是后续治理台账的初始数据废弃目录数量全系统主要是生产环境的真实客户端有几条废弃目录受影响角色数多少业务角色还在引用这些目录受影响用户数这些角色下发给了多少用户注意去重一个用户可能挂多个角色涉及应用数废弃目录里一共包了多少个 App/Tile这些应用在新目录里是否都能找齐。这组数字算完之后你基本就能判断出这次接管的量级是几个角色的小修补还是影响几百用户的大切换。影响面已经足够大时必须走正式的变更评审流程把计划、步骤、回退方案全部写清楚再动生产。2.3 新旧目录的差异对照替换目录之前必须做一次新旧目录的应用级差异比对。SAP 给的替代 Catalog 通常不是 100% 一一对应常见情况有三种场景旧目录新目录替换说明一对一平替SAP_MARKETING_ACTSAP_MARKETING_ACT2应用清单基本一致直接替换即可一对多拆分SAP_FIN_ACCTSAP_FIN_ACCT_AP、SAP_FIN_ACCT_AR按业务域拆开需按用户角色职责分别授权部分废弃SAP_HR_EMP_RECSAP_HR_EMP_REC_V2少量 App 被新目录收录个别被彻底下线差异比对可以靠 Content Manager 里的应用列表手工核对也可以让开发写个小程序把目录里的应用清单导出来做 diff。我建议无论工作量多大都要做这一步因为实际项目里经常出现明明替换了新目录某个岗位的人突然用不了某张报表这种事故查到最后就是目录拆分了漏配了一个应用。顺带提醒一句升级后必须先确认新目录已经在本客户端完成内容激活。内容没有激活的目录就算加进了角色Launchpad 上依然看不到 Tile。激活操作一般通过/UI2/FLPD_CONF里面的内容激活功能做或者跑一次 STC01 的 Fiori 配置任务清单。生产环境做内容激活前务必再一次确认传输方式避免跨环境不一致。3. 接管实操从 PFCG 到 Fiori Launchpad 的全流程3.1 前期准备清单实操开始前我长期经验凝聚成的准备检查表就这几条每次替换前过一遍就不会翻车确认目标客户端通常是 QAS 和 PRD的新目录内容已激活确认新旧目录差异比对完成并且业务负责人对替换结果无异议找一两个典型业务角色和测试用户先在小范围验证角色变更要纳入传输请求不要在 QAS 改完就直接去 PRD 手工改把当前角色的配置截图或者导出保存万一回退有依据。没有准备的接管都是裸奔。尤其是回退方案很多人觉得换目录嘛改回来不就完了实际上一旦角色重新生成授权配置文件改回旧目录后还要再重新生成一次同时还要处理已打开会话里的用户数据回退成本比你想象得高。3.2 PFCG 角色里的目录替换核心操作下面按照最常见的方式用 PFCG 手工替换适合一次处理少量角色也是掌握原理最好的方式进入事务码PFCG输入要修改的角色名点击修改不要直接双击只读查看。切到 Fiori 页签有些版本界面叫Business Catalog系统会列出这个角色引用的全部目录废弃的目录通常有明显标记。先记录旧目录下有哪些应用选中旧目录移除再点击添加目录搜索新目录 ID确认后加入。切到授权页签点击生成按钮重新生成角色授权配置文件。这一步不能省很多新手改完目录没点生成结果用户那边权限缓存没刷新照样报错。保存角色系统会提示分配传输请求。把角色变更放进一个传输请求后续按 DEV→QAS→PRD 的路径传输。传输完成后在目标环境再打开一次角色确认授权配置文件已经生成不要出现配置文件与角色定义不一致的提示。这里有个容易被忽视的细节替换目录后不要只关注目录本身还要看 PFCG 角色里是否还挂着跟旧目录配套的条件比如服务授权条件S_SERVICE。有时候目录删了但老的 OData 服务授权条件还在虽然这次看不出问题但未来会产生授权膨胀。所以顺手清理旧的、已废弃的服务授权条件是有经验顾问和普通顾问的分水岭。3.3 启动测试与回归要点目录替换完接下来最关键的环节是用户视角的验收。我强烈建议不要直接用超级管理员 ID 去测那样只会得到一个系统很干净的假象。正确的做法是用真实的业务测试账号登录 Fiori Launchpad/UI2/FLP检查 Tile 是否出现在正确的分组下逐个点击替换涉及到的核心应用确认能正常打开、能取数、能保存用 App Finder 搜索旧目录里包含的几个应用确认新目录下同样能找到测试另一个极端离职用户、新建用户、只挂部分角色的用户防止出现角色叠加导致的权限异常。回归测试还要注意用户浏览器的 Fiori Launchpad 缓存。很多实施团队在测试时报还是看不到新 Tile最后发现是浏览器缓存或者 Launchpad 自身的客户端缓存问题。测试前先让用户清理浏览器缓存或者在 Launchpad 设置里选择强制刷新能省掉大量无效排查。4. 废弃目录的长期治理规则、工具与节奏4.1 目录台账怎么建接管只是起点真正的价值是把一次性救火变成持续不火。我建议每个项目都建立一个目录治理台账形式不用高大上一张 Excel 或者一个 Wiki 页面就够但字段必须有目录 ID、目录名称、业务域、负责团队当前状态活跃 / 废弃 / 待替换 / 计划下线如果已废弃替代目录 ID 是什么、替换日期是什么引用了该目录的角色清单、用户量级备注比如某个目录只在特殊环境存在。这个台账最大的价值是在半年后、一年后的下一次升级前你能直接拿出一份上次遗留了什么脏数据的清单而不是从头再把系统翻一遍。我自己的项目里每个正经做升级的团队到后期都会回头补台账因为不补的话系统里到底哪些自定义 Catalog 还在被引用、哪些已经是僵尸目录根本没人说得清。4.2 生命周期卡点Catalog 的治理必须设置清晰的生命周期卡点。我的习惯是分四个阶段保留期升级完成后 1~2 个支撑包周期内新旧目录并存业务还可以继续用旧目录里的应用替换期完成差异比对、角色替换、回归测试明确替代目录冻结期废弃目录不再允许新建角色引用通过权限流程把关新角色申请一律使用新目录清理期确认所有引用已清除且替代目录稳定运行后关闭废弃目录的内容激活状态或者从 Launchpad 内容清单中剔除。注意清理期不要去物理删除系统交付的标准目录你删一个 SAP 交付内容下次升级它又冒出来了搞不好还带上传输错误。合理的做法是通过架构层面即不引用它、不在角色里关联它让它逻辑死亡而不是物理删除。掌握了这个思路后续维护会省去大量与 SAP 标准内容反复拉扯的时间。4.3 治理节奏与健康检查不要把治理做成一年一次的运动式扫荡。我建议把 Catalog 健康检查固化到月度维护窗口里面每次花不超过半小时做三件事用 Content Manager 检查有没有新增的废弃标记 Catalog跑一遍角色目录引用报表看有没有角色还挂着废弃目录检查有没有零引用的僵尸角色既有角色既无用户分配又无组织分配。这三件事看着简单但坚持做下来能在问题从一个废弃目录扩大到整片权限架构混乱之前提前发现。还有一点值得做把SU01里的用户登录对比和权限审计结合定期检查那些拥有大量过期角色引用但从不登录的用户这类账号经常是废弃目录残留的温床。5. 常见问题和踩坑记录九条实战经验5.1 目录只能换不能删这是最常见的认知误区。不是不能删引用而是不要删系统目录对象本身。标准目录属于 SAP 交付内容在 Content Manager 里做删除操作往往不受支持或者下次升级又回来。正确动作是从所有角色里移除对废弃目录的引用确保没有自定义角色再关联它通过内容激活状态控制它不出现在 Launchpad 上。说到底治理目标是让系统里没有角色再引用它而不是让系统里不存在这条目录记录。想通这一点就不会跟系统里的标准内容死磕了。5.2 测试与生产环境表现不一致测试环境替换得好好的传上生产后 Tile 消失了或者应用能打开但界面报 OData 服务错误。这类问题九成以上出在内容激活和传输范围上新目录在测试环境激活了但激活内容没有通过同一个传输请求传到生产角色传输了但角色依赖的自定义服务例如用户升级的自开发 Fiori App没有一并传输生产环境里 OData 服务的S_SERVICE授权条件没更新角色引用了新目录但后端服务不认。排查顺序建议先检查生产环境的新目录是否激活再检查角色授权配置文件是否重新生成最后检查后端服务的 ICF 节点和 OData 服务激活状态。不要一上来就怀疑权限很多时候是内容根本没到位。5.3 其他高频问题速查下面这些是我在实际项目中遇到过不止一次的问题我整理成速查表给你表现常见原因处理方法角色里加新目录后保存报错目录内容尚未激活或目录 ID 输入错误去/UI2/FLPD_CONF确认目录状态复制准确 ID避免手输用户仍能看到废弃 Tile点击报权限不足用户浏览器/Launchpad 缓存清缓存强制刷新 Launchpad部分用户能看到新 Tile部分看不到用户角色没有传输完成或用户没被重新分配角色核对传输请求记录检查SU01用户角色分配替换后某报表应用消失新旧目录是拆分关系漏配了某个目录参照2.3差异比对表补配角色生成授权时报大量警告底层服务授权条件未同步运行权限调整相关任务清单如 SU25 相关步骤生成最新授权变更角色已切换新目录但 OData 调用失败后端 ICF 服务节点未激活通过 SICF 激活对应服务节点再测一次再补两条真心话式的心得其一换目录永远不要赶在业务月结那几天。别看目录替换是个轻操作一旦牵扯到 OData 服务激活和授权配置文件重新生成生产环境出现个几分钟的服务中断都够你写半小时解释邮件。我一般安排在月初第一周或月中空窗期。其二角色多的情况下不要一个个手改。如果项目里受影响角色上百个这时候还靠 PFCG 手工替换效率太低了。更合理的做法是先用自动化方式把重复性操作批处理掉比如借助 SAP 提供的批量角色维护工具或脚本批量处理完再做抽样核对。Batch 的好处是减少漏改坏处是容易批量出错所以批量执行前一定先在小范围试跑。结尾最后说点个人体会。SAP 升级后的废弃 Business Catalog 接管技术门槛不高真正考验的是细心和治理习惯。我见过太多项目在升级完那几天全员扑到线上救火把目录替换做了却没人记录替换映射关系结果一年后下一次升级浪潮来的时候又是同一批角色踩同一批坑。你要想在这个领域少走弯路就从建台账开始把每次替换的旧目录→新目录→替换时间→影响角色都记录下来。这个 Excel 花不了你两个小时但它会在每一次后续升级、每一次权限审计、每一次岗位调整时帮你把问题从全量排查降维成定点确认。
