企业官网建设流程全解析

做 SAP Fiori 的应该都见过这种场景：群里丢过来一条消息，说用户登进 Fiori Launchpad 之后台面一片空白，或者磁贴都看得见，但点任何 App 都报"未授权"。排查到最后，绝大多数问题出在同一条链路上：Catalog 和 Group 只是前端素材，真正决定用户能看什么、能用什么的是 PFCG 里那个角色。Catalog 没挂进 Role 的菜单，授权对象没在 Role 里重建，用户分配了角色却没生成 Profile，这几件事任何一个环节断了，前端表现都一样：要么空白，要么报错。

这篇文章就顺着"从 Catalog 到 Role"这条主线，把 Fiori 角色创建、菜单转移和授权重建三个阶段完整拆开讲一遍。每一步讲清楚为什么这么做、怎么做、以及不这么做会踩什么坑。适合正在做 Fiori 上线、接手 Fiori 运维的 Basis 和安全顾问，也适合每个被"有角色却还是没权限"纠缠的同事。

1. 先把概念捋直：Catalog、Group 和 Role 到底各管哪一段

在进 PFCG 之前，我强烈建议先把三个词的关系刻进脑子里，因为我在项目里见过太多排障方向错误，根源就是把概念混为一谈。

Catalog 是 App 的集合，可以理解成一本菜单，它定义的是"系统里有哪些菜"。Catalog 本质上是给 Fiori Launchpad 前端用的配置对象，一条 Catalog 记录里会包含若干 Target Mapping，每个 Target Mapping 指向一个真实的应用。Catalog 不关心谁能用，它只负责声明"有哪些东西存在"。

Group 是 Catalog 的展示层，定义的是"用户在台面上先看到哪几道菜"。Launchpad 的首页磁贴是按 Group 分组的，同一个 App 可以出现在多个 Group 里，同一个 Group 也可以跨多个 Catalog 拼接 App 磁贴。这个灵活性是业务用户最喜欢的，但也带来一个副作用：Group 和 Catalog 之间的引用关系如果没人维护，台面上就会出现"幽灵磁贴"。

Role 才是权限的最终载体。PFCG 里创建的角色把 Catalog、Group、授权对象、用户四个要素粘在一起：菜单页决定前端可见性，授权页决定后端可执行性，用户页决定谁拿到这套组合。在 S/4HANA 里，对应的标准叫法是 Business Catalog、Business Group、Business Role，底层机制类似，只是换成了业务口径的术语。

这里有个最容易踩的坑：很多人习惯把 Catalog 直接说成"权限"，但 Catalog 本身不是权限。用户也不能被直接分配 Catalog，必须通过 Role 把 Catalog 挂上去、生成授权 Profile 后才真实生效。

打个比方：Catalog 是整个写字楼的楼层分布图，Group 是各楼层门口的前台指引牌，Role 则是门禁卡加工位授权。光有楼层分布图，你连一楼大厅都进不去；只有门禁卡但指引牌没更新，你进去了也找不到该去的房间。

这个类比能解释很多现场问题：用户明明有角色，Launchpad 却空白，大概率是角色菜单里没挂 Group/Catalog；磁贴显示正常，点进去却报权限错误，那是后端授权里少了对应事务或服务权限；换了新 Catalog 后旧 App 还能看到，那多半是 Group 里残留了旧 Catalog 的引用。理解了这三个对象的分工，后面所有操作才有章法。

2. 角色创建之前：先花半小时把现场摸清楚

PFCG 里点几下就能建出一个角色，但我见过太多同事"建角色五分钟、排障五小时"，原因就是跳过了前置检查。建角色前至少确认三件事：目录基础、服务状态、授权对象现状。

2.1 目录与群组现状盘点

先打开 Launchpad Designer 这类 Fiori 内容维护入口，把现有 Catalog 清单导出来，逐条看这些 Catalog 是标准产品自带的还是自建的，里面挂了哪些 Target Mapping。Group 也要一并看，尤其注意 Group 和 Catalog 的引用关系——Group 里的 App 必须在某个 Catalog 里能找到，角色挂载时才能正确渲染。

