企业官网建设流程全解析

今天这篇文章，起因是有位老哥在群里问：“我把‘采购申请审批’的磁贴放在首页第一个位置，过了两天它自己跑回‘更多’里了，是不是系统有什么定时任务在收拾我？”这个问题让我发现，很多人不是不会点按钮，而是对 SAP Fiori Launchpad 页面布局背后的“权力结构”没搞清楚。你看到的每个页面、每个分组、每张磁贴，其实都不是平白无故长在那儿的，背后有一套组（Group）、目录（Catalog）、磁贴（Tile）和目标映射（Target Mapping）协同工作的机制。这篇文章就围绕“Manage Launchpad Pages”这件事，把页面布局怎么管、管的时候哪些坑躲不开、页面改动怎么安全传到生产环境，一次性讲透。适合刚接手 Fiori 相关维护的后台顾问、系统管理员，也适合那些被用户频繁投诉“页面又乱了”的同事们。

1. 页面布局混乱的“底层追责”：组、目录、磁贴到底谁说了算

1.1 页面不是画出来的，是“拼”出来的

我刚接触 Fiori Launchpad 时有个误区，以为页面就像 PowerPoint 一样，可以由管理员随便拖拽画布、随意摆放。后来在系统里翻了半天才发现，Launchpad 页面本质上是一套动态装配的结果：系统根据登录用户的角色，把有权限的目录内容拿出来，再按照“组”的配置把它们组织成列、区段和磁贴，最终渲染成你看到的那个界面。你手动把一张磁贴拖到哪个位置，保存后确实生效了，但这个“生效”不是永久性的，它取决于磁贴和组之间的关联关系是否稳定。

所以当你发现磁贴“自己跑了”，先别怪系统抽风，大概率是这三件事里有一件发生了：

• 磁贴所属的业务目录被角色分配调整了，用户权限范围变化后，磁贴不再出现在可见目录里；
• 组被删了或者组的标识变了，磁贴失去了“挂靠点”，被系统归类到默认区域；
• 目标映射的配置失效，磁贴虽然存在，但导航目标不可用，系统把它降级处理。

我自己的经验是：处理这类问题，第一步不是进配置界面，而是先搞清楚“用户看到的页面”和“管理员配置的页面”中间隔了几层。你能看到的页面内容 = 用户角色（PFCG 菜单 / 业务角色）→ 业务目录（Catalog）→ 目录中的组（Group）→ 组内的磁贴（Tile）→ 磁贴关联的目标映射（Target Mapping）。任何一层的缺失或变更，都会直接反映到用户的 Launchpad 上。

1.2 磁贴、组、目录、目标映射各自管什么

这里可以把四个概念理解成“一桌菜”的安排：目录是菜谱，决定你能做什么菜（权限范围）；组是上菜顺序和摆桌方式，决定哪道菜放在哪个位置；磁贴是菜品本身，用户看得见摸得着；目标映射是菜和厨房之间的对应关系，告诉系统“点了这道菜，应该去哪道工序做”。四者缺一不可，但很多管理者容易把它们的职责搞混。

目录管的是“有没有资格看到”。目录里包含一组应用，通过角色分配到用户身上。用户没分配这个目录，哪怕你把磁贴摆到首页黄金位置，他也看不见。这一点经常被忽略：你花半天时间调整页面布局，最后发现用户根本不在分配了这个目录的角色里。

组管的是“放在哪一块区域展示”。组是布局的核心单位。系统默认按目录派生出组，但管理员也可以创建独立的自定义组，把不同目录的磁贴混排在同一个组下。比如我常做的“高频应用”组，就是把采购、财务、人事三个目录里最高频的 5 个应用放进同一个组，用户一登录就看到，不需要在“更多”里翻。

