ABAP环境Fiori Launchpad Pages与Spaces落地实践与避坑指南

在 ABAP 这套体系里摸爬滚打久了，你一定会遇到这个场景：Fiori 应用明明都发布出来了，用户进去还是对着一个超长目录干瞪眼。菜单越来越长，权限越来越乱，每个项目上线前都要花好几天调 Launchpad，上线后又天天有人问“这个应用该点哪”。这时候，Pages 与 Spaces 这套机制就是用来救场的。

这篇内容我写给你，主要是面向正在做 ABAP 环境（S/4HANA 或 SAP BTP ABAP 环境都算）里 Fiori Launchpad 的顾问、BASIS、以及负责把系统交付出去的人。你会搞清楚为什么传统的 Group 模式做不成“可运营的产品入口”，也会知道 Pages 与 Spaces 怎么落地、怎么设计、怎么避开我实际踩过的坑。

1. 旧 Group 模式为什么做不成“可运营的产品入口”

最早接触 Fiori Launchpad 的时候，大家用的都是 Group。那时候觉得也还行，反正就是把一堆 tile 拖到某个分组里，用户登录后按组导航去找应用。但时间一长、用户一多，你会发现这玩意儿是按照“管理员的喜好”组织的，而不是按照“用户的工作场景”组织的。

1.1 Group 模式的问题：它是静态目录，不是工作场景

Group 模式天然围绕“菜单”设计，它把所有应用平铺到一个或者多个分组里。今天加一个财务应用，明天加一个人事应用，后天可能还要加个自定义的 Z 程序。结果是：每个组越来越大，组里面的排序越来越随意，新来的用户根本不知道第一下该点什么。

更头疼的是权限和可见性。很多项目团队为了让某类用户只能看到部分应用，会在 PFCG 角色里反复折腾菜单，或者在语义对象/导航配置里做权限控制。这种搞法不是不能跑，但“产品的入口”讲究的是：用户打开 Launchpad，看到的是跟他今日工作完全匹配的操作台，而不是一个需要他记住位置的巨型菜单。

1.2 “可运营”意味着什么

运营不是一次性的交付，而是常态化的发布、调整、监控、下架。对一个产品入口来说，你的应用列表会持续变化：新应用要灰度给一小批用户、老应用要逐步下线、某个业务场景的入口要临时调整。

Group 模式下的应用归属是“全局的”，它没有把“应用本身”和“应用在界面上的呈现位置”解耦。你想给销售团队做一个“订单处理工作台”，做一个“发货异常处理台”，单靠 Group 只能又新建一组 tile，然后手动选择一个又一个应用。应用一多，这样的组就是线性增长，维护成本完全失控。

Pages 与 Spaces 就是在这个背景下推进的。它把“有哪些应用可提供”这件事，和“用户在某个场景下看到哪些卡片、什么布局”彻底分开了。这个概念说白了不复杂，但理解后对整个项目交付方式会产生根本性的变化。

1.3 我为什么在项目切换期强烈建议新项目别再回到 Group

很多项目是从老版本升级上来，Fiori Launchpad 里还保留着大量 Group 配置。我不建议一上来就全部推翻，但新开发的场景，尤其是那些要面对多种用户角色的业务场景，尽量用 Pages 与 Spaces。

一是 Group 属于兼容模式，未来 SAP 在界面上虽然不会直接废弃，但从产品演进方向看，Spaces 才是符合现代 Fiori 设计语言的。二是你迟早要面对多语言、多渠道、多终端一致性问题，Group 模式的定位天生就是“一个分组一屏菜单”，缺少层级和场景的支撑。

2. 把数据模型理清楚：Catalog、Page、Space、Group 到底谁管谁

提到 Pages 与 Spaces，很多新手容易卡在概念上。其实用大白话一句话说：应用先进 Catalog（目录），再从 Catalog 拖进 Page（页面），多个 Page 归一个 Space（空间），最后把 Space 给角色。

2.1 Catalog 是应用的“仓库”