这一步看上去不起眼，但它是后面菜单转移的关键输入。你要知道哪些 Catalog 已经废弃、哪些 Group 是冗余的、哪些 App 在多个 Catalog 里重复出现。某客户项目上我就遇到过，前期没做盘点，转移 Catalog 时把一个还活着的 App 从新角色里漏掉了，用户第二天过来说"报销入口没了"。这种低级事故，追根到底就是盘点不到位。

2.2 OData 服务和 SICF 节点状态检查

Catalog 和 Group 只解决"长什么样"，App 真正跑起来靠的是 OData 服务和后端事务。所以建角色之前，要确认该 App 对应的 OData 服务已经在服务维护入口中激活，同时检查 SICF 服务树里相关 ICF 节点是否可用。Fiori Launchpad 自身、各标准 App 的 ICF 服务节点，全部要在目标环境处于激活状态。

这个检查放到前面有个实打实的好处：如果服务没激活，后面不管怎么调角色授权，用户点 App 永远报 HTTP 状态码错误，你会误判成权限问题，白折腾一两天。我自己的经验是，凡是不是因为权限报错的问题，最后查出来有一大半是服务没激活或者 ICF 节点不可用。

2.3 授权对象现状与 SU24 建议值

建角色前，可以在 SU24 里查一下这套 Fiori 应用对应的事务代码和授权对象建议值，确认系统里有没有客户增强过的授权检查逻辑。Fiori 普通用户角色不是"给了事务码就万事大吉"，尤其涉及 OData 类应用时，后台往往还需要服务授权、RFC 授权，甚至 CDS 分析权限。SU24 里的建议值只是一个起点，后面第四节展开说。

3. PFCG 角色创建与菜单挂载：手把手实操

前置检查做完，进正题。这一节把 PFCG 里从前到后的动作拆开，每一步该点什么、该注意什么，照着做就行。

3.1 创建角色主记录与命名规范

事务码 PFCG，选择创建"单一角色"，输入名称后回车。角色名看起来只是字符串，但强烈建议统一命名规范，例如"Z_业务域_场景_访问级别"这种结构，后续用 SUIM 反查、批量授权、传输管理时能省下大量时间。

创建时注意别用"从默认角色复制"这个功能无脑复制——复制会把旧菜单的 Catalog/Group、旧授权对象一块带过来。如果确实要复制，复制后必须把菜单页的 Catalog/Group 清理干净，授权页重新生成，否则新角色带着一堆历史残留上线，出了事都不知道是哪一任留下的锅。角色主记录保存后，系统会自动弹出一个传输请求，这个请求要留着，后面授权 Profile 生成后一起放进去传输。

3.2 菜单转移核心动作：把 Catalog 和 Group 挂进角色菜单

这是"从 Catalog 到 Role"最核心的一步，也是很多人第一次找不到按钮的地方。在 PFCG 里进入角色的"菜单"页签，在菜单相关工具栏里找"添加 Fiori 目录和组"这类入口（不同版本按钮位置和叫法略有差异，但都在菜单维护区域），点开后会出现一个 Catalog/Group 浏览器，勾选目标 Catalog 和 Group，确认后这些条目就挂到了角色的菜单树里。

这一步有四个关键注意点：

• Catalog 和 Group 要一起挂。只挂 Group 不挂对应 Catalog，Launchpad 上可能出现磁贴渲染不完整；只挂 Catalog 不挂 Group，用户登录后连默认台面布局都没有，效果等同空白页。
• 挂完检查菜单树里的目标映射是否完整。自开发 App 的目标映射，类型要选准确，是 Transaction 还是 OData UI5 App，URL 或事务码要对得上。很多 App 打不开，根因是目标映射配错了，授权反而一身清白。
• 同一个角色里别塞太多 Catalog。角色是岗位策略，不是 App 大杂烩，一个角色能瘦身就瘦身，Catalog 塞得越多，后面授权越难收敛。
• 保存角色时留意传输请求。菜单挂载的数据会跟着角色一起进传输请求，别把这个请求随便删除，否则生产环境角色到了，Catalog/Group 配置却没到。

3.3 授权标签页：生成建议值与手动微调的边界

菜单挂好了，切到"授权"页签，进入"更改授权数据"。这里首选的动作为点"生成"，让系统根据 SU24 建议值把该角色涉及事务、服务的授权对象带出来。然后你要在这个列表里做三件事：

