如果你管过 SAP Fiori Launchpad一定遇到过这种场景业务同事跑过来说为什么老王的启动台上有“采购订单审批”这个 tile我这边却死活找不到或者更让人头大的是昨天还在的 tile今天突然没了。Fiori Launchpad 的 tile 可见性看起来是配置问题实际上是一大串层层叠加的过滤条件在起作用。我把这套机制叫作“过滤流水线”用户有没有匹配角色、角色有没有挂目录和组、目录里的 Target Mapping 有没有生效、后端服务和权限有没有放行、前端缓存和个性化有没有捣乱——每一环都是一道闸门全部通过tile 才真正出现在你的屏幕上。这篇文章不打算罗列菜单而是把这条流水线拆开给你看。无论你是做 Fiori 运维的、搞 Basis 的还是刚接手 Launchpad 配置的顾问照着这个思路排查基本都能在几分钟内定位到问题出在哪一层。1. 从配置到上屏一条 tile 的完整旅程先说一个很多人忽略的前提tile 不是“直接发给用户”的。它从配置到最终显示中间要穿过好几层容器每一层都有机会把它拦下来。所以在谈可见性之前必须先把这些容器搞清楚否则后面排查时你连“该看哪个事务码”都不知道。1.1 目录、组、角色三个先分清才能谈可见性Fiori 世界里最容易混的就是目录Catalog、组Group和角色Role。我的经验里十个说“tile 没配置”的人有五个其实是这三个概念没对齐。用生活化一点的类比目录是仓库里的货架专门存放 tile 和对应 Target Mapping组是店铺里的展柜决定用户打开 Launchpad 后先看到哪个分区角色是员工工牌决定这个用户能进哪个仓库、允许使用哪个展柜。用户最终能看到什么 tile取决于他的工牌上盖了哪些章、这些章又关联了哪些仓库和展柜。我把它们整理成一张对照表对象通俗理解在 Launchpad 中的作用常见维护入口Catalog 目录存放 tile 和 Target Mapping 的货架决定“有哪些可用的 app/tile”/n/UI2/FLPD_CUSTGroup 组前台的展柜/分区决定“这些 tile 以什么分组形式出现在首页”/n/UI2/FLPD_CUSTPage/Space 页面/空间新版本里的展柜升级版Fiori 3 模式下替代 Group控制页面布局/UI2/FLP_SPSPFCG Role 角色连接用户与目录/组的工牌用户通过角色获得 tile 可见性PFCG、SU01这里要特别注意一点Catalog 和 Group 都不是直接分配给用户的必须通过 PFCG 角色这个“中间人”。这也是为什么很多项目里配置明明存在用户却看不到 tile——因为角色这条线没接上。1.2 tile、Target Mapping、Intent点击背后的三件套tile 本质只是一个“外壳”。它决定你在 Launchpad 上看到的标题、图标、颜色、动态数字但真正决定点击后跳到哪个 App、调哪个后端服务的是跟它绑定的 Target Mapping 和 Intent。一个 tile 的完整生命周期大概是这样的实施方在 Launchpad Content 里创建或引用一个 tile。创建或引用对应的 Target Mapping把 Semantic Object语义对象、Action动作和 System Alias系统别名绑定起来。将 tile 和 Target Mapping 放入某个 Catalog。将 Catalog 以及对应的 Group/Page 挂到 PFCG 角色。把角色分配给用户。用户登录 Fiori Launchpad前端向后端请求该用户可见的 tile 列表。前端根据 Group/Page 渲染布局动态 tile 再通过 OData 拉取数值。这个链条里最容易踩坑的是第 2 步。很多人误以为“tile 配好了就一定能显示”但 Fiori 导航是按 Intent 走的比如#PurchaseOrder-manage。如果 Semantic Object 或 Action 对不上或者 System Alias 指向了错误的后端系统tile 要么直接不出现要么出现了却点开一片空白。后面讲过滤流水线时这个点会反复出现。2. 过滤流水线tile 可见性的五道闸门现在进入正题。我习惯把 tile 可见性拆成五道闸门从宏观到微观、从配置到运行时一层层过滤。每道闸门都有明确的检查对象、典型失败特征和快速验证方法。2.1 第一道闸门用户与角色的关联是否真的生效最基础也最容易被忽略的一道闸门。用户如果没有被分配到任何包含 Fiori 内容的业务角色Launchpad 上一片空白一个 tile 都不会有。检查这个环节常规路径是事务码SU01查看用户主数据里的“角色”页签或者用SUIM按用户查询角色分配。但真正到了项目里问题往往出在“角色分配没有同步”HR 主数据与用户主数据未同步新员工的角色根本没下发到 SU01批量导入用户后用户类型User Type不是“Dialog”导致无法登录或无法正常看到角色角色分配了但角色未激活或者角色的“生成授权”参数过期。这里我提一个实操心得不要只盯着 SU01 看。很多 SAP 项目里用户如同时间存在“直接分配”和“HR 组织分配”两个来源如果一个角色是通过 HR 职位绑定的SU01 里能看到但你需要检查同步是否完成如果是直接分配的还要确认是不是批次脚本漏跑了一段。注意第一道闸门不通过时问题表现往往不是一个 tile 不见而是整个 Launchpad 空荡荡甚至登录后直接报“无任何可用应用”。2.2 第二道闸门目录和组有没有挂进角色菜单第一道闸门过了用户有角色但 Launchpad 上要么没有分区要么分区里缺 tile。这时候大概率是角色的菜单树里没有正确挂载 Catalog 和 Group/Page。传统 Fiori 模式下常见配置方式是在 PFCG 角色的“菜单”页签里添加“Fiori 目录”或“Fiori 组”。添加目录后Launchpad 会以目录为单位把 tile 组织起来添加组后组就是用户看到的分区。但这里有一个非常经典的坑只加了 Catalog没加 Group或者加了 Catalog但 Catalog 里没有激活的 tile 和 Target Mapping。前者会导致 tile 没有明确的“展柜”可放后者会让整个目录看起来是个空壳。Fiori 3 之后情况更复杂了。如果系统启用了 Spaces空间模式用户被分配了 Space 后Launchpad 会优先以 Space 和 Page 的方式渲染传统 Group 可能直接不再显示。我接触过好几个升级到 S/4HANA 后的项目用户反馈“原来好好的 tile 全没了”最后排查下来系统并没有删配置而是 Spaces 模式启用后传统 Group 被隐藏了角色里又没有挂对应的 Space/Page。所以查这道闸门时要同时搞清楚三件事角色菜单里到底挂的是什么——Catalog、Group 还是 Page/Space系统当前是传统 Group 模式还是 Space 模式用户是否同时被分配了 Space 和 Group如果是前端优先展示哪个。2.3 第三道闸门Target Mapping、语义对象和系统别名这道闸门是 tile 可见性里最让人头疼的部分因为很多失效问题不报错、不提示只是安静地“不显示”。tile 要正常出现并且可点击依赖 Target Mapping 里的三要素Semantic Object语义对象比如PurchaseOrder、SalesOrder、LeaveRequestAction动作比如manage、display、approveSystem Alias系统别名指向实际后端系统的逻辑别名。这三者拼在一起就是 Fiori 的 Intent。例如#PurchaseOrder-manage。如果 tile 绑定了一个 Intent但系统中找不到对应的 Target Mapping或者 Target Mapping 被停用、系统别名失效前端在组装 tile 列表时就会把这个 tile 过滤掉。具体检查时可以用/n/UI2/FLPD_CUST打开目标目录逐条查看 Target Mapping 的状态。重点看系统别名是否存在是否指向了正确的后端系统Semantic Object 和 Action 是否与 tile 配置一致Target Mapping 是否被标记为已停用Inactive或已过时Deprecated。这里还要提一个容易被忽略的场景标准内容在升级后可能被覆盖或变化。SAP 标准目录里的 tile 和 Target Mapping 会随版本更新如果项目组直接改了标准目录升级后很可能出现“昨天还好好的今天突然少了一片 tile”的情况。我的建议是自定义内容尽量放到扩展目录比如/UI2/EXT或自定义/Z开头目录少动标准目录。2.4 第四道闸门服务激活与业务权限是否放行配置层面全通了tile 也不一定显示尤其是动态 tile 和需要后端调用的 tile。动态 tile 的特点是会在砖块上显示数字、图表或新闻摘要比如“待我审批 12 条”。它的数据来源是后端 OData 服务。如果服务没有激活或者当前用户没有该服务对应的权限前端拿不到数据可能出现两种结果tile 上数字空着或者 tile 直接不渲染。这道闸门的检查对象很明确ICF 节点状态用SICF检查/sap/bc/ui2/flp、/sap/bc/ui5_ui5等关键节点是否激活OData 服务注册和激活状态用/IWFND/MAINT_SERVICE查看服务是否已激活授权对象PFCG 角色里是否包含了访问该服务所需的S_SERVICE/S_ICF权限RFC 连接如果 Gateway 和后端分离还需要检查系统别名对应的 RFC 目标是否正常。有一个做运维的朋友跟我吐槽过他们项目里一个 tile 消失了大半个月最后发现就是后端系统升级时 OData 服务被重置成未激活状态。这不是个例我建议在生产环境变更单里把“服务激活状态检查”写成固定步骤避免系统升级后出现莫名奇妙的“tile 失踪”。注意业务权限不足时有时候不是 tile 消失而是 tile 在但点进去报“无权限”或者动态 tile 上的数字一直转圈。这种问题容易被前端误判为用户个性化问题实际是后端权限没有放行。2.5 第五道闸门缓存、个性化与空间发布状态前四道闸门都通过后tile 在配置层面已经“该出现了”但用户刷新后依然看不到。这时候就要看第五道闸门它包括了几个纯前端或缓存层面的因素。第一是缓存。Fiori Launchpad 在前后端都有缓存后端 Gateway 有元数据缓存前端浏览器有 tile 配置缓存。修改了目录、组、角色、Target Mapping 后如果缓存没有清理用户看到的还是旧数据。常见清理手段包括后端/IWFND/CACHE_CLEANUP清理 Gateway 缓存前端清除浏览器缓存或使用无痕窗口重新登录Launchpad 配置缓存在部分版本有/UI2/FLP_CACHE_CLEANUP。第二是个性化。用户可能在某次使用中手动隐藏了 tile或把 tile 拖出了当前分组。这种情况最迷惑人因为角色、目录、服务全都正常唯独这个用户看不到。处理办法是让用户在 Launchpad 设置里恢复默认布局或者检查前端本地存储中的个性化标记。第三是 Space 发布状态。Fiori 3 的 Space/Page 模式里新建的 Space 和 Page 必须先发布角色分配才会生效。可以想象成内容做出来但还没“上架”用户当然看不到。第四是设备类型。Launchpad 是响应式设计但某些自定义 tile 或 Target Mapping 可能被配置成仅在桌面端可见移动端访问自然看不到。这个在排查“手机上看不到、电脑上能看到”的问题时要优先考虑。3. 实操篇按流水线顺序排查一个“消失的 tile”讲完原理给一套可以直接抄的排查步骤。我自己遇到“tile 不见了”类问题基本都按这个顺序走很少扑空。3.1 第一步用 /n/UI2/FLPD_CUST 看用户视角/n/UI2/FLPD_CUST是 Launchpad 配置维护工具也是排查 tile 可见性最好用的起点。它能直接在配置层看到某个用户或某个角色下有哪些目录、组、页面以及对应的 tile 和 Target Mapping。操作上先按用户维护视图输入用户 ID系统会列出该用户通过角色能访问到的目录和组。这一步能快速把问题缩小到两种情形用户视角下根本没有这个 tile说明问题出在前两道闸门角色或目录挂载环节用户视角下有这个 tile但实际 Launchpad 上不显示说明问题更可能出在第四、五道闸门比如权限、缓存、个性化或前端渲染。这个“有没有”的判断非常关键能帮你避免在一个正确的配置上浪费时间。3.2 第二步顺着角色查目录、组和 Target Mapping如果第一步发现用户视角下就没有该 tile那就回到 PFCG 查角色菜单。打开PFCG输入角色名称进入“菜单”页签检查是否包含目标 Catalog/Group/Page。这里我建议看两个地方菜单树里有没有挂目标目录目录是否“非空”——如果目录里一个有效的 Target Mapping 都没有等于空目录目录中的 tile 是否绑定了正确的 Target Mapping有没有处于 Inactive 状态。如果是 Fiori 3 场景还要额外去/UI2/FLP_SPS检查 Space 和 Page 的发布状态。很多时候角色里挂了页面但页面没有 Publish 到用户前端就是不显示。3.3 第三步确认服务、权限和缓存状态配置链路全通后再往后端和运行时走。首先用SICF检查 ICF 节点确认/sap/bc/ui2/flp等关键服务已激活。然后用/IWFND/MAINT_SERVICE检查该 tile 对应应用所需的 OData 服务是否 active。如果是动态 tile还要看当前用户是否有读取数据的权限。确认服务和权限无误后最后清缓存。顺序建议是后端 Gateway 缓存清理 → 前端浏览器缓存清理 → 重新登录。如果是在配置更改后测试务必用一个“干净用户”或无痕窗口验证避免被旧缓存误导。3.4 一个真实案例系统别名惹的祸说一个我实际处理过的 case能让这套流水线更具体。某项目用户反馈升级后“采购申请审批”的 tile 在部分人 Launchpad 上消失了但同一套角色的另一批人却能正常看到。第一步用/n/UI2/FLPD_CUST按用户预览发现看不到 tile 的用户和看得到的用户角色分配、目录挂载完全一样。这说明前两道闸门没问题。第二步看 Target Mapping发现一个细节部分用户由于历史原因角色里套用了不同的系统别名一个指向新系统S4H_200另一个还是老的S4H_100。升级后老系统别名已经不再是激活状态指向它的 Target Mapping 直接失效tile 自然就不显示了。修复路径是更新 Target Mapping 的系统别名指向新的S4H_200然后清理 Gateway 缓存用户重新登录后 tile 恢复。这个 case 最典型的地方在于它不会在日志里留下明显的报错从角色、目录角度查全都是“正常”真正的问题藏在 Target Mapping 的系统别名上。所以排查 tile 可见性时别只盯着“有没有分配”还要看“分配的 Target Mapping 还有没有效”。4. 常见问题速查表与避坑经验最后把高频问题整理成速查表方便你截图存在手机里接到用户反馈时先对号入座。4.1 高频症状排查速查表症状最可能原因检查方向处理手段Launchpad 整个空白用户没有 Fiori 相关角色SU01查角色SUIM查分配分配正确的业务角色检查角色激活状态有部分分区但某个 tile 缺失目录/组未挂载或目录为空/n/UI2/FLPD_CUST按用户预览在 PFCG 中补充目录/组/页面tile 在但点击报错或白屏Target Mapping 系统别名或 Intent 不匹配/n/UI2/FLPD_CUST查看 Target Mapping修正系统别名、Semantic Object 或 Action只有个别用户看不到用户隐藏了 tile或该用户角色组合不同检查个性化设置、对比角色分配恢复默认布局或调整角色分配升级后一片 tile 突然消失缓存未清或 Spaces 模式覆盖了 Group查缓存清理日志、查系统是否启用 Spaces清缓存或给角色补挂 Space/Page手机上看不到电脑上正常设备可见性配置限制查看 tile/Target Mapping 的设备可见属性调整设备可见范围或改用适配方案动态 tile 数字一直不刷不出来OData 服务未激活或权限不足/IWFND/MAINT_SERVICE、SICF激活服务补充授权这张表是我日常排查的浓缩版基本覆盖了 80% 的可见性异常。4.2 项目中的几条保命实操心得踩了足够多的坑之后有几条经验值得写出来。第一条改配置前先在 PFCG 里建一个“最小测试角色”只挂一个目录、几个 tile分配给测试用户。这样排查问题时不会被一个角色里几百个 tile 干扰。我见过太多人在几十个标准目录里翻找半天最后发现问题根本不在那里。第二条任何配置修改后都要走完“用户-角色-缓存”三步刷新确认用户主数据同步、确认角色菜单重新生成、清理前后端缓存。少一步都可能让修改“看似生效但实际没生效”。第三条不要直接改标准 Delivered 目录。所有自定义 tile 和 Target Mapping优先放扩展目录。升级 S/4HANA 时标准内容会被覆盖或迁移如果你只在标准目录里做手脚升级后所有自定义都会不翼而飞。第四条生产环境排查“tile 消失”时先问一句“是所有人没了还是部分人没了还是一个人没了”。这个问题的答案能直接决定你先查角色、查权限、还是查个性化能省下一大半时间。最后再分享一个实战技巧遇到难啃的可见性问题别只看前端去 SE16N 里查一下CSTA_*相关的配置表比如目录、组、tile 关联表能和/n/UI2/FLPD_CUST里的界面信息互相印证。但要注意直接改表是高风险动作除非你对数据关系非常清楚否则还是走标准配置事务码更稳。我在实际项目里有一半以上的 tile 消失案例最后都是“低垂果实”角色改了没同步、用户手滑隐藏、空间没发布、缓存没清。先查便宜的环节再往深处挖能省掉大量时间。这套“过滤流水线”的思路你下次再接到类似问题不妨从用户视角那个 FLPD_CUST 入口开始一层一层往下游问角色通了吗目录挂了吗Target Mapping 还活着吗服务激活了吗前端缓存或个人化有没有干扰走完这五步答案基本就自己浮出来了。