Catalog 在 Fiori 里的定位是逻辑分组。你可以按产品线、按模块、按部门去建。Catalog 里放的就是一个个应用和它们对应的 tile。这个层级不应该关心用户会怎么布局，只负责回答一个问题：“系统里有哪些应用可以被摆上入口”。

Catalog 设计得好不好，直接影响到你后续的复用。比较合理的做法是让 Catalog 跟业务领域对齐。比如订单中心相关应用全部放进“Catalog_Order”，人事服务相关应用放进“Catalog_HR”。这样即使以后换了页面布局、变了空间划分，应用的出处还是清晰的。

2.2 Page 是“画布”，Space 是“工作区”

Page 相当于一块可定制的画布，你可以把同一个 Catalog 或者多个 Catalog 里的 tile 排列出来，定义行和列，定义卡片尺寸，还可以加入文本、链接、卡片组。用户看到的 Launchpad 首页，本质上就是一个 Page。

Space 则是一个更高层的容器，一个 Space 可以包含一个或多个 Page。Space 解决的是“员工一天要处理几类工作”的问题。销售代表可能每天涉及“客户管理”“订单处理”“售后任务”三类工作，你就可以建三个 Page，组合到一个名为“销售工作台”的 Space 里。

用户登录后，Launchpad 顶部显示 Space 列表，点进去之后显示这个 Space 下的 Page，页面里才是具体的 tile。这个层层递进的组织逻辑，就是一个“产品入口”的标准结构。

2.3 Group、Catalog、Space 的关系如何映射

我把三者的关系用下面这个角度去理解：

这套关系理清之后，你会发现它跟“产品运营”的逻辑很对称。一个产品入口是有“货架”的，Catalog 就是仓库里的货架分类，Page 是前置仓的陈列面，Space 是给顾客划分的动线。顾客不会关心仓库分类，但他们会对“我们的动线是不是顺手”特别敏感。

3. ABAP 环境里启用并落地 Spaces 的实操步骤

下面这部分，我按自己在 ABAP 环境里的实际配法写，已经跑通过多个项目。不同系统版本入口名称会有细微差异，但核心逻辑一致。

3.1 确认系统已经启用 Spaces 功能

在 Fiori Launchpad 里进入“配置”或“Launchpad 设置”，找到是否启用 Spaces 的开关。不同版本把这个开关放在不同位置，有些在事务代码/N/UI2/FLP的右上角设置里，有些在后台维护。但先强调一个容易被忽视的前提：Spaces 模式必须在整个系统里打开，而不是单独对某个用户打开。

SAP 在这方面的处理策略是保留了旧 Group 与新 Spaces 的并存期，但如果你想让 Spaces 真正生效，需要保证两点：一是系统版本支持 Fiori 3 以上的 Launchpad，二是所有相关角色都已经分配了至少一个 Space。

3.2 创建 Catalog 并维护应用

打开 Fiori Launchpad Designer（通常通过/N/UI2/FLP或事务代码LPD_CUST），先创建 Catalog。创建 Catalog 时给一个清晰的技术名称，建议前缀用CAT_。然后把你要发布的应用从应用列表拖进去，同时可以配置 tile 的标题、副标题、图标。

Catalog 是跟着传输请求走的。这意味着你在开发系统里建好 Catalog，可以通过请求传输到测试、生产。这里我踩过一个坑：Catalog 里的应用 ID 必须和系统里 Fiori 应用的注册 ID 完全一致，尤其在自定义应用场景下，容易把前端组件 ID 和后端 OData 服务名搞混。

3.3 创建 Page 并摆放 tile

Catalog 建好之后，回到 Designer 首页切到 Page 页签，新建 Page。你可以选择把它归类到一个 Space（如果 Space 已存在），或者先不关联，等 Space 建好后挂上去。Page 里的 tile 排列方式支持多列、多行，支持大卡片、小卡片。我建议按使用频率排序：高频操作放左上角，低频操作放右下角，跟 Web 端用户注意力模型保持一致。

另外 Page 之间可以设置“关联页面”，也就是级联跳转。比如主页面是“订单处理”，点某个卡片后跳到关联页面“订单详情操作”，这种场景适合在同一 Space 下做二级导航，但不要做得太深，两级就够。