第一，检查生成的授权对象清单，确认没有多余的高权限对象，比如别给业务用户带出管理类事务码或通用授权对象；第二，对字段值明显的对象（比如 S_TCODE）按业务岗位的实际需要手工筛选和增减，原则是最小授权；第三，保存时系统会给角色生成一个新的授权 Profile，这个 Profile 才是真正在用户主数据里生效的东西。

很多新手容易犯的错：生成了建议值就原样保存，结果用户权限大得像管理员，或者反过来漏掉关键对象。建议值只是 SU24 根据标准事务推导出的最小集，不包含项目自开发事务和特殊混合场景，所以"生成"只是一个起点，后面要配合 SU53 和 ST01 的报错反馈持续微调，直到权限刚好够用。

3.4 用户分配、角色激活与用户主数据比较

角色授权的最后一公里是用户。在 PFCG"用户"页签里批量添加用户，或者回 SU01 给用户分配角色都行。保存后别急着通知用户登录，先把角色激活，确认授权 Profile 生成完毕。SAP 在角色保存时会触发 Profile 生成，但如果你改了授权对象后没有保存，或者没有重新生成 Profile，旧的 Profile 还会留在用户主数据里，造成"改了和没改一样"的诡异现象。

另外必须提一下"用户主数据比较"。SU01 里有用户与角色授权的比较逻辑，生产环境因为密码策略、锁定等原因，用户主数据里的角色和 PFCG 角色常出现不一致。改完角色以后，做一次比较并同步，再让用户去试，能消掉一批"明明授权了却报权限错误"的假故障。这一步是我每次上线前必做的动作。

4. 授权重建：从零搭权限的关键细节

第三节点到授权生成，但"重建授权"这个动作值得单独拆一章，因为 Fiori 环境里，授权出问题的概率远高于目录配置。

4.1 看清两层授权模型：前端可见性 vs 后端可执行性

Fiori 的授权实际上是两层，排查时必须先把层次分清：

前端可见性由角色菜单页挂载的 Catalog/Group 决定。用户有没有磁贴、看得到哪些 App，取决于角色菜单里挂没挂对目录，前端并不做传统事务码级的访问检查。

后端可执行性由授权页的授权对象决定。用户点下磁贴，App 在前端调用后台的 OData 服务或直接打开事务代码，这时候才开始走传统 ABAP 授权检查，S_TCODE、S_SERVICE、S_RFC、S_ICF 等对象挨个被查。

很多排障混乱就是从这两层混在一起开始的。磁贴没了你去加 S_TCODE，完全南辕北辙；App 报权限错误你去挂 Catalog，用户依然被挡在门外。我经常跟团队说一句话：先看点不点得进去，再谈数据权限，最后才动授权对象。顺序反了，你会把所有代码都碰一遍。

4.2 高频授权对象与建议值对照

这里列几个 Fiori 环境里最常见的授权对象，具体清单以你们系统 SU24 实际生成为准，但排查时可以按这个思路对号入座。

在 S/4HANA 里做嵌入式分析类 Fiori 应用时，还会额外检查 CDS 视图授权，这通常通过分析权限或 DCL 相关配置来体现，光靠 SU24 建议值往往不够，需要专门设计。这个点很容易遗漏，因为你在 PFCG 里看不到明显的 CRUD 授权对象，但用户点了报表就是没数据。

授权重建的原则是"从零开始、按需叠加"。千万别拿一个看起来和现在需求差不多的旧角色当模板，旧角色往往带着三年前的授权残留，直接复制再改，等于把历史包袱全部继承过来。我见过一个客户，财务岗位角色里有几十个早已废弃的事务码，就是因为整套 Fiori 角色都是当年从一个模板复制出来的。

4.3 活动组与字段值：参数化授权的尺度

重建授权时，授权对象的字段值不要无脑填"*"。对业务用户来说，S_TCODE 给具体事务码集合、数据权限对象给具体的组织范围，才是可控的。操作级别可以用活动组来限制，比如 01 创建、02 修改、03 显示；数据相关授权对象则要针对公司代码、工厂、销售组织等字段做参数化设计。

外观上看，这样做更费时间，但后期做权限审计、合规检查、岗位离职交接时，你一定会感谢当初没有图省事。权限只给到"够用"，永远是 Fiori 角色设计的第一原则。

