上个月在客户现场做S/4HANA升级收尾Fiori Launchpad一打开就出现一屏灰色磁贴用户点进去全是No data或者直接跳权限报错。查了一圈根源不是权限角色没配好而是升级前一直被忽略的Business Catalog业务目录被系统标记成了废弃状态。这类问题在SAP升级项目里非常典型尤其是从NetWeaver Gateway老架构升级到新的Fiori技术栈时旧目录的接管和治理如果没有提前规划上线日就是背锅日。这篇文章把我从原理到实战的完整处理过程写出来内容包括Business Catalog为什么会在升级后被废弃、如何快速评估影响面、用标准手段做目录接管与数据迁移以及升级后如何建立常态化治理机制让废弃目录不再反复变成定时炸弹。SAP Basis顾问、Fiori项目团队、以及负责权限和系统架构的同事都可以直接参考里面的操作步骤和排查思路都是可以直接复现的。1. Business Catalog废弃背后的机制升级后为什么会变成死目录1.1 Catalog在Fiori架构中的位置角色、目录、磁贴三层关系要理解废弃的根源先得把Business Catalog在整个Fiori权限和内容分发体系里的位置搞清楚。SAP Fiori的权限和界面内容分发是典型的三层结构第一层业务角色PFCG Role。管理员在PFCG里创建角色往角色里塞授权对象、事务代码同时也会把一组业务目录分配给角色。第二层Business Catalog业务目录。这是一个逻辑容器里面装着若干组Groups。Catalog本身不直接决定用户能不能执行后台事务但它决定了用户在Fiori Launchpad上能看到什么入口。第三层Tile和Target Mapping。磁贴是用户点下去的入口Target Mapping负责把磁贴映射到具体的前端应用或后端OData服务。用户登录Fiori Launchpad后系统汇总他所有角色里的Catalog渲染出工作台上的组和磁贴。这一套设计的初衷是让权限控制和界面呈现解耦——你可以在不碰授权对象的情况下调整某个岗位的用户界面也可以在不改UI的情况下收紧后端访问。问题也出在这套灵活性上。Catalog的数量会随着项目规模膨胀尤其是老项目的Catalog命名和版本管理通常比较随性。很多公司从ECC 旧NetWeaver Portal架构升级到S/4HANA Fiori或者从Fiori Foundation老版本升级到新Fiori云就绪架构时系统里会同时存在几十甚至上百个Catalog其中一大部分还是旧架构时代留下的升级过程中系统会自动给它们打上废弃标记。1.2 废弃的四种触发场景谁在何时把Catalog标记成废弃我处理过不少升级后目录失效的案例总结下来Business Catalog被标记为废弃Deprecated的主流路径有四种场景一SAP标准Catalog被新版本替代。SAP从Fiori Foundation向Fiori Cloud Ready演进时很多标准Catalog经历了多次改名和合并。比如老的SAP_BC_FES_*系列目录在S/4HANA 2020之后的版本里被并入新的SAP_FESF_*或业务线专属目录。系统在升级过程中会自动把旧目录标记为废弃并在标准目录说明里注明replaced by xxx。问题是你角色里还引用着旧目录用户在Launchpad上自然什么都看不到。场景二升级过程中目录内容校验失败。Fiori的基础组件升级会重新做一次Catalog一致性检查凡是引用了不存在的OData服务、指向已删除的应用别名、或者Target Mapping已经失效的Catalog系统会在升级日志里将其标记为不一致Inconsistent进而提示废弃。这类Catalog属于技术上仍然存在但业务上已经残废的状态。场景三系统迁移/客户增强冲突。把老系统通过SUM或S/4HANA转换迁移到新架构时客户曾经在NetWeaver Portal里自定义的Catalog对象如果带有非法命名空间比如沿用旧的CUST_前缀加非规范字符升级会把它们归入未知来源默认按废弃处理。场景四人为废弃。项目实施过程中顾问们把某些目录下线了但没清理角色引用Catalog身上的废弃标记就是上一任管理员手动打上去的。这种最常见也最坑因为追溯起来几乎没有文档只能靠现场排查。明白了这四种触发源头就知道接管不是简单地把废弃标记解除就完事。你要做的是判断这个Catalog所承载的内容还有没有价值、角色还在不在引用、有没有替代目录然后才谈得上下一步动作。2. 接管前的现状盘查如何精确评估废弃Catalog的影响面2.1 摸清Catalog与角色、用户的绑定关系不急着改任何东西先把影响面摸清楚。我常用的排查链路分三步走。第一步从Fiori Catalog目录表里拉出全部废弃清单。核心表是/UI2/CATALOG自定义Catalog以及标准Catalog的视图。Fiori技术栈的目录状态字段在/UI2/CATALOGS里可以直接按废弃状态过滤。我习惯用这个查询把系统内所有Catalog的KEY、标题、命名空间和状态一起拉出来放到Excel里做后续分析SQL大致长这样SELECT CAT_KEY, CAT_TXT, NAMESPACE, PARENT_KEY, DEVCLASS, CH_USER, CH_TMSTMP FROM /UI2/CATALOGS WHERE ACTIVE X AND ABLETYPE C ORDER BY NAMESPACE, CAT_KEY;第二步反查废弃Catalog被哪些角色引用。Catalog在PFCG角色里的分配信息可以通过两种途径获得。一种是直接进PFCG逐个看角色但角色一多就累死。更高效的做法是用权限报表的事务代码或者直接SQL查AGR_TCD和AGR_1251相关的授权对象表。这里我推荐一个相对冷门但极实用的方法用事务代码SUIM选择角色菜单下的角色含特定菜单/权限报表输入你要查的Catalog名称就能一次性列出所有引用了该Catalog的角色清单。第三步从角色反查用户。上一步筛出引用废弃Catalog的角色后再用SUIM按角色查用户或者直接用AGR_USERS表关联。这一步必须做因为影响面最终要落到人的维度。把这三步做完你手上会得到一张废弃Catalog - 影响角色 - 影响用户的全链路清单。到了这一步别急着动手接管还要先识别出替代目录。2.2 识别替代目录标准替代与自建目录的对照对SAP标准目录最权威的信息源是SAP Note和Fiori Content的官方页面。升级项目的标准动作是在升级前的项目准备阶段打开SAP Fiori Apps Reference Library在SAP Help Portal里搜索Fiori apps reference library搜索你目前在用的标准Catalog名称看官方标注的替代关系。多数官方废弃Catalog都会明确写出Application Component和Cross-version compatibility信息。有一些老目录对应的新目录会直接带后缀比如从SAP_HCM_BC_*升级到SAP_HCM_EMP_*系列时磁贴入口基本可以平移。对自建目录替代关系就要靠内容对照。把旧Catalog里的Tile清单导出来对照新系统Fiori Launchpad Designer里的Tile库存逐个确认功能入口是否存在。这里有个实用技巧从/UI2/TILE表里按TILE_KEY抓取旧目录的磁贴清单再在目标系统里用事务代码/UI2/FLPD_CONF打开Fiori Launchpad Designer搜索同名Tile看是否已经被迁移到新Catalog里。如果内容存在但目录不同接管方案就从续命旧目录变成迁移到新目录。2.3 影响面评估的三个维度用户、权限、性能用户维度上面已经提到了要统计受影响的用户数并且按部门/岗位分组。注意有一种隐蔽情况——有些用户可能通过多个角色间接引用同一废弃Catalog统计去重时别把重复用户数算进总影响人数。权限维度Catalog废弃不等于用户执行后台事务的权限被回收权限是由角色上的授权对象决定的。影响的是用户界面入口是否可见。所以评估时要区分两类影响入口丢失但不影响业务执行用户还能用事务代码/SAP GUI操作入口丢失且业务中断比如审批任务入口、填单入口没了用户完全无法完成操作第二类影响要按P1级别对待直接决定接管顺序。性能维度废弃Catalog影响性能不是它本身占资源而是角色分配里大量引用废弃Catalog会导致Launchpad启动时做无效的Catalog解析。我一个客户出现过这种症状Fiori Launchpad登录后要转十几秒才出磁贴查到最后就是角色里挂着几十个废弃Catalog每次启动前端都去做一次无效内容拉取和权限过滤。清理掉之后登录速度快了近一半。所以性能评估时重点看引用废弃Catalog的角色有多少个、这些角色被多少用户加载数据量大就值得在接管方案里把清理废弃引用当成性能优化来做。3. 废弃Catalog的接管实战从目录替换到数据迁移3.1 方案选型替换角色引用还是迁移Catalog本身排查做完真正的接管决策点来了。表格对比三种主流方案方便你根据现场情况做选择接管方案适用场景操作复杂度风险等级主要弊端方案A角色引用替换有标准替代目录且功能一一对应低低需要逐角色修改引用较多时工作量递增方案B自建Catalog迁移旧Catalog里有自建Tile没有现成替代中高中需要处理Tile、Target Mapping、OData服务的成套迁移方案C保留废弃Catalog但解除废弃标记系统升级导致误标废弃内容本身仍有效低高不推荐长期会积累技术债后续再次升级大概率复发我的建议是优先做方案A需要保留自建内容时做方案B方案C只作为一个过渡性应急动作绝不能当成最终结果。原因有三第一解除废弃标记只解决了眼前界面空白的急救问题但Catalog本身的技术状态还是旧版本下一次升级时还会触发同样的故障治标不治本。第二SAP新版本里对Catalog的校验越来越严格老目录即便强制激活也可能在后续的补充升级中被再次强制失效到时候你又要返工。第三从长期维护角度看同一种业务功能同时存在于新旧两套Catalog里对后续排错和权限审计都是负担。3.2 实操步骤以Fiori角色替换为例的完整操作链先讲方案A的完整落地过程。假设排查结果表明废弃目录SAP_HCM_BC_OLD里装的都是员工自助的入口个人信息、工资单、请假申请而新系统里有标准替代品SAP_HCM_EMP_1功能基本一致。完整操作链分五步第一步在沙盘或开发系统中创建一个临时角色副本。用事务代码PFCG复制原角色ZHR_EMPLOYEE为ZHR_EMPLOYEE_NEW。在菜单页签里把旧Catalog移除加入SAP_HCM_EMP_1。别直接改生产角色先在开发系统里验证无误再走传输这是铁律。第二步逐项核对新Catalog里的磁贴映射。在PFCG里点开新目录看里面的Tile列表是否覆盖了旧目录的所有关键入口。尤其要检查Target Mapping对应的OData服务是否已在后端系统激活事务代码用/IWFND/MAINT_SERVICE逐个服务名点进去激活。这一步最容易踩坑因为角色替换后提示Service not available十有八九是OData服务没激活。第三步事务代码SU53权限模拟校验。角色复制和目录调整做完后用SU53对关键用户做授权追踪或者更高效地给测试用户分配新角色后直接在Fiori Launchpad里登录调出每个关键磁贴验证实际可用性。别只验证磁贴显示出来了要真的点进去走一遍业务流程因为有些磁贴对应的后端事务在新版本里的权限对象名发生了变化。第四步传输到测试系统跑UAT确认。开发系统验证通过后通过STMS传输到测试系统让关键用户在测试环境反复验证。第五步生产切换。生产环境替换角色引用时按用户批次操作。我常用的做法是先在PFCG里对角色ZHR_EMPLOYEE做菜单页签替换保存后立刻让一组业务用户登录验证确认无误后再让所有用户重新登录。注意Fiori Launchpad有缓存机制角色变化后不是每个人刷新页面就能立刻看到效果可能需要清一下前端缓存或者等缓存刷新周期结束。3.3 自建Catalog的迁移导出、导入与传输如果旧Catalog里有一部分是业务部门自建的入口比如公司内部的报表磁贴、自定义审批入口没有标准替代那就要走方案B做自建Catalog迁移。这块操作细节比角色替换复杂不少我给出一套经过验证的完整链路。第一段链路导出旧目录及其磁贴定义。在旧系统里用事务代码/UI2/FLPD_CONF打开Fiori Launchpad Designer找到废弃Catalog把Catalog下的所有Group和Tile先导出为本地文件。导出时会连带输出每个Tile的Target Mapping配置。这里有个关键提醒导出的内容只包含Catalog元数据不包含后端配置。如果Tile对应的应用是自定义Fiori应用或第三方应用还要把后端的OData服务、IWFND配置、以及可能存在的后端BSP应用一并迁移到新系统。很多人只导了前端的Tile定义结果新系统目录建好了磁贴在页面上是灰的。第二段链路在新系统创建新Catalog并导入。在新系统里通过/UI2/FLPD_CONF点击创建目录命名空间建议用Z开头名称要能一眼看出用途如ZHR_EMP_ESS_V2。然后把你导出的内容导入进去。导入后逐Tile检查状态确认每个Tile的Target Mapping都指向了有效的服务地址。第三段链路传输与激活。自建Catalog的传输有个独有特性Catalog对象在CTS传输里往往需要连带/UI2/这一整套前端内容一起走。如果你用的是传统CTS确保在SE03里把Transport Request包含的对象检查完整尤其是/UI2/CATALOG、/UI2/TILE、/UI2/FLP这几个表条目。新一些的S/4HANA系统支持gCTS用站点级别的传输更稳妥但要注意不同的前端服务器架构下gCTS的部署配置。传完后同样要在目标系统里重新激活OData服务并在/UI2/FLP用户设置里刷新Catalog缓存。3.4 升级完成后的验证清单与回滚策略所有接管操作做完验证工作不能只停留在用户能打开Launchpad这个层面。我整理了一份我每次都会用的验证清单贴在下面供你复制使用。业务可用性验证关键用户的每个磁贴入口均可达点击后后台事务正常执行新目录对应的Target Mapping引用的OData服务全部激活用/IWFND/MAINT_SERVICE逐一核验用SU53抽查2-3个代表用户确认新角色的权限对象能覆盖实际业务操作对涉及审批、工作流入口的场景额外做一遍任务列表刷新测试确认待办事项正常显示系统一致性验证旧废弃Catalog在角色上的引用已经清零用SUIM反查角色菜单确认无残留Fiori Launchpad登录耗时恢复合理水平排除废弃Catalog加载拖慢现象系统日志事务代码SLG1里没有新的Catalog相关错误记录回滚策略接管操作的回滚相对简单但前提是你在操作前留了完整的备份。我的习惯是在PFCG里做角色替换前先导出角色菜单结构在/UI2/FLPD_CONF里做Catalog导入前先导出原Catalog配置。如果生产切换后2小时内发现问题直接按备份把角色引用恢复到旧Catalog同时保留新Catalog不做删除避免二次切换时还要重做导出。若超过2小时且业务已经开始使用新入口则不建议回滚改为走增补修复的渠道。4. 治理机制落地让废弃Catalog不再成为升级遗留债4.1 建立Catalog命名与版本规范从源头减少废弃升级后接管做得再好都不如让废弃Catalog一开始就别产生那么多。治本之道是建立一套简单但强制执行的Catalog治理规范。命名规范上我建议所有自建Catalog统一用Z模块业务线版本的结构。比如ZCUST_PROD_ESS_V2看到名字就知道是客户主数据、生产领域、员工自助场景、第二版。反面教材就是我亲眼见过的一些项目Catalog名字叫TEST_BK、Fiori_New2这类内容是什么谁都不记得升级时自然断不清弃留。版本管理上Catalog创建时就在描述字段里写明创建日期、创建人、适用范围、关联角色清单。这个字段平时没人看但在升级排查时就是救命文档。还有一点很实用SAP允许在Catalog描述里写业务Owner把业务负责人姓名联系方式写进去遇到这个Catalog能不能删的裁决时你直接能找到拍板的人。4.2 把Catalog治理嵌入升级项目生命周期Catalog治理不能等升级那天才想起来而是要嵌入整个项目的四个关键节点。项目启动阶段做一次完整的Catalog盘点把废弃和在用两类分开归档确定每个Catalog的业务Owner形成Catalog治理责任人清单。这一步可以和权限盘点合并做但一定要单独输出一份Catalog维度的报表别混在角色清单里。蓝图设计阶段对照SAP标准替代目录清单列出所有可能受影响的Catalog逐项确认替代方案。这个清单是整个接管工作的路线图比到上线时再排查效率高一倍不止。开发测试阶段做Catalog的传输测试时同一套Catalog要在开发、测试、生产三个环境间保持内容一致。我见过不止一次开发系统里Catalog内容更新了但生产系统里还是旧版本升级一上线旧内容全部报错。解决办法是建立Catalog版本对照表每个环境升级部署后都做一次Catalog内容快照。上线切换前最后做一次废弃Catalog引用全量扫描确保方案A的角色替换和方案B的自建迁移全部落地。这个节点宁可多花一天做验证也不要仓促上线。4.3 常态化监控定期审计无效Catalog与授权引用治理机制的最后一块是让维护动作周期化、可量化。我给客户的推荐是做一个季度性的Catalog健康度检查检查项就三条。第一用/UI2/CATALOGS表按状态过滤废弃Catalog检查数量是否有增长。新增的废弃Catalog如果出现在最近一个季度且没有对应的接管记录就要立刻追溯。第二用SUIM反查所有引用废弃Catalog的角色确保为零。这个检查可以在作业层面做自动化把结果邮件发给负责权限的管理员比人工查靠谱得多。第三做一个Fiori Launchpad启动性能的抽检。Catalog引用清理前后的效果往往立竿见影你把这个数据扔给管理层看也比说一千句治理很重要更有说服力。另外补充一个我在多个项目中反复遇到的细节升级后的Catalog清理一定要安排专人跟踪。这不是说简单派一个人干活而是要指定一个Catalog维护人给他明确的职责边界——负责定期导出目录清单、核查废弃状态、维护Catalog版本备注、跟进每一次升级前后的接管闭环。很多公司就是缺了这样一个明确的Owner才让Catalog问题从升级到上线反复复发。我自己的体会是Business Catalog的接管与治理难点不在于某个具体的操作命令而在于把目录当成一个和权限、角色同等重要的管理对象来对待。升级后的废弃Catalog就像家里积攒多年的杂物间——你平时看不见问题一旦搬家升级所有东西都得重新过一遍。与其搬家时手忙脚乱不如平时就保持每周看一眼、每季度清一次的习惯到了真正升级的时候你会发现所谓接管工作早就在日常治理中完成了大半。