磁贴管的是“长什么样”。磁贴类型、大小、颜色、标题、副标题、图标都由磁贴配置文件决定。这里容易踩的坑是：同一个应用可能对应多个磁贴，每个磁贴的标题不一样（比如“采购申请”和“采购申请审批”，实际上是同一个 Fiori 应用的两个磁贴实例），你改其中一个，另一个却纹丝不动，用户自然觉得你没干活。

目标映射管的是“点下去之后去哪”。磁贴只是个壳，真正把点击行为变为应用启动的，是目标映射。如果目标映射配置正确但应用本身没部署，或者语义对象（Semantic Object）和动作（Action）不匹配，点击磁贴就会报“目标不存在”。这个报错经常被误认为是“页面布局坏了”，其实布局好得很，是导航链路断了。

1.3 为什么用户看到的和你配置的不一样

我最初管理 Launchpad 时，最郁闷的就是：配置界面里明明改好了，用户那边刷新很久还是旧样子。后来才明白，Fiori Launchpad 有客户端缓存和服务端缓存两层机制。

客户端缓存指浏览器里的本地存储（Local Storage），用户不强制刷新或浏览器不清理缓存，旧页面结构就会一直挂着。服务端缓存指应用数据在 Gateway 后端和 HANA 数据库之间的缓存机制，配置修改后，个别场景需要等待几分钟或通过缓存刷新操作才能读出新结果。所以你在后台改完保存，不等于用户立刻能看到新布局。正确的通知方式应该是：“配置已保存，请按 Ctrl+F5 强制刷新，或重新登录。”这一句话能挡掉至少一半的“页面没变”投诉。

另一个常见差异是设备类型。桌面端、平板、手机三种断点下，Launchpad 的渲染逻辑不同，组的排列、磁贴尺寸会被系统自动重排。同一组配置，手机上看可能是折叠状态，桌面端却整整齐齐。有些管理员非要在手机上复现桌面端的布局，这属于跟框架机制较劲，没有意义。你该做的是把组和磁贴配置做好，展示层交给系统。

2. 管理页面之前，先分清三种最容易搞混的页面形态

2.1 业务角色里的页面与个人化页面是两回事

SAP Fiori 里“页面”这个词非常容易被混用。最典型的第一种混淆：业务角色中通过目录和组配置出来的页面，和用户自己在浏览器里做的个人化（Personalization）页面，是两套独立机制。

业务角色页面是管理员基于业务需求统一布局，面向一组人，具有强制性和一致性。个人化页面是用户基于统一布局自己调整后的结果，比如把某个组折叠、把某张磁贴从首页移除、调整组顺序等等。个人化数据存在用户个人的配置里，管理员在后台看到的默认布局永远不会被个人化动作“污染”，但用户看到的，却是个人化数据覆盖后的效果。

这带来一个管理难点：用户投诉“我的磁贴没了”，你查后台配置完全正常，但用户的个人化数据里就是把它隐藏了。解决方式不是去改后台布局，而是清理该用户的个人化配置。具体做法一般是在系统管理里清空该用户对 Fiori 启动板个人化的标记（通常是通过用户数据清理工具或管理后台的操作），让用户回到默认页面。所以收到页面问题投诉时，先问一句“您是不是手动拖过或者关过什么”，能省很多排查时间。

运维建议：企业内如果对页面布局有严格规范（比如要求所有人看到同一套首页），建议在项目实施阶段就关闭部分个人化能力，只保留必要的个人化选项，避免后续管理成本爆炸。这件事最好在项目早期做，上线之后再限制个人化，用户已有的个人化数据并不会自动清理，你还得逐个处理。

2.2 自定义页面与标准页面的关系

第二种混淆：管理员自己新建的页面（Custom Page）和系统预置的标准页面（Standard Page）在主配置界面里混在一起时，不仔细看很难分辨。标准页面通常由 SAP 预交付，用于特定业务领域；自定义页面是企业业务顾问基于实际需求拼装的。

