随缘惜情前两周帮一个客户做SAP Fiori Launchpad治理复盘，遇到一个特别典型的case：某条业务线反馈，某个Tile在张三的界面上能看到，在李四的界面上死活看不到。两个人都挂在同一个PFCG角色下，Catalog也都配了，Group也分过去了。查了一下午，最后发现原因是：我们一直以为“给角色挂了Catalog”就是“配好了桌面入口”，但实际上Catalog管的是“应用池”，用户桌面上放哪些组、哪些磁贴，是由Group控制的。这两个层级被混在一起讨论，是SAP Fiori Catalog Administration里最常见的失控起点。
这篇文章我想把Catalog、Tile、Scope这三层拆开讲一遍。你会发现，Fiori的管理难点从来不在单个点的配置上，而在怎么把这三个东西组织成一条能解释、能审计、能随组织变化而伸缩的治理链路。适合正在做Fiori rollout、FLP权限整改、或者被各种Tile忽隐忽现的问题折磨得够呛的Basis、Fiori管理员和后端开发一起看。
1. 治理失控的根源：Catalog、Tile、Scope经常被当成同一个东西在配
1.1 一个把“Group当成Catalog用”的现场
我见过不少项目里，管理员在Launchpad Designer里新建一个Group，把一堆Tile拖进去，然后告诉用户“桌面已经配好了”。听起来没什么问题，但接下来用户换一台电脑、或者新入职一个人，你需要在PFCG里重新配一遍。这个时候你会发现，Launchpad Designer里的Group是不跟权限走的，它只负责“当前这套前端系统上，页面长什么样”。
Catalog才是跟角色绑定的东西。如果你只是把Tile放在Group里而没有把对应的Catalog放进角色，那么用户在这个FLP站点上，根本不会在“应用查找器”里看到任何东西。换句话说，桌面上被拖到Group里的Tile只是“快捷方式的陈列”；Catalog才决定了这个用户是否“拥有”某个应用入口的浏览资格。
现场里最经典的报错就是：用户把Group当成Catalog去理解，为了一个新App加了一个Group、拖了Tile，然后在PFCG里找不到“这个Group怎么挂”。因为Group在前端是做个性化布局用的，不进入权限角色关系。
1.2 三层概念各管哪一段
把Fiori内容从权限和导航角度拆开，其实是三条责任链，链上每一环解决的问题都不同。
- Catalog：面向应用入口的“分类池”，它定义了“角色里包含了一批什么应用”。Catalog本身不关心页面排版，也不关心后端授权，它只是把一堆Tile和对应的Target打包成一个可分配的单元。
- Tile：用户能感知到的那张卡片，它作为UI入口展示名称、图标、计数。但Tile本身不负责“解引用”，它要依靠Target Mapping告诉你点击之后去哪个应用、用哪个语义对象和动作去发起导航。
- Scope：这个最容易被误读。它在很多项目里有两种含义，一种是实施范围（比如“HCM这个阶段上哪些流程、开哪些Fiori App”），另一种是运行时权限范围（用户到底能看多少、能进多少、能在后端做多少）。不管哪一种，它都要以Catalog和Tile的分配作为落地载体。
你可以把所有用户都放在同一个FLP前端上，这没问题。但不能让所有用户都挂同一个超集Catalog。Catalog的粒度如果太大，Scope就没有办法剪裁；Scope如果没有跟业务流程对应，Catalog最后就会膨胀成垃圾场。
1.3 治理视角下的三层模型
我在实际做整改时会用一个模型：可见性、可访问性、可执行性。
- 可见性由Catalog和Group共同决定。Catalog管“你能从应用查找器里找到什么”，Group管“这些Tile是否默认出现在你首页的某个分区里”。
- 可访问性由Target Mapping和前端导航的配置决定。Catalog里放了Tile，Tile也挂了Target，但Target对应的SICF服务、OData服务没激活或没暴露，Click之后就是白屏。
- 可执行性由后端的PFCG授权对象和网关层权限决定。Catalog让你看到入口，不代表你点了就能跑；后端没给到S_TCODE、对象级权限，或者OData服务的权限没配好，你在界面上会看到403或系统错误。
这三层你分别在三个地方排查，又必须在同一个角色矩阵里对齐。可以把一个用户能用的应用看成：Catalog分配提供了“候选菜单”，Target Mapping决定了导航到哪个后端资源，后端授权决定资源内能执行到哪个动作。这三者只要有一环错位，表现出来就是“菜单里看得到，点进去没权限”——这类问题占了Fiori运维工单的一大半。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Catalog配置实战：别把“目录”和“桌面分组”混为一谈
2.1 Catalog常用的维护入口
SAP Fiori Launchpad的内容维护入口现在比较收敛了。常规是用Manage Launchpad Content（Fiori App ID F2302，事务代码 /UI2/FLC）来维护Tile、Catalog、Target Mapping。Launchpad Designer（/UI2/FLP_CONF）更多是维护桌面分组和最终展示层。
具体从哪进取决于你的版本和项目约定。我的习惯是：凡是要进入角色管理和分配的Catalog，统一在Fiori Content Manager里维护；凡是纯布局调整，比如默认分组顺序，再进Launchpad Designer。这个习惯能让“内容”和“布局”变更分开走，传输和审批的边界也干净。
虽然直接读后台表也能看出部分内容，但读出来的XML或JSON结构非常难读，而且容易误改。尽量不要直接操作数据库表来维护Fiori内容，把这活儿留给标准维护工具，不然一个Transport Request里的内容完整性和依赖关系很容易被拆坏。
2.2 Catalog的命名规范和结构设计建议
很多项目最初在Catalog设计上是没有想法的，SAP标准给了一堆目录，自己实施时又创建一堆Z开头的目录。没过一年，每一个Fiori用户角色里挂着六七个Catalog，每个Catalog里几十个Tile，权限管理员自己都说不清用户到底是哪些流程的使用者。
我建议Catalog按下述两条原则来设计：
- 按业务域拆，不按系统拆。比如Z_HCM_PAYROLL、Z_HCM_BENEFITS，比Z_ERP_01、Z_ERP_02这种有生命力的多。按系统拆的问题在于，系统合并或Farm切换的时候，Catalog的维护成本直接翻倍。
- 按使用场景剪裁粒度。Catalog服务于权限分配，不是给Tile做文件夹归档。一个Catalog如果覆盖“人事全员”又覆盖“薪酬专员”，那任何角色矩阵都必须额外做一层手工干预，才能避免薪酬类App开放给全员。反之也尽量不要为了某个单一App建一个目录，因为那样会导致角色里的Catalog列表爆炸，每次升级SAP标准Fiori内容时，校准成本会很高。
一个折中的粒度是：业务子域包含3到15个Tile左右，但这个数字不是硬性的。重点是Catalog拆完以后，能不通过二次裁剪就匹配上业务角色，这才是合理的。
还有个小技巧，Catalog ID和Tile ID也统一加后缀，例如_CAT、_TIL、_GRP。当你在角色里或传输请求里看到Z_HCM_PAYROLL_CAT和Z_HCM_PAYROLL_TIL时，一秒就能判断它是Catalog还是Tile，对后续写脚本审计非常关键。
2.3 Catalog与标准SAP目录的关系处理
SAP在Fiori Apps Reference Library里会给每款标准App标注对应的Catalog ID、Tile ID和Target信息。很多管理员在配置阶段喜欢直接把SAP标准Catalog整个挂到自定义角色上，省事是省事，但Scope会失控。因为一个标准Catalog里通常包含同一业务流程的一组App，不会精准到某个角色只需要其中一个。
标准Catalog的处理，我建议按不同场景区别对待：
- 如果SAP标准Catalog的内容与你的业务角色完全一致，比如你就是要把“我的收件箱”这类通用App给全员开，那直接挂标准Catalog是合理的。
- 如果只是需要标准Catalog里的某几个App，不要直接把Catalog挂进去，而是另建Z开头的业务目录，从标准目录里把需要的Tile复制过来或引用过来，再在角色里挂Z目录。
- 如果项目刚起步、还处在Demo和探索阶段，可以先挂标准Catalog跑通浏览链路，但一定要在进入UAT前完成剪裁和替换，否则后面的Scope审计会非常痛苦。
标准Catalog本身还会随SAP版本和Support Package升级发生变化，新App会往里面加。如果无脑挂标准Catalog，等于每次升级都自动给用户发一批新的可见入口。从治理角度看，这要比自己维护Z目录有更大的不确定性。
2.4 Catalog分配常见翻车点
我整理了几个实际项目里反复出现的情况，你可以拿去做排查对照：
- 用户的角色里加了Catalog，但还是看不见：优先检查Fiori前端站点的角色分配是否已保存，以及用户是否重新登录。FLP有缓存机制，用户不重新登录或者不清理Launchpad缓存，Catalog的新增不会立刻出现在桌面或应用查找器里。
- 把Tile直接加到Group却没有加入Catalog：用户桌面上可能暂时能看到，但换一台设备或通过App Finder就找不到了。原因回到前面说的：Group是布局，Catalog才是权限池。
- Catalog分配过多但Group没放：用户其实能在应用查找器里看到，但首页没分组显示，就以为“没给我开”。这种建议一开始就给最终用户讲清楚“应用查找器”的价值，否则你会收到大量误报工单。
- 权限角色复制后Catalog内容串了：复制PFCG角色时，Fiori Catalog往往也会被一并复制。如果只改了事务权限而没剪裁Catalog，就会出现新角色继承了旧角色一大串无用Tile的情况。
3. Tile的生命周期：从磁贴到Target再到权限边界
3.1 Tile只是一个入口卡片
很多刚接触Fiori的人以为Tile就是“一个应用”，其实它是一种投射。同一款App可以被多个Tile引用，同一个Tile也可以被多个Catalog引用，Tile里的参数还能决定打开应用时默认携带的筛选条件或上下文。
这就带来一个治理要求：创建Tile之前，必须先想清楚这个入口的“消费对象”是谁。比如同一套采购审批App，给采购专员和给部门经理做的Tile，显示的标题可以不同，默认的审批列表范围也可以不同。这不能靠复制一大堆Tile来实现，而是要通过Target上的参数和Tile参数配合。
如果只是给同一个人群做一个入口，没有任何参数差异，那就不该建多个Tile，否则后面Catalog审计的时候，你会在不同Catalog里看到一堆重复的“审批入口”，很难判断哪个才是用户真正该用的。我建议在新建每个Tile时都记录一条元数据：对应哪个业务场景、哪个语义对象/动作、是否带参数、作用对象是哪些角色。没有这张对应表，Tile半年后就是一笔糊涂账。
3.2 Target Mapping是连接Tile和后端应用的那根管子
Tile上通常会配一个Target，其实你可以把Target理解成“导航的目标定义”，它由语义对象和动作组成。当用户在Launchpad上点击Tile时，前端会根据Target信息找到对应的应用类型和导航方式，再决定是打开一个SAPUI5应用、一个旧Web Dynpro、一个SAP GUI事务还是一个外部URL。
Catalog、Tile、Target这三者的生命周期是不一致的。Catalog是权限分配的单位，Tile是视觉入口，Target是导航解析的单位。有时候你只改了Tile的显示名称，Catalog不用动；有时候你换了一个后端应用的OData服务地址，Target Mapping必须跟着动，但Catalog和Tile可以不动。理解这个差异，才能避免在一次小变更里牵动一堆无关对象。
在治理上，我最常强调的是Target Mapping的变更不能走“临时改生产”这一步。因为它一旦改错，影响面是所有挂了相应Tile的用户，而且错误不会只出现在某一个人身上。Target Mapping应该有独立的变更记录，写清楚改动时间、原因、前后端服务版本、影响范围。
3.3 Tile点开后白屏或报403，先别怀疑Catalog
在实际运维里，更多的问题不是Tile找不到，而是Tile找得到、点进去却白屏或返回403。很多人习惯把它理解为Catalog配错了，其实问题往往出在后半段。
点开一个Fiori应用时，整套请求链路大致是这样：Launchpad根据Target Mapping找到应用入口，前端请求UI资源，然后向后端OData服务发数据请求。如果后端OData服务没激活、SICF节点被禁用、或请求头里的CSRF Token校验没过，你在浏览器里就会看到403或类似错误。
我见过好几次现场，开发一上来就怀疑Catalog配错了，反复改Tile配置，实际呢？到后端用Gateway Client直接调一下OData服务，发现是OData服务的权限没放给通信用户。用F12看Network，前端其实已经拿到了OData的元数据，只是具体数据请求被后端拒了。所以遇到403，正确姿势是先分清楚：是Launchpad导航阶段报403，还是数据请求阶段报403。前者大概率是Target Mapping、SICF服务或认证配置的问题，后者大概率是后端权限和Gateway用户配置的问题。
3.4 一个和CSRF Token相关的403排查路径
这里单独说一下CSRF Token。SAP Fiori对OData的写操作遵循比较严格的CSRF防护，前端一般会先发一个只读请求去获取X-CSRF-Token，拿到之后再在后续的POST/PUT/DELETE请求头里带回去。如果第一步获取Token就失败，或者Token拿回来但被中间链路剥掉了，前端就会报很典型的AJAX调用403。
我的排查路径一般是：
- 用F12打开网络面板，找一条返回403的请求，看这条请求是获取X-CSRF-Token的那个OPTIONS、GET或HEAD，还是后续修改类请求。
- 如果是获取Token阶段就403，基本是登录会话或网关服务本身的问题。先看用户的登录态是否正常，再看反向代理、负载均衡或防火墙有没有把这个响应头或随后的自定义请求头剥掉。
- 如果Token请求成功，是后续写操作403，那就要把请求里的Token值和后端Session里记录的值做比对。很多时候是因为没有开启会话粘滞，或前端走了不同网关节点导致Token不一致。
- 如果是后台开发自己写的OData服务，还要检查服务实现里有没有做重复的CSRF校验。某些扩展代码会自己二次校验，校验逻辑如果读不到请求头，就会把正常请求误伤。
Fiori里排查前后端交互问题，核心要领就是看整条HTTP链路上的请求头和响应头，不要只看响应状态码。Catalog和Tile即使配得完美，后端出问题依然会表现为应用不可用，这一点一定要在治理SOP里写清楚。
4. Scope怎么定：从“能看到的范围”细化到“能执行的范围”
4.1 Scope在Fiori项目里是有两张脸的
“Scope”这个词在Fiori语境里很分裂。做项目计划的人提到Scope，通常指的是Implementation Scope，也就是这期上哪些流程、哪些工厂范围、哪些用户组。做权限和治理的人提到Scope，指的是一个用户能够访问到的Fiori App集合，甚至再细一点，是在某个App里能看到哪些业务数据。
如果这两拨人不在同一个频道上对齐，很容易出现业务说“这个Scope我们SOW里写了，怎么还没开”，而权限管理员说“Catalog我加了，为什么用户进来还是报没有权限”。两边都在说Scope，但一个说的是功能范围，一个说的是技术配置范围。
治理时要做的第一件事，就是把Scope拆成两个显式的维度：业务流程范围和技术授权范围。业务流程范围说明“为什么给这个角色开应用”，技术授权范围说明“在FLP里能看到什么、点进去能做什么”。两个维度放到一张矩阵里对齐，Scope才是可控的。
4.2 你看到的Catalog范围不一定等于你能执行的范围
我见过一个挺极端的处理：因为用户抱怨打开某个Fiori App后403，就把前端角色里的Catalog扩大，把包含相同后端服务的Catalog都挂上。结果403照样在，因为403是后端OData权限报出来的，Catalog根本管不到那一段。反过来，如果把某个企业级服务从用户的可见范围里隐藏掉，但后端权限没撤，用户依然能通过旧URL、语义对象导航或外部继承入口访问到该应用，只是桌面上看不到。
所以真正的权限Scope，不能只观察“前端能看到多少Tile”，而是要覆盖三层：前端可见的Tile范围、通过Target解引用后的入口范围、后端权限对象允许执行的功能范围。这三层任何一个不一致，严格来说都算权限漏洞。要么是过度开放，要么是表面关闭实则后门打开。
做一个Fiori角色整改时，我一般会导出每个角色关联的Catalog清单，再从Catalog推导Tile和Target清单，最后去后端核对每个Target对应的服务权限。那张表列出来后，很多“看不到”和“不该通却通了”的问题会自己暴露出来。
4.3 用一张Scope矩阵把角色和Catalog对齐
我的个人习惯是给每个业务角色维护一张Scope矩阵，字段类似这样：
| 业务场景 | 建议角色名 | Catalog ID | 入口Tile | 后端权限要点 | 目标用户群 |
|---|---|---|---|---|---|
| 员工自助-我的资料查询 | Z_ESS_MASTERDATA | Z_ESS_CAT | Z_ESS_MY_DATA_TIL | OData只读权限、无薪资字段 | 全员 |
| 薪酬专员-薪资核算 | Z_HCM_PAYROLL_CLERK | Z_HCM_PAYROLL_CAT | Z_HCM_PAYROLL_PROCESS_TIL | 薪资数据读写权限、敏感字段授权 | 薪酬组 |
| 采购员-请购单审批 | Z_MM_PR_APPROVER | Z_MM_PURCHASE_CAT | Z_MM_PR_LIST_TIL | 审批任务授权、供应商主数据只读 | 采购组 |
这张矩阵有两层价值。第一层是“一份清单讲清楚所有范围”，第二层是“任何变更都能反查到影响面”。
比如业务提出“给临时工也开通请购审批”，你不需要去猜该加哪些Tile，直接查矩阵里采购审批的Catalog ID和权限要点，复制角色、套用同样的内容，再改人员范围即可。矩阵如果不维护，等你离职或者项目交接时，下一任管理员面对几百个PFCG角色，只能靠猜，Catalog里挂的Tile越多，越不敢动。
Scope真正做得好不好，在我看来不取决于你建的Catalog多细致，而取决于你是否能快速回答一个问题：“某个业务角色，一个不多一个不少，到底该拥有哪些Tile入口和后端权限。”只要能回答出这个问题，你的Scope就是收敛的。
5. 一套能落地的治理SOP：从上线启动到日常运营
5.1 启动期：先做需求裁剪，不做Catalog堆叠
Fiori内容治理最忌讳一上来就对着SAP标准内容库把Catalog全铺开。标准的Fiori Catalog数量几十上百，一股脑同步到生产前端再挂到角色上，看起来好像“App都开了”，实际交付质量非常差。
我在项目启动期建议分三步走：
- 从业务用例出发，列出本阶段要开放的流程，一个流程对应一个业务角色初稿。
- 把流程翻译成具体的Fiori App清单，去SAP Fiori Apps Reference Library查每个标准App的Catalog、Tile、Target和依赖服务。
- 对超出标准Cut的App，统一创建Z开头的业务Catalog和Tile，并在这个阶段就完成命名和归属登记。
这个阶段最核心的目标是生成一份基线清单。基线清单一经确认，就进入传输和权限配置。不要一边做需求调研一边往生产里加Catalog，那会让基线完全失效。Catalog的增补应该走变更流程，而不是谁都可以在生产维护一把梭。
5.2 内容同步与传输：Catalog不是在前端直接调出来的
Fiori内容管理有一个容易让人误解的地方：你在开发系统的Fiori Content Manager里建好了Catalog和Tile，不上传、不传输，生产前端是不会知道这些内容的。有些刚上手的管理员会在生产系统里直接敲/UI2/FLC来新建内容，这样做虽然也能暂时跑通，但后续再变更时，生产和其他环境之间的内容会越漂越远。
花点时间把Catalog、Tile、Target Mapping、Group分开纳入传输请求，是值得的。每一类内容变更，写清楚传输请求的描述和关联问题单号。内容物设计不好，后续版本升级时冲突会多到让人崩溃。比如一个Target Mapping被两个不同请求改了，传输先后顺序不同，生产上就会出现“不同时间打开系统表现不一致”的灵异现状。
另外，内容传输完成后，还需要根据项目实际情况清理或重建相关缓存，否则内容在后台已经变了，前端还是拿旧内容。以前遇到过在传输后立即让用户测试，用户反馈跟没改一样，多数情况是前端浏览器缓存或Launchpad内容缓存还残留着旧版本。
5.3 运营期：定期做Catalog健康检查
Catalog从上线那天起就会开始腐化。原因是组织在变，流程在变，SAP标准内容也会随升级变动。运营期我会建议按季度或半年做一个“Catalogs健康检查”，主要看这几项：
- 角色里是否存在已经半年以上没有被任何用户访问的Catalog。这类Catalog通常属于历史项目残留，可以标记为退役候选。
- Catalog里的Tile是否有指向失效Target的。比如某个OData服务已经下架，但Tile还挂在目录里，用户点进去就是错误提示。
- 是否存在面向大批量用户的超集Catalog。说明业务边界不够清晰，或者有人在图省事。
- Catalog的命名是否还符合规范。时间久了，总会出现Z_TEMP、Z_TEST、Z_COPY_OF_OLD这类垃圾目录，这些是治理纪律松动的信号。
如果组织规模大，建议写一点脚本去读角色和Catalog的对应关系，定期拉出“Catalog被引用次数”和“Tile被Catalog引用次数”。这两组数字结合起来，冷门内容会很快浮出水面。治理SOP不是靠人盯，而是靠数据和定期巡检来降低成本。
6. Fiori内容治理中最容易被忽略的几个排障细节
6.1 改完Catalog用户还是没变化，先查的不是权限，是缓存
我一再强调缓存问题，是因为它真的会浪费大量排查时间。Fiori Launchpad前端有Shell缓存、Tile缓存、Target缓存，后端还有Metadata缓存和Gateway缓存。有时后台配置明显是对的，用户那里却一直是旧状态。
我的处理顺序是：
- 先确认配置已经传到目标客户端，且内容激活状态正常。
- 让用户强制刷新Launchpad或重新登录浏览器。
- 如果还不正常，再考虑在后端刷新或重建相关缓存。许多Fiori内容缓存清理有标准事务码或标准操作流程，并不需要重启前端服务器，但不同版本处理方式不同，不要生搬硬套。先搜一条当前版本的官方操作步骤再执行。
这个顺序看起来很简单，但能拦住至少三分之一的无谓工单。不要在用户还没有做基本缓存清理时就往深层权限去挖，那样会越挖越偏。
6.2 用户侧Debug和请求级排查怎么用
前面讲Scope和Catalog都是偏架构层面的，但真正排查的时候还得回到请求级。我给团队定了个规矩：Catalog有问题先别看后端权限，先用浏览器开发工具把“当前登录用户、请求的Launchpad URL、具体报错接口”三者定位清楚。
Fiori调试没有太多黑魔法。在浏览器里打开F12，看Console和Network，基本上能确定问题出在Shell加载、OData请求还是应用JS报错。如果要从浏览器侧开启更完整的调试信息，可以在Fiori应用的URL上按UI5的调试约定追加参数，比如sap-ui-debug=true，然后刷新页面。很多时候日志会自动打印出加载了哪个Catalog、解析了哪个Target，问题比想象中好定位。
如果请求到了后端还是查不出来，就要把视角切到网关侧。用OData服务测试工具直接发请求，对比前端报错时的Authorization和CSRF Token差异。这一招能区分“前端问题”和“后端授权问题”，比两拨人互相甩锅高效得多。
6.3 关于Catalog引用关系和内容追溯的三个建议
最后说三个实操建议，都是我在项目里吃了亏以后沉淀下来的：
- 给你的Fiori角色也建一份“角色说明”备注。每次新建角色时写清楚这个角色对应哪些业务岗位、允许访问哪些Catalog、由谁负责审批。这个备注在一年后的权限审计里价值极高。
- 做Catalog拆分时，一定要同步更新Target Mapping和Tile。很多人只拆了Catalog，忘了把Tile移过来，结果原目录看起来瘦身了，新目录却是空的，用户什么都找不到。
- 生产环境尽量做到“最小变更”。内容想清楚再动，测试环境和生产环境的Catalog内容要定期比对，不要相信“我记得之前传过”。Fiori内容治理到最后拼的就是细心和纪律，谁在流程上省事，后面运维就会加倍还回来。