4.4 从角色到传输：授权重建后的落地路径

角色和授权归根到底都是配置对象，最后要通过传输请求带到测试和生产环境。这里特别提醒：Fiori 角色涉及的内容比传统角色多，除了 PFCG 角色本身，还有 Catalog 配置、Group 配置、OData 服务激活配置、ICF 服务配置。这些对象存在不同的表和应用集合里，单纯传输 PFCG 角色，目标系统里可能根本没有对应的 Catalog/Group 对象，结果角色到了生产，菜单树是断的。

所以传输前，把相关配置对象全部收集到同一个请求里，或者先传 Catalog/Group、再传角色，顺序别反。我踩过的坑是：只传了角色，没传自开发的 Catalog 配置，生产环境用户登录后空白一片，后端一查目录对象在目标系统不存在。那次之后，我每批 Fiori 角色传输前都会列一个配置物件清单，逐项勾掉才放行。

5. 菜单转移的两种典型场景：新旧体系切换实操

标题里的"菜单转移"，在真实项目里通常对应两种需求：一种是旧 Catalog 整体淘汰，把角色菜单迁到新 Catalog；另一种是角色持续演进，在既有角色里增删 App 并更新 Group。两种场景动作不一样，拆开说。

5.1 场景一：旧目录整体淘汰，角色菜单迁移到新目录

这种情况常见于从老版本 Fiori 迁移到 S/4HANA 的 IAM 模型，或者某个业务从标准 App 整体切换为自开发 App。操作路径大体如下：

先用 SUIM 或通过 PFCG 的角色清单，把当前引用了旧 Catalog 的角色全部列出来，评估哪些要迁、哪些直接下线；然后逐个打开目标角色，在菜单页把旧 Catalog 的节点删除，再挂入新 Catalog/Group；清完旧目录后进入授权页，把旧事务码或旧服务相关授权删掉，重新生成建议值并补上新 App 需要的授权；保存角色、重新生成 Profile，打包传输到下个环境。

这个过程看似平淡，最容易出问题的是"漏"：有些 Group 仍然引用旧 Catalog 里的 App，角色菜单里看着旧 Catalog 删了，但 Group 没同步清理，用户台面上依然残留旧磁贴，点一下报错。所以做整体迁移时，Catalog 和 Group 必须一起梳理，而不是只动角色。

实操中我还习惯在迁移后做一次全量比对：用 SUIM 查新角色包含的事务码和授权对象，和旧角色逐一核对，确保没有把仍在使用的业务功能遗漏。人脑在权限矩阵面前极其不可靠，宁可多花半小时做比对，也不要上线后被用户反过来教育。

5.2 场景二：在已有角色中增加或下线 App，并同步 Group 布局

日常运维里碰到更多的是这种需求：新 App 上线，要在某个岗位角色里放出来。完整动作链是：

在 Catalog 里新增 Target Mapping，或者直接新建 Catalog；激活该 App 依赖的 OData 服务；在 Group 里添加该 App 的磁贴，也可以新建 Group；打开目标角色，菜单页挂上新 Catalog/Group；授权页重新生成建议值，补充新增事务码或服务授权；保存、生成 Profile、传输、测试。

下线一个 App 时，很多人的第一反应是直接从 Group 里删磁贴。其实还要记得把 Catalog 里的映射停掉、把角色里对应的授权对象删掉。否则 App 虽然在台面上不显示了，后台授权还在，安全审计时这就是一个"幽灵权限"。我在一次合规检查中就翻出过这种权限，看着没什么危害，但审计意见里写出来很难看。

这里给一张增删 App 动作清单，方便你直接抄作业：

6. 高频故障与排查实战

把我在项目里碰到过的典型问题整理一遍，每个问题给出现象、常见原因和排查动作，可以直接当速查表用。

6.1 用户登录后空白台面，一个磁贴都没有

先别怀疑人生，按顺序查：用户主数据里有没有分配角色，SU01 查看角色列表，有时候测试用户根本没挂角色；角色的菜单页是否真的挂了 Group/Catalog，打开 PFCG 看菜单页签，没挂就补上再激活；角色是否生成了授权 Profile，看授权页的 Profile 名称是否为空；用户端清理浏览器缓存和 Fiori 客户端缓存，强制刷新；最后检查 FLP 相关的 SICF/ICF 服务状态。

