1. 一次现场问题让我重新审视 Fiori Launchpad 的内容分层去年有个项目上线 Fiori Launchpad 的个性化配置业务方提了一个很典型的需求我们希望关键用户能自己调整首页的磁贴布局但普通用户必须严格按我们统一规划的内容来看不能随便改。听起来像是权限就能解决的问题对吧结果我给了关键用户SAP_CORE_BC_EXT这个 Role 之后问题接踵而至——业务方反馈说关键用户不仅能改自己的视图居然还能把整个 Launchpad 的全局内容给动了。我当时第一反应是是不是角色给错了后来排查下来才发现问题出在Scopes for Adapting Content这个参数上。这个参数在 Fiori Launchpad 配置里叫SAP_UI_FLEX_PARAM对应 FrankFlexibility框架的SAP_UI_FLEX_PARAM参数通过它去控制Adaptation Scope自适应范围。简单说它决定了用户在运行时能对 Launchpad 的哪些层做修改、修改结果落在哪一层。这个错误把启动板从个人定制变成了全局覆盖直接影响了所有用户的生产界面。那之后我专门花了两天时间把 Fiori Launchpad 内容分层的逻辑、Scopes 的三种模式以及它们之间的组合关系彻底梳理了一遍再结合项目里的实际配置经验整理成这篇指南。如果你也在做 Fiori Launchpad 的推广、集成或者运维这篇内容大概率能帮你少踩几个我踩过的坑。2. 爬出层的概念迷宫Fiori Launchpad 内容分层的底层逻辑2.1 四层内容模型搞懂它才能搞懂 ScopesFiori Launchpad 的内容不是一坨平铺在服务器上的它天然是分层的。最常见、也被官方文档反复提及的模型分为四层从底到顶分别是SAP 交付内容Delivery Content这是 SAP 标准系统自带的 Launchpad 内容比如SAP_CORE_BC_EXTRole 底下自带的那些组、磁贴、目标映射。这层内容通常由 SAP 维护实施方不应该直接去改它因为一升级就会被重置。客户/合作伙伴内容Customer Content这是实施项目里真正需要花力气建设的一层。你通过SAP_FIORI_CONTENT_EXTENSION这类扩展 Role 去创建自定义目录Catalog、自定义组Group、目标映射Target Mapping把客户个性化的流程挂到 Launchpad 上。全局内容Global Content这层是运行时层面的它是在上面两层的基础上由管理员或者有权限的关键用户在 Launchpad Designer 里进一步做调整后的结果。它属于一个环境里所有用户都可见的公共层。个人内容Personal Content每个用户自己保存的视图、磁贴布局、筛选偏好只对当前用户生效。这四层里SAP 交付内容和客户内容属于设计期/静态层而全局内容和用户内容属于运行时/动态层。Adaptation Scope 控制的就是当用户在运行时做出修改动作时这个动作是被写进全局层还是个人层或者干脆直接被禁止写入。2.2 为什么要分这么多层因为不同角色的诉求天然不同很多业务用户不理解我就是在手机上调整了一下磁贴顺序为什么说会影响别人因为从 Launchpad 的视角看我调整了磁贴顺序这个动作本身是中性但落点不同影响面就完全不同。普通用户调整应该只影响自己这是Personalization的范畴关键用户调整可能要影响某个角色下的所有人比如销售团队登录后都应该把订单报表放在第一位管理员调整要能影响全公司这就是Global层的范畴。如果不加限制任何用户只要能进入个性化模式就有可能把个人调整提升为全局调整。那为什么默认参数没拦住因为 Scopes 的默认配置ALL就是把所有内容调整能力都放开这适合开发环境和初期测试但绝不适合生产环境。2.3 先理解层再来选 Scope不然一定会配错我见到很多配置人员一上来就翻文档查参数但没见过先把层这个概念理清楚的。Scopes for Adapting Content中Adapt这个词是核心——它瞄准的是运行时对已有内容做的调整而不是设计期从零创建内容。这两个概念容易被混淆后果就是你以为开的是个性化窗口实际开的是全局修改权限。所以在进入下一节的 Scope 模式解读之前请务必牢记这四层模型。所有 Scope 的配置决策本质都是回答同一个问题我的用户需要修改哪一层3. 逐个拆解 Adaptation Scope 的三种模式以及它们各自的杀伤半径3.1 Scope 模式速览在一个参数里藏着三种能力边界SAP_UI_FLEX_PARAM这个扩展参数在 Launcher即 Fiori Client层面生效好的它的取值主要有三种模式值含义能力边界全部放开ALL允许对 Catalog、Group、Target Mapping 等所有内容做创建、修改、删除并影响全局用户个人化USER只允许创建和修改用户个人视图不改变全局内容全部关闭NONE不允许任何内容调整但允许个性化如磁贴排序?等等这里有个容易误读的点NONE不是用户什么都动不了。在 Fiori Launchpad 的逻辑里用户对磁贴的排列、分组、颜色主题这类纯粹的个人化设置走的是另外一套机制通常不会因为 Scopes 为NONE就被完全锁死。真正被锁住的是对 Catalog、Group、Target Mapping 这类业务内容的增删改。如果你需要精细区分能不能调布局和能不能改业务内容建议参考SAP_UI_FLEX_PARAM的官方参数文档并且结合PFCG角色里的SAP_FIORI_UI_ADMIN或SAP_FIORI_CONTENT相关权限去控制管理入口。只看 Adaptation Scope 一个参数无法做到面面俱到。3.2 USER 模式最适合关键用户生产环境落地的一种我最推荐在典型场景中使用的是USER模式。它的官方描述是User-based Adaptation意为用户只能做基于个人内容的适配。在这种状态下用户可以新建个人 Catalog 并绑定应用磁贴吗可以但只对自己可见。用户可以新建个人 Group 吗可以也只对自己可见。用户能修改全局的 Group 吗不能。用户能影响其他同事的界面吗不能。这就是理想的责任田模式每个人在自己的地里随便折腾但碰不到公共区域。在我们的项目里这个模式是给关键用户Key User用的。他们在 USER 模式下可以把常用单据入口加入我的收藏、创建个人的日报处理组生产效率提升明显又不会污染全局内容。3.3 ALL 模式千万别在生产环境随意开放ALL模式对应Global Adaptation。在这种模式下用户所做的调整会直接写进全局层影响所有人。听起来很像超级管理员但它比管理员权限更隐蔽——因为它不要求你进入 Launchpad Designer 或 SAP Gateway 的后台配置界面直接在 Launchpad 的运行时界面里改。想象一下一个关键用户在早上 8 点看到采购审批App 太靠后了直接把它拖到了第一位。这个改动如果是ALL模式就会同步到所有启动了该 Global 层的用户的页面上。如果业务部门今天刚好有审计任务第一眼找不到自己的 App投诉就直接到你这里了。我在项目中只建议开发/测试环境用ALL正式环境要么USER、要么NONE。除非你能保证操作者对你的内容模型有完全的掌控力否则不要选它。3.4 NONE 模式适合有统一视觉规范和流程标准的业务NONE模式限制所有基于内容的 Adaptation这适合很稳定、很标准化的业务环境所有的 Catalog、Group、Target Mapping 都有专门的后台维护团队统一配置前台用户甚至包括关键用户都不需要做任何内容调整。这种模式的缺点也很明显Launchpad 的灵活性被锁死用户想收藏一个应用都得走 IT 流程业务满意度会下降。所以如果你打算用NONE建议同时开启标准的Personalization设置保证用户至少能调整主题、默认布局不然体验太僵硬。4. 三层内容分层策略从 User 到 Key User 再到 Admin各配什么 Scope4.1 明确的分层授权矩阵我建议这样配在实施过程中我最常用的一套策略是把用户群体分成三层分别对应不同的 Adaptation Scope 和 PFCG 角色用户群体对应业务用户PFCG 角色建议Scopes for Adapting ContentEnd User普通用户日常业务操作不需调整内容SAP_FIORI_UI_USER标准用户NONE或默认不设视管理要求Key User关键用户负责本部门流程视图优化SAP_FIORI_UI_USER 自定义关键用户角色USERAdministrator系统管理员负责全局内容维护SAP_FIORI_UI_ADMINALL限定管理员这套方案核心逻辑是内容修改半径随着职责变大而变大。普通用户只能动自己关键用户能优化自己部门相关的视图管理员才能动全局。权限粒度清晰审计也好追溯。4.2 底层实现SAP_UI_FLEX_PARAM 参数与 PFCG 角色绑定在实际系统里Scopes 是通过Launchpad站点参数SAP_UI_FLEX_PARAM传入的。这个参数一般在 LPD_CUSTLaunchpad 自定义里的Role 配置或业务角色配置中设置。以我常用的配置路径为例进入事务码PFCG创建角色或者在已有业务角色上做调整。在菜单页签中找到 Fiori Launchpad 相关的配置项通常是SAP_UI_FLEX_PARAM这项双击进入参数维护。把参数值设为SAP_UI_FLEX_PARAMUSER或NONE、ALL。激活角色重新生成参数文件。这里有两点经验千万别在 SAP_UI_FLEX_PARAMALL 状态下给用户分配任何内容维护相关的 Fiori App 权限比如Launchpad Designer/sap/bc/ui5_ui5/sap/launchpaddesigner或新版的 Maintain Launchpad Content。否则这个用户即便是普通用户也可能通过 App 前端修改全局内容。参数传递是一次登录全局生效的它不像一些细粒度权限可以精确到某个 Catalog 或 Group。所以如果你需要这一组用户只能改这个 Catalog 下的内容那一组只能改另一个 Catalog单靠 Scopes 不够还需要结合 Catalog 可见性规则做二次约束。4.3 越权误操作的真实案例Scope 配置错了关键用户改全公司我说一个真实项目里的翻车事件帮大家具象理解。某化工企业上线 Fiori 后IT 部门给 20 名车间关键用户开通了自定义首页的权限拿的是标准模板角色加SAP_UI_FLEX_PARAMALL。结果上线第二周夜班调度员因为桌面端工作台磁贴顺序影响工作效率就在 Launchpad 上直接做了拖拽排序。他拖完一刷新整条生产线所有调度员的首页全部变了白班同事直接打电话到 IT 部门投诉。排查过程其实很快在/sap/bc/ui5_ui5/sap/launchpaddesigner里管理员看到全局 Group 被修改CLIENT 的USR01参数里SAP_UI_FLEX_PARAM值已经被更新到了 20 个用户上。等管理员一个个改回USER再逐个通知用户刷新一下这事才算平息。事后复盘这个问题的根子不在用户操作而在 IT 部的授权粒度太粗。ALL影响的不只是当前用户是全局。如果你做的项目准备给关键用户开通个性化权限USER是底线ALL一定要留给专职管理员。5. 完整落地方案四步走配置出可控分层的 Fiori Launchpad5.1 第一步梳理用户清单和内容策略配置之前先盘一下人不能上来就改参数。你需要对用户做分类明确每个业务部门中谁是普通用户只要能看能用、别乱改谁是关键用户需要能局部调整、优化本部门工作台谁是管理员需要维护全局内容、处理投诉这部分要跟业务方开一次需求确认会把结论落实到一张用户授权矩阵表里作为后续 PFCG 配置的输入。没有这张表后面配置就是拍脑袋。5.2 第二步创建或调整业务角色写入正确的 Scope 参数在PFCG中按你的分层矩阵创建三个业务角色模板推荐命名规范Z_FIORI_ENDUSER普通用户角色。菜单里挂标准 Fiori 内容SAP_UI_FLEX_PARAM不设置或显式设为NONE。Z_FIORI_KEYUSER关键用户角色。在菜单页签里增加 Fiori Launchpad 的个性化参数项值设为USER。Z_FIORI_ADMIN管理员角色。值设为ALL并且加挂 Fiori Admin 相关应用权限严格控制分配范围。每个角色的菜单维护路径要核对正确尤其注意SAP 交付内容 Role如SAP_CORE_BC_EXT一般不会直接挂SAP_UI_FLEX_PARAM参数你需要在自定义角色上把它显式写出来。5.3 第三步验证配置别在用户环境里做火力试探配置完成后不要直接分发我习惯先在 QA 系统里做三类验证普通用户验证用一个测试用户登录 Launchpad确认磁贴顺序不能改、不能新建 Catalog/Group。如果必须允许个人视角的收藏就在 User Actions Settings Personalization 中打开相应开关再确认最终效果。关键用户验证用关键用户登录尝试创建个人组和个人 Catalog确认自己可见。再尝试进入 Launchpad Designer 的全局编辑模式应该被拒绝或没有任何内容操作入口。管理员验证用管理员账号登录能正常打开 Designer能修改全局 Group/Catalog改完普通用户刷新即可看到。这一步容易被忽略但它是把合理配置变成可靠配置的最关键一环。5.4 第四步建立运行规范和监测机制系统上线后我建议在运维手册里加入如下规则每季度审计一次SAP_UI_FLEX_PARAM值分布查询USR01表中该参数的值看有没有异常放大为ALL的用户。变更走流程任何用户从普通升级为关键用户都必须有业务审批记录IT 才能把角色加进Z_FIORI_KEYUSER。开通自助式反馈渠道用户遇到布局问题建议通过 IT 服务台反馈给管理员统一处理而不是给用户开大权限让他们自己解决。这样的治理机制配合一个配置正确的 Scopes 值能让 Fiori Launchpad 的内容分层策略既灵活又可控。6. 几个常见的隐藏坑位看到就是赚到6.1 Universal 模式陷阱某些 Fiori App 自带全局自适应权限并不是所有 Fiori App 都遵守 Launchpad 站点的 Scopes 设置。少数 App 特别是基于SAPUI5 Flexibility制作的自开发 App可以自带sap.ui.fl相关的变式配置允许用户在 App 内部创建全局变式Variant。这就意味着你可能把 Launchpad 的 Scope 设成了USER但用户在某个 App 内部依然可以创建全局变式影响他人。遇到这种情况需要额外在 App 的manifest.json或后端 BAdI 实现里加一层变式范围控制。6.2SAP_UI_FLEX_PARAMALL不等于管理员权限ALL模式只是开放了内容调整的能力不代表用户能直接进入后台管理界面。有的项目只看参数名以为给了ALL就万事俱备结果关键用户连 Launchpad Designer 的入口都找不到照样没法做全局维护。反过来给了ALL又没约束好角色则是另一个方向的灾难。所以务必把SAP_UI_FLEX_PARAM和 Fiori 管理 App 的授权分开看待两者结合才是完整的管理员能力。6.3 注意 User Role 中也可能出现ALL的历史配置升级或接手老项目时要主动检查现有 Role 的参数配置。我遇到过不止一次标准角色被以前的项目顾问改过里面赫然写着SAP_UI_FLEX_PARAMALL而且这个角色还挂在一大批普通用户身上。这种历史遗留炸弹如果不排查新配置上线后依然会被老参数覆盖。建议上线前统一跑一次RSUVM003或者直接查USR01把可疑角色全部拉出来评估。7. 这些经验是从好多次验证失败里换来的关于Scopes for Adapting Content的坑市面上文档讲得不多很多细节都是我在验证和排障过程中才体会到的。最后再分享三个比较贵的经验第一个多浏览器并发测试比一个管理员账号测试更可靠。有些权限问题在管理员账号下根本暴露不出来因为管理员对内容层有天然修改权。只有新建一个普通测试账号在干净浏览器里测试你才能看到真实用户看到的界面权限。第二个内容调整的落点可以通过系统日志跟踪。如果你怀疑某个用户的ALL操作污染了全局 Group可以在SM21里按Fiori关键字过滤或者在LPD_CUST中检查配置变更记录。跟追踪 ABAP 程序错误不同这种前端配置类日志容易被忽视但它恰恰能帮你确认调整时间点和操作者。第三个在项目沟通时不要对业务用户说我给了你个性化权限就结束。必须把个性化和全局维护这两个概念讲明白。我吃过亏业务方以为能改首页就是能改所有人的首页最后出了问题反过来质疑 IT 没有提示。一页纸的说明文档比一百行配置更能保证项目稳定。这套分层策略和配置路径我在三个不同类型的企业项目里复制过基本都能稳定跑在一个可控范围内。Fiori Launchpad 的灵活性和可控性从来不是二选一配置对了两者可以兼得。 
长河君 · 2026/9/11 3:54:23 · 阅读 1.2k Fiori Launchpad内容分层与Scopes参数配置实战
1. 一次现场问题让我重新审视 Fiori Launchpad 的内容分层去年有个项目上线 Fiori Launchpad 的个性化配置业务方提了一个很典型的需求我们希望关键用户能自己调整首页的磁贴布局但普通用户必须严格按我们统一规划的内容来看不能随便改。听起来像是权限就能解决的问题对吧结果我给了关键用户SAP_CORE_BC_EXT这个 Role 之后问题接踵而至——业务方反馈说关键用户不仅能改自己的视图居然还能把整个 Launchpad 的全局内容给动了。我当时第一反应是是不是角色给错了后来排查下来才发现问题出在Scopes for Adapting Content这个参数上。这个参数在 Fiori Launchpad 配置里叫SAP_UI_FLEX_PARAM对应 FrankFlexibility框架的SAP_UI_FLEX_PARAM参数通过它去控制Adaptation Scope自适应范围。简单说它决定了用户在运行时能对 Launchpad 的哪些层做修改、修改结果落在哪一层。这个错误把启动板从个人定制变成了全局覆盖直接影响了所有用户的生产界面。那之后我专门花了两天时间把 Fiori Launchpad 内容分层的逻辑、Scopes 的三种模式以及它们之间的组合关系彻底梳理了一遍再结合项目里的实际配置经验整理成这篇指南。如果你也在做 Fiori Launchpad 的推广、集成或者运维这篇内容大概率能帮你少踩几个我踩过的坑。2. 爬出层的概念迷宫Fiori Launchpad 内容分层的底层逻辑2.1 四层内容模型搞懂它才能搞懂 ScopesFiori Launchpad 的内容不是一坨平铺在服务器上的它天然是分层的。最常见、也被官方文档反复提及的模型分为四层从底到顶分别是SAP 交付内容Delivery Content这是 SAP 标准系统自带的 Launchpad 内容比如SAP_CORE_BC_EXTRole 底下自带的那些组、磁贴、目标映射。这层内容通常由 SAP 维护实施方不应该直接去改它因为一升级就会被重置。客户/合作伙伴内容Customer Content这是实施项目里真正需要花力气建设的一层。你通过SAP_FIORI_CONTENT_EXTENSION这类扩展 Role 去创建自定义目录Catalog、自定义组Group、目标映射Target Mapping把客户个性化的流程挂到 Launchpad 上。全局内容Global Content这层是运行时层面的它是在上面两层的基础上由管理员或者有权限的关键用户在 Launchpad Designer 里进一步做调整后的结果。它属于一个环境里所有用户都可见的公共层。个人内容Personal Content每个用户自己保存的视图、磁贴布局、筛选偏好只对当前用户生效。这四层里SAP 交付内容和客户内容属于设计期/静态层而全局内容和用户内容属于运行时/动态层。Adaptation Scope 控制的就是当用户在运行时做出修改动作时这个动作是被写进全局层还是个人层或者干脆直接被禁止写入。2.2 为什么要分这么多层因为不同角色的诉求天然不同很多业务用户不理解我就是在手机上调整了一下磁贴顺序为什么说会影响别人因为从 Launchpad 的视角看我调整了磁贴顺序这个动作本身是中性但落点不同影响面就完全不同。普通用户调整应该只影响自己这是Personalization的范畴关键用户调整可能要影响某个角色下的所有人比如销售团队登录后都应该把订单报表放在第一位管理员调整要能影响全公司这就是Global层的范畴。如果不加限制任何用户只要能进入个性化模式就有可能把个人调整提升为全局调整。那为什么默认参数没拦住因为 Scopes 的默认配置ALL就是把所有内容调整能力都放开这适合开发环境和初期测试但绝不适合生产环境。2.3 先理解层再来选 Scope不然一定会配错我见到很多配置人员一上来就翻文档查参数但没见过先把层这个概念理清楚的。Scopes for Adapting Content中Adapt这个词是核心——它瞄准的是运行时对已有内容做的调整而不是设计期从零创建内容。这两个概念容易被混淆后果就是你以为开的是个性化窗口实际开的是全局修改权限。所以在进入下一节的 Scope 模式解读之前请务必牢记这四层模型。所有 Scope 的配置决策本质都是回答同一个问题我的用户需要修改哪一层3. 逐个拆解 Adaptation Scope 的三种模式以及它们各自的杀伤半径3.1 Scope 模式速览在一个参数里藏着三种能力边界SAP_UI_FLEX_PARAM这个扩展参数在 Launcher即 Fiori Client层面生效好的它的取值主要有三种模式值含义能力边界全部放开ALL允许对 Catalog、Group、Target Mapping 等所有内容做创建、修改、删除并影响全局用户个人化USER只允许创建和修改用户个人视图不改变全局内容全部关闭NONE不允许任何内容调整但允许个性化如磁贴排序?等等这里有个容易误读的点NONE不是用户什么都动不了。在 Fiori Launchpad 的逻辑里用户对磁贴的排列、分组、颜色主题这类纯粹的个人化设置走的是另外一套机制通常不会因为 Scopes 为NONE就被完全锁死。真正被锁住的是对 Catalog、Group、Target Mapping 这类业务内容的增删改。如果你需要精细区分能不能调布局和能不能改业务内容建议参考SAP_UI_FLEX_PARAM的官方参数文档并且结合PFCG角色里的SAP_FIORI_UI_ADMIN或SAP_FIORI_CONTENT相关权限去控制管理入口。只看 Adaptation Scope 一个参数无法做到面面俱到。3.2 USER 模式最适合关键用户生产环境落地的一种我最推荐在典型场景中使用的是USER模式。它的官方描述是User-based Adaptation意为用户只能做基于个人内容的适配。在这种状态下用户可以新建个人 Catalog 并绑定应用磁贴吗可以但只对自己可见。用户可以新建个人 Group 吗可以也只对自己可见。用户能修改全局的 Group 吗不能。用户能影响其他同事的界面吗不能。这就是理想的责任田模式每个人在自己的地里随便折腾但碰不到公共区域。在我们的项目里这个模式是给关键用户Key User用的。他们在 USER 模式下可以把常用单据入口加入我的收藏、创建个人的日报处理组生产效率提升明显又不会污染全局内容。3.3 ALL 模式千万别在生产环境随意开放ALL模式对应Global Adaptation。在这种模式下用户所做的调整会直接写进全局层影响所有人。听起来很像超级管理员但它比管理员权限更隐蔽——因为它不要求你进入 Launchpad Designer 或 SAP Gateway 的后台配置界面直接在 Launchpad 的运行时界面里改。想象一下一个关键用户在早上 8 点看到采购审批App 太靠后了直接把它拖到了第一位。这个改动如果是ALL模式就会同步到所有启动了该 Global 层的用户的页面上。如果业务部门今天刚好有审计任务第一眼找不到自己的 App投诉就直接到你这里了。我在项目中只建议开发/测试环境用ALL正式环境要么USER、要么NONE。除非你能保证操作者对你的内容模型有完全的掌控力否则不要选它。3.4 NONE 模式适合有统一视觉规范和流程标准的业务NONE模式限制所有基于内容的 Adaptation这适合很稳定、很标准化的业务环境所有的 Catalog、Group、Target Mapping 都有专门的后台维护团队统一配置前台用户甚至包括关键用户都不需要做任何内容调整。这种模式的缺点也很明显Launchpad 的灵活性被锁死用户想收藏一个应用都得走 IT 流程业务满意度会下降。所以如果你打算用NONE建议同时开启标准的Personalization设置保证用户至少能调整主题、默认布局不然体验太僵硬。4. 三层内容分层策略从 User 到 Key User 再到 Admin各配什么 Scope4.1 明确的分层授权矩阵我建议这样配在实施过程中我最常用的一套策略是把用户群体分成三层分别对应不同的 Adaptation Scope 和 PFCG 角色用户群体对应业务用户PFCG 角色建议Scopes for Adapting ContentEnd User普通用户日常业务操作不需调整内容SAP_FIORI_UI_USER标准用户NONE或默认不设视管理要求Key User关键用户负责本部门流程视图优化SAP_FIORI_UI_USER 自定义关键用户角色USERAdministrator系统管理员负责全局内容维护SAP_FIORI_UI_ADMINALL限定管理员这套方案核心逻辑是内容修改半径随着职责变大而变大。普通用户只能动自己关键用户能优化自己部门相关的视图管理员才能动全局。权限粒度清晰审计也好追溯。4.2 底层实现SAP_UI_FLEX_PARAM 参数与 PFCG 角色绑定在实际系统里Scopes 是通过Launchpad站点参数SAP_UI_FLEX_PARAM传入的。这个参数一般在 LPD_CUSTLaunchpad 自定义里的Role 配置或业务角色配置中设置。以我常用的配置路径为例进入事务码PFCG创建角色或者在已有业务角色上做调整。在菜单页签中找到 Fiori Launchpad 相关的配置项通常是SAP_UI_FLEX_PARAM这项双击进入参数维护。把参数值设为SAP_UI_FLEX_PARAMUSER或NONE、ALL。激活角色重新生成参数文件。这里有两点经验千万别在 SAP_UI_FLEX_PARAMALL 状态下给用户分配任何内容维护相关的 Fiori App 权限比如Launchpad Designer/sap/bc/ui5_ui5/sap/launchpaddesigner或新版的 Maintain Launchpad Content。否则这个用户即便是普通用户也可能通过 App 前端修改全局内容。参数传递是一次登录全局生效的它不像一些细粒度权限可以精确到某个 Catalog 或 Group。所以如果你需要这一组用户只能改这个 Catalog 下的内容那一组只能改另一个 Catalog单靠 Scopes 不够还需要结合 Catalog 可见性规则做二次约束。4.3 越权误操作的真实案例Scope 配置错了关键用户改全公司我说一个真实项目里的翻车事件帮大家具象理解。某化工企业上线 Fiori 后IT 部门给 20 名车间关键用户开通了自定义首页的权限拿的是标准模板角色加SAP_UI_FLEX_PARAMALL。结果上线第二周夜班调度员因为桌面端工作台磁贴顺序影响工作效率就在 Launchpad 上直接做了拖拽排序。他拖完一刷新整条生产线所有调度员的首页全部变了白班同事直接打电话到 IT 部门投诉。排查过程其实很快在/sap/bc/ui5_ui5/sap/launchpaddesigner里管理员看到全局 Group 被修改CLIENT 的USR01参数里SAP_UI_FLEX_PARAM值已经被更新到了 20 个用户上。等管理员一个个改回USER再逐个通知用户刷新一下这事才算平息。事后复盘这个问题的根子不在用户操作而在 IT 部的授权粒度太粗。ALL影响的不只是当前用户是全局。如果你做的项目准备给关键用户开通个性化权限USER是底线ALL一定要留给专职管理员。5. 完整落地方案四步走配置出可控分层的 Fiori Launchpad5.1 第一步梳理用户清单和内容策略配置之前先盘一下人不能上来就改参数。你需要对用户做分类明确每个业务部门中谁是普通用户只要能看能用、别乱改谁是关键用户需要能局部调整、优化本部门工作台谁是管理员需要维护全局内容、处理投诉这部分要跟业务方开一次需求确认会把结论落实到一张用户授权矩阵表里作为后续 PFCG 配置的输入。没有这张表后面配置就是拍脑袋。5.2 第二步创建或调整业务角色写入正确的 Scope 参数在PFCG中按你的分层矩阵创建三个业务角色模板推荐命名规范Z_FIORI_ENDUSER普通用户角色。菜单里挂标准 Fiori 内容SAP_UI_FLEX_PARAM不设置或显式设为NONE。Z_FIORI_KEYUSER关键用户角色。在菜单页签里增加 Fiori Launchpad 的个性化参数项值设为USER。Z_FIORI_ADMIN管理员角色。值设为ALL并且加挂 Fiori Admin 相关应用权限严格控制分配范围。每个角色的菜单维护路径要核对正确尤其注意SAP 交付内容 Role如SAP_CORE_BC_EXT一般不会直接挂SAP_UI_FLEX_PARAM参数你需要在自定义角色上把它显式写出来。5.3 第三步验证配置别在用户环境里做火力试探配置完成后不要直接分发我习惯先在 QA 系统里做三类验证普通用户验证用一个测试用户登录 Launchpad确认磁贴顺序不能改、不能新建 Catalog/Group。如果必须允许个人视角的收藏就在 User Actions Settings Personalization 中打开相应开关再确认最终效果。关键用户验证用关键用户登录尝试创建个人组和个人 Catalog确认自己可见。再尝试进入 Launchpad Designer 的全局编辑模式应该被拒绝或没有任何内容操作入口。管理员验证用管理员账号登录能正常打开 Designer能修改全局 Group/Catalog改完普通用户刷新即可看到。这一步容易被忽略但它是把合理配置变成可靠配置的最关键一环。5.4 第四步建立运行规范和监测机制系统上线后我建议在运维手册里加入如下规则每季度审计一次SAP_UI_FLEX_PARAM值分布查询USR01表中该参数的值看有没有异常放大为ALL的用户。变更走流程任何用户从普通升级为关键用户都必须有业务审批记录IT 才能把角色加进Z_FIORI_KEYUSER。开通自助式反馈渠道用户遇到布局问题建议通过 IT 服务台反馈给管理员统一处理而不是给用户开大权限让他们自己解决。这样的治理机制配合一个配置正确的 Scopes 值能让 Fiori Launchpad 的内容分层策略既灵活又可控。6. 几个常见的隐藏坑位看到就是赚到6.1 Universal 模式陷阱某些 Fiori App 自带全局自适应权限并不是所有 Fiori App 都遵守 Launchpad 站点的 Scopes 设置。少数 App 特别是基于SAPUI5 Flexibility制作的自开发 App可以自带sap.ui.fl相关的变式配置允许用户在 App 内部创建全局变式Variant。这就意味着你可能把 Launchpad 的 Scope 设成了USER但用户在某个 App 内部依然可以创建全局变式影响他人。遇到这种情况需要额外在 App 的manifest.json或后端 BAdI 实现里加一层变式范围控制。6.2SAP_UI_FLEX_PARAMALL不等于管理员权限ALL模式只是开放了内容调整的能力不代表用户能直接进入后台管理界面。有的项目只看参数名以为给了ALL就万事俱备结果关键用户连 Launchpad Designer 的入口都找不到照样没法做全局维护。反过来给了ALL又没约束好角色则是另一个方向的灾难。所以务必把SAP_UI_FLEX_PARAM和 Fiori 管理 App 的授权分开看待两者结合才是完整的管理员能力。6.3 注意 User Role 中也可能出现ALL的历史配置升级或接手老项目时要主动检查现有 Role 的参数配置。我遇到过不止一次标准角色被以前的项目顾问改过里面赫然写着SAP_UI_FLEX_PARAMALL而且这个角色还挂在一大批普通用户身上。这种历史遗留炸弹如果不排查新配置上线后依然会被老参数覆盖。建议上线前统一跑一次RSUVM003或者直接查USR01把可疑角色全部拉出来评估。7. 这些经验是从好多次验证失败里换来的关于Scopes for Adapting Content的坑市面上文档讲得不多很多细节都是我在验证和排障过程中才体会到的。最后再分享三个比较贵的经验第一个多浏览器并发测试比一个管理员账号测试更可靠。有些权限问题在管理员账号下根本暴露不出来因为管理员对内容层有天然修改权。只有新建一个普通测试账号在干净浏览器里测试你才能看到真实用户看到的界面权限。第二个内容调整的落点可以通过系统日志跟踪。如果你怀疑某个用户的ALL操作污染了全局 Group可以在SM21里按Fiori关键字过滤或者在LPD_CUST中检查配置变更记录。跟追踪 ABAP 程序错误不同这种前端配置类日志容易被忽视但它恰恰能帮你确认调整时间点和操作者。第三个在项目沟通时不要对业务用户说我给了你个性化权限就结束。必须把个性化和全局维护这两个概念讲明白。我吃过亏业务方以为能改首页就是能改所有人的首页最后出了问题反过来质疑 IT 没有提示。一页纸的说明文档比一百行配置更能保证项目稳定。这套分层策略和配置路径我在三个不同类型的企业项目里复制过基本都能稳定跑在一个可控范围内。Fiori Launchpad 的灵活性和可控性从来不是二选一配置对了两者可以兼得。