有一类典型问题：企业想改标准页面的布局，但直接去改标准页面发现保存不了，或者传输出去之后在测试环境不复现。这是因为标准页面的配置项受框架保护，你不能直接在客户命名空间里改标准配置。正确做法是复制标准页面到自定义命名空间（或客户化页面），在副本上做调整，再把标准页面从角色分配中替换为副本。

这里我踩过一个很实在的坑：复制页面后忘了同步更新目标映射和组关联，导致用户从新页面点了磁贴，系统跳去旧标准页面，完全重置。复制不是“另存为”那么简单，你得把复制的页面对应的组、磁贴、目标映射全部检查一遍，保证每个链接都是指向新命名空间的。

2.3 门户页面、工作区页面与 Launchpad 页面的区别

第三种混淆来自 SAP 产品线迭代。SAP Fiori Launchpad 是经典的应用启动界面，而 SAP Build Work Zone 这类新工具里也有“页面”概念，还包括工作区、子页面等。很多企业同时上线了 Work Zone 和传统 Launchpad，管理员经常对“我到底该在哪边维护页面”产生困惑。

简单理解：传统 Launchpad 页面的核心单位还是组、目录、磁贴，适合在 Fiori 设计器里维护；Work Zone 的页面则是更灵活的内容聚合载体，可以嵌入链接、文本、图表和传统 Launchpad 页面，更像企业门户。你既可以在 Work Zone 里嵌入一个完整的 Launchpad 页面，也可以在 Launchpad 里放一个跳转到 Work Zone 的磁贴。二者是包含和引用关系，不是替代关系。

我接待过的咨询中有不少是“页面加在传统 Launchpad 里了，但 Work Zone 里看不到”。原因多半是 Work Zone 里的频道或内容源没有重新同步。同步动作完成后，还要注意权限映射：传统 Launchpad 通过角色分配目录，Work Zone 通过内容源定义可见范围，两套权限体系如果不对齐，同样会造成“他有你没有”的怪现象。

3. 用 Launchpad 设计器调整页面布局的完整工序（含常用入口）

3.1 哪些场景适合进设计器，哪些场景不适合

SAP Fiori Launchpad 设计器（Launchpad Designer）是维护页面布局最常用的工具，但也要分场景使用。适合用设计器的场景包括：调整组的顺序、新增/删除组、修改磁贴标题和图标、配置磁贴跳转目标、调整磁贴在组内的排序、将磁贴从一个组移动到另一个组。

不适合用设计器的场景包括：给用户分配角色（应该去 PFCG 或业务角色维护）、修改应用本身的权限配置（应该在后台权限里控制）、删除某类目录下所有内容（应该批量评估后再动，避免误删）。记住一点：设计器是“布局工具”，不是“授权工具”。把权限逻辑塞进布局配置里，最后一定会乱套。

进入设计器的路径在不同产品版本里略有差异，但基本思路一致。我自己常用的做法是直接通过系统管理入口进入 Fiori Launchpad 设计器，在配置界面中维护“页面”相关对象。如果你不确定入口，可以在系统配置里查找 Launchpad Designer 相关的管理应用。

3.2 从组开始，把页面骨架搭对

我调整页面布局时，永远遵循“先组后磁贴”的顺序。组就是页面上的“分区”，分区不稳，磁贴再好看也没用。

具体操作思路：

1. 梳理当前所有组清单，先看哪些组是空的、哪些组只有一两张磁贴、哪些组名字语义不清。
2. 把高频业务入口合并进少数几个核心组，比如“我的日常工作”“审批任务”“分析报表”。
3. 组数量控制在合理范围。组太多，用户上下翻页找应用，体验极差。组太少，所有应用堆在同一屏，没有层次。
4. 为每个组设置清晰的顺序和标题。标题别用内部代号，用户看不懂；也尽量别用太长名称，手机屏幕上会折行。

