在 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工作场景的容器顶部导航入口按角色/工作台分配Group旧版压缩包旧的菜单导航不建议再用这套关系理清之后你会发现它跟“产品运营”的逻辑很对称。一个产品入口是有“货架”的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 并摆放 tileCatalog 建好之后回到 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 的顶层设计图在纸上画出来再进系统动鼠标。一旦这一步想清楚了后面的实现就是水到渠成的事。