3.4 创建 Space 并分配到业务角色

Space 的创建有两种路径：一种是手动在 Designer 里建，然后手工分配；另一种是使用 PFCG/业务角色维护时直接把某个 Space 挂到角色上。在 ABAP 环境里（尤其是 S/4HANA），更规范的方式是在业务角色维护界面的 Launchpad 区域里关联 Space。

给角色分配 Space 的时候要特别注意，Space 一旦分配出去，用户的 Launchpad 默认就会显示这个 Space。如果用户被分配了多个 Space，他会看到多个顶部页签。我见过不少管理员把十来个 Space 全部塞给一个角色，结果用户一登录看到一长排页签，体验反而比 Group 还差。正确做法是：一个角色最多两三个 Space，一个 Space 包含三五个 Page，每个 Page 的 tile 控制在十到十五个以内。

3.5 验证可见性和权限

配置完成后，用一个测试账号登录 Launchpad，确认几个点：用户在首页能看到分配给它的 Space；每个 Space 下的页面只显示授权范围内的 tile；点击 tile 能够顺利跳转到 Fiori 应用；没有分配权限的应用不会出现在搜索结果里。

在这个环节一定要做“最小权限”验证。我遇到太多系统上线后用户能看到入口、但点进去没有数据或报错的情况，原因往往不是在 Spaces 配置，而是底层 PFCG 授权对象、SICF 服务、OData 服务没开。Launchpad 的入口只是最后一道门，前端的 Fiori 应用本身也要做权限校验，这点别指望 Spaces 能帮你兜底。

4. 按产品运营思路设计 Launchpad：空间划分、导航规则与角色策略

说完了配置，再用半天聊聊“运营”。配置做出来只是一个骨架，真正让 Launchpad 成为一个产品入口的，是你怎么划分空间、怎么定导航规则、怎么让每一个角色都觉得这个入口是“给我量身定做的”。

4.1 划分 Space 的第一原则：按任务，不按部门

把 Space 命名为“财务部”还是“月结处理”，表面上只是措辞差异，实际上反映的是两种截然不同的设计观。按部门划分，本质上还是旧菜单思维；按任务划分，才是工作台思维。

月结处理这个 Space，里面可以放“总账凭证处理”“固定资产结账”“应收对账”“关账报表”等跨模块的应用。用户在做月结期间，只需要打开这一个 Space，不用在财务部的长菜单里翻页。划分时你可以列一个用户典型工作日清单：上午什么任务、下午什么任务、月底什么任务、季度底什么任务。一个任务就是一个候选 Space，而不是一个部门一个 Space。

4.2 留下导航的“最小足迹”

Fiori Launchpad 引入 Spaces 之后，搜索框仍然是用户找应用的重要手段。所以你不需要把每个能分配的 tile 都摆在页面上。运营上比较合理的原则是：页面只放高频任务和关键业务动作，低频操作靠搜索完成。

如果把应用都堆在页面上，不仅信息密度过高，还会导致后续统计“哪个应用真正被使用”的时候出现噪音。你当然可以靠 Fiori 的使用情况分析去看点击率，但如果入口太杂乱，分析出来的数据无法指导你优化产品。入口即产品，信息架构本身就是用户体验的一部分。

4.3 用语义对象和导航规则支撑跨应用流程

一个产品入口免不了要做跨应用跳转，比如从销售订单列表跳到客户主数据、从财务凭证跳转到供应商信息。在 Spaces 里这些可以通过 tile 的目标映射和语义对象来定义。

语义对象（Semantic Object）加动作（Action）的组合本质上是在生成一个跨应用的意图。它甚至不需要知道目标应用具体部署在哪，只需要在 Launchpad 里配置好别名和映射。这块在 ABAP 环境里配置起来不难，但建议统一命名规范，例如语义对象一律用业务对象名，动作一律用动词。别小看命名的价值，等配置超过两百个意图映射的时候，名称混乱会直接导致后期无法定位问题。

4.4 运营节奏：从“一次性上线”变为“分批发布”