这里我想多说一嘴：很多项目组在初始配置时喜欢“按目录建组”，结果每个目录对应一个组，菜单级目录有多少，首页就有多少组。这其实是偷懒做法。目录是权限结构，不该直接决定页面呈现。更好的做法是，定义两到三个业务聚合组，把不同目录的高频应用合并进组，其余低频应用留在“更多”里由系统分目录展示。

3.3 磁贴调整里最容易被忽视的细节

组骨架搭好后，再进磁贴调整。这时候要关注的细节比选图标要多得多：

• 磁贴标题要避免与同组内其他磁贴标题重复，否则磁贴区分度差，用户点错概率高。比如“采购订单”和“采购订单审批”，一眼看上去非常相似，最好加上前置说明或图标区分。
• 磁贴尺寸影响移动端展示效果。基础尺寸磁贴在手机端可能挤成一团，区块型磁贴适合展示少量但重要的应用入口。不要把所有磁贴都设成大图标，在窄屏设备上会严重破坏页面平衡。
• 磁贴的排序规则有两种常见逻辑：按字母排序和按手工排序。如果你在维护时发现磁贴顺序老是不对，去检查是否被系统按字母自动排序了。
• 磁贴状态：未激活的磁贴不会显示在最终页面上，但设计器里还能看到记录。检查页面问题时，先看磁贴是否处于激活状态。

另外，同一组里如果存在很多来自不同目录的磁贴，请确认这些目录都分配给了目标角色。否则就会出现“你组里配了两套磁贴，用户只能看到其中一套”的现象。这种问题的排查思路，就是按用户角色去模拟访问，而不是盯着设计器里的配置页空想。

3.4 保存、预览、发布，三个动作的区别

设计器里“保存”和“发布”是两回事。保存只是把改动写入配置存储，不一定会让在线用户立刻生效；发布或激活才意味着对运行时环境生效。不同产品版本对“发布”这个动作的具体叫法不完全一样，但你在做改动后一定要确认它真的激活了，而不是只保存了草稿。

预览功能也非常有价值。你在一个复杂页面上改完，最好先预览一下桌面端、平板、手机三种形态，确认磁贴没有溢出、组顺序符合预期，再正式放出去。我有一次改完没预览，结果一个标题过长的磁贴在手机端占了两个磁贴位，用户截图发群里，尴尬到不行。

发布后记得验证一次“真实用户视角”：用一个普通业务账号登录，不要用管理员账号。管理员账号往往有超级权限，能看到很多普通用户看不到的内容，用管理员验证页面布局，等于开了外挂测普通路线，不准。

4. 页面基线跨环境传递：让开发、测试、生产页面对得上

4.1 为什么页面改动在测试环境好端端的，到生产就变了

页面布局这类配置和代码一样，需要跨环境传递。很多管理员都遇到过这个经典困境：在测试环境把页面调得漂漂亮亮，走传输到生产后，磁贴位置、组顺序全变了，或者干脆生产环境里找不到那几个自定义组。

原因通常有两个：一是传输收集时只包含了部分配置对象，组、目录、磁贴、目标映射之间存在引用关系，如果收集不完整，就像菜谱只传了序言没传清单，厨房当然不知道该做什么；二是目标环境里原有的残留配置与新配置冲突，新对象是插进去了，但旧引用没被替换，系统呈现出来的结果就被“缝合”成了怪样子。

所以每次传输页面配置前，我建议做一次完整的配置清单梳理，重点检查以下内容：

• 组对象是否已全部包含（新增的和修改的都要）；
• 磁贴对象是否已包含，尤其是跨目录复用的磁贴；
• 目标映射是否包含关联的导航目标；
• 目录分配关系是否同步；
• 是否存在依赖前置数据（比如依赖某个自定义属性），前置数据是否已传输。

4.2 收集传输请求的正确姿势

在传统 ABAP 环境里，页面配置一般会涉及 Gateway 系统、业务系统和前端配置存储。你需要在正确的客户端和系统里做配置，然后在传输管理工具里收集对应请求。关键是要做到“完整收集”，而不是“看见几个对象收几个”。

