企业官网建设流程全解析

如果你管过 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，取决于他的工牌上盖了哪些章、这些章又关联了哪些仓库和展柜。

我把它们整理成一张对照表：

这里要特别注意一点：Catalog 和 Group 都不是直接分配给用户的，必须通过 PFCG 角色这个“中间人”。这也是为什么很多项目里配置明明存在，用户却看不到 tile——因为角色这条线没接上。

1.2 tile、Target Mapping、Intent：点击背后的三件套

tile 本质只是一个“外壳”。它决定你在 Launchpad 上看到的标题、图标、颜色、动态数字，但真正决定点击后跳到哪个 App、调哪个后端服务的，是跟它绑定的 Target Mapping 和 Intent。

一个 tile 的完整生命周期大概是这样的：

1. 实施方在 Launchpad Content 里创建或引用一个 tile。
2. 创建或引用对应的 Target Mapping，把 Semantic Object（语义对象）、Action（动作）和 System Alias（系统别名）绑定起来。
3. 将 tile 和 Target Mapping 放入某个 Catalog。
4. 将 Catalog 以及对应的 Group/Page 挂到 PFCG 角色。
5. 把角色分配给用户。
6. 用户登录 Fiori Launchpad，前端向后端请求该用户可见的 tile 列表。
7. 前端根据 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。

所以查这道闸门时，要同时搞清楚三件事：

1. 角色菜单里到底挂的是什么——Catalog、Group 还是 Page/Space；
2. 系统当前是传统 Group 模式还是 Space 模式；
3. 用户是否同时被分配了 Space 和 Group，如果是，前端优先展示哪个。

2.3 第三道闸门：Target Mapping、语义对象和系统别名

这道闸门是 tile 可见性里最让人头疼的部分，因为很多失效问题不报错、不提示，只是安静地“不显示”。

tile 要正常出现并且可点击，依赖 Target Mapping 里的三要素：

• Semantic Object（语义对象）：比如PurchaseOrder、SalesOrder、LeaveRequest；
• Action（动作）：比如manage、display、approve；
• System 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 高频症状排查速查表

这张表是我日常排查的浓缩版，基本覆盖了 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 还活着吗？服务激活了吗？前端缓存或个人化有没有干扰？走完这五步，答案基本就自己浮出来了。