按这个顺序，前三条能解决 80% 的空白问题，剩下 20% 大概率是缓存和服务状态。遇到空白台面，别急着改角色，先花三分钟做上面这套检查，往往比盲目点配置管用得多。

6.2 磁贴能看到，点击 App 却报错或者打不开

这类故障的定位顺序是"服务 -> 目标映射 -> 授权"：先看 OData 服务是否激活，用服务维护事务直接查；再看 SICF 节点是否可用，尤其有前置网关架构时，前端和后端节点都要查；然后看角色菜单里的 Target Mapping，很多自开发 App 的映射 URL 写错或类型选错，授权再大也打不开；最后才查授权，用 SU53 看用户最近一次访问时的授权检查结果。

这里有一条现场经验：凡是"部分用户能开、部分用户不能开"，基本可以锁定是授权或角色分配问题；凡是"所有用户都不能开"，优先查服务、映射和配置，别在权限上耗时间。这个判断能帮你少走很多弯路。

6.3 SU53 与 ST01：授权报错怎么读、怎么追

Fiori 页面上的授权报错经常是一段晦涩的英文加一长串技术参数，很多人看到就截图发群。读取方法其实很简单：把报错信息里提到的授权对象和字段值记下来，然后进 SU53 查该用户最近一次失败的授权检查，系统会列出具体的对象、字段和值。如果 SU53 查不到，可以在用户端开启 ST01 授权跟踪，让用户复现一次操作，再分析跟踪文件，就能精确找到被哪个检查点拦住。

这两个事务码是授权重建阶段的左右手。省着点说，Fiori 排障 70% 的情况靠 SU53 加服务状态检查就能定位，剩下 30% 靠 ST01 和耐心。

6.4 改完角色不生效：缓存与比较的隐藏坑

角色明明改好了、Profile 也重新生成了，用户刷新还是老样子。这时候多半是三个原因之一：

浏览器和 Launchpad 前端缓存没清。Fiori 的前端缓存机制在不同版本里表现差异很大，清一次客户端缓存基本能解决大部分"没变化"问题；用户主数据没做比较和同步。前面提过 SU01 和 PFCG 的角色比较逻辑，改了角色后要把用户主数据里的授权 Profile 刷新到最新；传输没到位。如果开发和测试环境分别改过配置，注意别把请求弄丢，查一下目标系统的传输日志。

角色配置改完"看起来没生效"的故障，本质都是某个缓存或同步环节脱节。按服务端配置、用户主数据、前端缓存、传输日志这个顺序排查，一般十分钟内能定位。记住一个原则：改完角色不是终点，Profile 生成了、用户比较过了、缓存清掉了，用户看到的才是新世界。

7. 最后说几句经验之谈

正文该干的活基本干完了，最后补几个文档里不会写、但能帮你少走弯路的习惯。

一是建角色之前先把命名规范和 Catalog/Group 的归属关系定下来。某客户项目后期角色从 20 个膨胀到 90 个，一半原因就是前期没有规范，后面想收都收不住。

二是每次改完授权，养成"保存 -> 生成 Profile -> SU53 复测 -> SU01 用户比较"的四步习惯，不要跳步。这套流程看似机械，但省下的排障时间远超操作时间。

三是 Catalog 迁移时，宁可多花半小时用 SUIM 把引用关系全部导出来核对，也不要凭记忆判断哪些角色受影响。我在这上面栽过跟头，所以后来每次迁移都按清单走。

四是把 SU53、ST01 和服务维护入口练成本能反应。Fiori 排障大部分情况靠这三样就能定位，剩下的靠经验和耐心。

最后分享一个我自己的自检习惯：每批 Fiori 角色交付前，我都会问自己三个问题——角色菜单里挂的 Catalog/Group 是不是当前有效版本？授权页删没删掉用不到的旧事务码？用户主数据比较做没做？三个都确认了才放行上线。这个习惯算不上高明，但确实把不少线上事故拦在了前面。Catalog 只是图纸，Role 才是拿在手里的钥匙，图纸画得再漂亮，钥匙配错了，门照样打不开。