我自己的习惯是：在配置完成并验证无误后，通过传输管理工具查看该配置段下的所有待传对象，包括自定义请求里新增的对象和已修改对象。确认对象列表之前，先用“对象列表对比”方式检查源环境和目标环境的差异。如果你所在环境没有自动记录，也可以手动导出配置内容作为备份，再在目标环境导入。

传输到目标环境后，不能只看“传输状态成功”。状态成功只代表对象到了目标系统，不代表运行时页面就按预期展示。你还要在目标环境里检查组依赖的目录是否已分配、磁贴的导航目标是否有效、目标环境的应用版本是否匹配。一个典型的翻车现场是：目标系统应用版本还没升级到位，磁贴传过去了，点进去报“未知应用”。这在多系统并行升级时经常发生，所以我把“目标系统应用版本匹配性检查”列为传输验证的必查项。

4.3 云环境与混合环境下的页面同步策略

如果你的系统部署在云环境，页面配置的管理路径又不同。云环境里用于自定义页面、组、磁贴和导航目标的内容管理，与本地环境的传输方式不完全一样。

我参与过的一个企业客户采用的是混合架构：核心业务系统保留本地，部分流程页面托管在云环境。页面布局在两边的维护方式、发布路径、权限策略都不同，曾经出现“本地改了组顺序，云上还是旧的”这种混乱。最后定了一个简单可行的策略：以云环境的内容管理为唯一入口，所有页面布局统一在云侧维护，通过内容同步机制分发到本地系统的 Launchpad 引用；标准页面维护则以本地系统为主。两条线分别立好规则后，再没出过“二义性配置”的问题。

这类策略没有万能解，但有一条主线不会变：页面布局的“定义权”必须收敛到一个地方。哪怕异构环境多，也要明确谁是主配置系统、谁是被同步系统。否则每个环境都有人改，最后谁也说不出哪个是正确的。

5. 页面上线后的常见乱象排查链路

5.1 用户看不到某张磁贴：先排查三层可见性

页面问题里最高频的，就是“某张磁贴我看不到”。遇到这种问题，按照下面链路来排查，基本不会漏：

第一层：磁贴激活状态。在配置里查看该磁贴是否处于激活状态，未激活的磁贴不显示。

第二层：目录分配范围。用户的角色里是否分配了该磁贴所在目录。这是我最常发现的原因——角色调整后目录被移除或替换，磁贴自然消失。解决办法是回到角色配置里，把对应目录重新分配，注意用户可能需要重新登录才能生效。

第三层：组关联关系。该磁贴是否加入了用户可见的组，还是只挂在某个未分配目录对应的默认组下。如果组本身是自定义组，还要确认这个自定义组是否对目标角色生效。

还有一个特殊情况：用户个人化数据里把磁贴隐藏了。如果你在后台三层都查完没问题，让用户退出登录，清理个人化设置，再重新登录查看。这一步经常被忽略，却是最快解决的路径。

5.2 磁贴掉进“更多”里，组怎么找回来

磁贴掉进“更多”区域是另一类高频问题。“更多”是 Launchpad 对未显式归组或超出页面空间的内容的默认收纳区。很多人问“能不能让所有磁贴都在首页平铺显示”，其实系统有限显示空间，超出一定数量后必然收起，这是正常机制，不是故障。

如果你希望某张磁贴从“更多”里出来，回到首页组，要去检查该磁贴是否属于某个已定义并分配给角色的组。如果它不属于任何自定义组，系统只能按目录默认规则帮它找位置，找不到就在“更多”里待着。

我通常会做两件事：一是将该磁贴显式加入一个明确的组，二是把该组顺序调到靠前位置。保存发布后重新登录，磁贴就从“更多”区域回到首页了。注意组顺序对“更多”里的展示也有影响，组顺序越靠前，其内容越可能优先展示。

5.3 点击磁贴报“目标不存在”的排查链路