在 Group 模式下，菜单权限一阵容调整就要动一整个角色，风险范围特别大。Spaces 模式下，目录、页面、空间都是相对独立的对象，你可以实现更细粒度的发布策略。

比如新上线一个采购订单审批应用，你不需要把整个采购工作台重做，只需要在已有的“采购处理”Page 里加一个 tile，发布时只调整这一个页面对象对应的传输请求。如果要对小部分用户试用，则可以把这个页面放进一个临时的 Space，分配给试点角色，等反馈稳定后再并入正式 Space。

这种能力才是“可运营”的真正含义，让你的入口能跟上业务变化，而不是业务变了你还要等一个跨月的角色调整窗口。

5. 上线后才会暴露的问题（以及我的避坑清单）

最后这部分，把我在多个项目上实际踩过的坑集中说一下。有些坑机制里自带，有些则是因为团队协作方式引起的，希望能帮你省掉几周调试时间。

5.1 新旧模式混用的问题

启用 Spaces 不等于旧的 Group 自动消失。系统里之前分配给用户的 Group 仍然会生效，如果用户在 Spaces 之外还看到一堆旧的组菜单，体验会很割裂。

我的建议是，在启用 Spaces 的过程中，把旧 Group 的分配全部清理干净，只保留 Spaces 模式。SAP 在配置里也有相关参数控制是否隐藏传统群组，但你最好做一次全局检查，千万不能以为系统切到新版本后旧配置就自动不显示了。切换前把角色清单整体过一遍，把还挂在角色上的 Group 引用清掉，比上线后再懊恼强得多。

5.2 传输请求里容易漏掉的对象

Spaces、Page、Catalog 的配置一般都会进传输请求，但你不一定把所有关联对象都带全。尤其当你创建了自定义的角色时，角色里关联的 Space 引用是否随请求走了，需要仔细验证。

我在一次升级中，生产环境里所有 Page 都正常，但用户登录后看到 Space 下面空荡荡，查了半天才发现是 Catalog 跟 Page 的关联关系没传到生产环境，导致页面上一片空白。这类问题在预览环境很难暴露，因为你在开发系统里看到的都是完整数据。经验是上线前导出所有 Catalog、Page、Space 清单，在生产环境核对数量和数据完整度。

5.3 权限设置：别把“可见”当成“可点”

Launchpad 上的一个 tile 能看见，不代表用户就能正常打开应用。这个点前面提过，但我还想单独拎出来强调，因为它太容易出问题了。

一个 tile 从可见到最终正常显示 Fiori 应用页面，要经过 SICF 服务激活、前端组件部署、OData 服务权限、后端授权对象、组件自身权限检查等多道门槛。Spaces 配置只是让入口出现，真正的权限控制贯穿整个系统链路。上线前需要拿一个空权限的测试账号从零开始验证，而不是拿管理员账号测完就算通过。

5.4 运营期间的口径与规范

如果项目有多位管理员维护 Launchpad，强烈建议定一份命名规范。Catalog 用前缀区分业务域，Page 用场景命名，Space 用角色或工作台命名，tile 的标题避免放太多业务黑话。没有规范，三个月后每个人都要花大量时间去猜当时为什么这么配。

最好再配合一张目录清单表，定期更新。表里字段比你想象的还要简单：Catalog 名称、关联的业务领域、归属 Space、页面名称、维护人、更新时间。这张表不用进系统，放在团队共享盘或者 Wiki 里就行，但能解决大量“这个 Catalog 能不能删”之类的困难问题。

5.5 最后一点心得

从老 Group 迁到 Pages 与 Spaces，并不只是一个技术动作，它改变了我们交付 Fiori 入口的方式。以前交付的是一个菜单，现在交付的是一套可以随业务结构调整的运营框架。配置本身花不了太多时间，真正花时间的是理解业务、划分场景、厘清权限链路。如果你正准备在 ABAP 环境里做这方面的重构，我建议先把 Space 的顶层设计图在纸上画出来，再进系统动鼠标。一旦这一步想清楚了，后面的实现就是水到渠成的事。