SAP Fiori升级后Business Catalog废弃的排查接管与治理实战

上个月在客户现场做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，方案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就像家里积攒多年的杂物间——你平时看不见问题，一旦搬家（升级），所有东西都得重新过一遍。与其搬家时手忙脚乱，不如平时就保持"每周看一眼、每季度清一次"的习惯，到了真正升级的时候，你会发现所谓接管工作早就在日常治理中完成了大半。