这个报错比“磁贴消失”更让人头疼，因为它发生在点击行为之后，用户已经产生操作预期，突然断掉，情绪反应更大。排查链路如下：

第一步，检查目标映射是否完好。目标映射是磁贴与导航目标之间的桥梁，如果映射缺失或被覆盖，点击必然找不到目标。

第二步，检查语义对象和动作。磁贴配置中经常指定语义对象（Semantic Object）和动作（Action），系统会把两者拼成导航目标标识（SemanticObjectAction）。如果磁贴里的拼写与目标映射定义不一致，哪怕只差一个空格、大小写不同，也会报“目标不存在”。

第三步，检查应用是否已经部署并激活。目标映射背后对应的 SAP UI5 应用如果未部署或未激活，点击就找不到入口。这在系统刚升级或应用重新部署后最常见。

第四步，检查前端和后端版本兼容性。跨组件升级时，前端应用文件版本与后端服务接口版本不匹配，也会导致目标映射虽存在但访问失败。

我的排查习惯是先在诊断工具里查看 Navigation Target 的具体返回信息，而不是直接去翻配置。诊断信息会直接告诉你失败在哪个环节，省掉大量盲查时间。

5.4 怎么看“页面配置没生效”这类模糊反馈

用户说“页面配置没生效”，信息量太小，你要学会引导对方给出具体表现。是磁贴缺失？顺序变了？还是点击报错？甚至是看起来没变化？

这里有个操作层面的小技巧：让用户提供截图、时间点、设备和浏览器信息。同样的配置，在不同浏览器或缓存状态下表现差异很大。之前有一个案例，用户说页面布局没改，结果对方用的是旧版本浏览器内置的缓存策略过于顽固，强制刷新几次后一切恢复正常。

如果页面确实没变化，你还得确认：是不是改了业务角色默认页面，但用户访问的是个人化后的页面？是不是改了自定义组，但用户看到的页面是基于目录自动生成的组？是不是保存了但没发布？这些问题在排查链路里依次走一遍，基本能在十分钟内定位。

6. 把页面管理融入日常运营的几条经验

6.1 给页面维护建立“变更记录习惯”

页面维护看似是配置操作，本质是变更管理。我后来养成一个习惯：每次改动页面，都记录四个要素——改了什么、为什么改、影响哪些角色组、需要哪些人在什么时间点配合验证。这个习惯起初被同事嫌烦，后来一次生产事故复盘时，正是因为那条记录里的“影响角色组”写清楚了，运维团队五分钟就圈定了事发范围。

不需要复杂系统，一个共享表格就够。条目至少包括：日期、操作人、页面/组/磁贴名称、改动内容、涉及角色、传输请求号、验证账号、验证结果。

6.2 页面权限和布局职责一定要分开

部门级管理员经常只有布局维护需求，但没有角色调整权限。如果企业把页面维护权限开放给业务部门，必须在后台明确限制其角色和用户组维护权限。否则出现的情况就是：业务管理员为了帮助用户看到磁贴，顺手改了角色，导致其他用户被波及。

我们定的规矩是：页面布局问题，由页面管理员处理；角色分配问题，由权限管理员处理；二者联动场景，必须开变更申请。这个规矩听起来僵硬，但能拦住很多“好心办坏事”的越权操作。

6.3 周期性巡检比“救火式维护”更重要

页面布局不会一夜之间自己坏掉，大多数问题都是变更积累出来的。我建议每季度做一次巡检，重点看：是否存在孤立组、是否存在悬空磁贴、是否存在无目录直连的异常引用、是否存在长时间未激活的目标映射占位记录。巡检动作不复杂，但能提前发现潜在风险。

作为个人分享，最后补一句实操小细节：在维护页面配置前，建议先导出一份当前配置快照。快照本身不用提交给谁，纯粹是给自己留一条后路。每一次布局调整都当“上线”对待，你会发现页面管理这件事，远远没有大家想象中那么玄。