最近接了一个 Fiori 项目的运维诊断客户反映 Launchpad 上的磁贴总是时有时无权限加了又看不到应用补丁发布完第二天用户又反馈入口不见了。坐下来排查了一圈发现配置本身没有大错真正的问题出在团队把 SAP Fiori Launchpad Designer 当成了一个“什么都该管”的工具既想用它做应用开发又想用它做权限管理还想让它完成整个工作台的站点规划。这个工具本身的设计并不算复杂真正拉开项目体验差距的是你打开它之前有没有做过内容建模以及打开它之后有没有一套分层治理的纪律。这篇文章我就把自己在几个项目里总结的打开方式完整讲一遍希望能帮正在实施或维护 Fiori 的顾问、甲方 SAP 管理人员少走一点弯路。1. Launchpad Designer 到底管什么、不管什么1.1 工具定位它是内容配置层不是应用开发层很多人第一次打开 Launchpad Designer 的时候看到左侧一堆目录、组、磁贴第一反应是“我是不是能在这里创建新的 Fiori 应用”这是一个非常普遍的误解。实际情况是Launchpad Designer 是一个基于浏览器的内容配置工具不是开发工具。你在里面创建和维护的是一组“内容对象”比如目录Catalog、组Group、磁贴Tile、目标Target。这些对象的本质是配置元数据它们负责回答三个问题“用户能看到什么”“用户点开去哪里”“用户点击之后携带什么参数”。而应用本身——也就是 SAPUI5 视图控制器、Fiori elements 的注解、OData 服务这些真正承载业务逻辑的东西——是在开发环境里构建、部署完成的Launchpad Designer 根本碰不到。我用一个通俗的类比来理解这件事Launchpad Designer 更像电视台的编播系统它决定《新闻联播》在几点播出、在哪一个频道、片头用什么画面但它不负责拍摄新闻素材也不负责剪辑成片。素材和成片是内容制作团队的事编播只是最后一公里的排期与呈现。你不可能靠编播系统写出一档新节目同样你也别指望 Designer 能帮你把一个自开发页面“做”出来。1.2 它和周边几个工具怎么分工Fiori 实施过程中管理员往往要被好几个名字绕晕Launchpad Designer、SAP Build Work Zone、前端服务器配置、业务角色配置……我见过最混乱的项目是几个人在各说各话结果配置目标放到了不同的位置。我把这条分工线整理成了一张表你在项目里可以直接拿去做培训材料层次产出物主要使用者典型问题应用开发层SAPUI5 应用、Fiori elements 服务、OData 服务开发人员应用怎么样能被 Launchpad 发现内容配置层目录、组、磁贴、目标、导航参数Fiori 内容管理员如何组织入口、如何跨应用导航权限授权层PFCG 业务角色、目录到角色的分配安全顾问、业务关键用户哪个角色能看到哪些目录站点入口层站点 URL、主题、统一入口配置平台管理员或 BTP 管理员用户登录后第一眼看到什么Launchpad Designer 的核心位置在第二层。它向上承接开发层已经发布的应用向下把结果交给权限层和站点层去引用。边界一旦清楚你就不会再出现“让开发在 Designer 里改标题”“让安全顾问在 Designer 里加角色”这类错位。1.3 什么时候不该用 Launchpad Designer还有几个场景我会明确建议团队不要碰 Designer第一不要用它做复杂的品牌定制。主题、Logo、首页整体版式应该去站点管理层面的配置里做。Designer 里的磁贴能调颜色、能换图标但它不是一套品牌系统别指望它承担整套企业 VI。第二不要用它替代业务角色管理。Designer 里有“目录分配给组”这类操作但“哪些用户有权限登录这个目录”是靠角色体系完成的。把权限逻辑写进磁贴描述里还不如不写。第三不要拿它做跨环境配置同步的工具。内容对象需要靠系统标准传输机制从前端资源库搬运而不是你在 Designer 里做一遍、再到生产环境重新做一遍。这点后面第五章还会细讲。2. 从业务输入到内容模型先有结构再谈配置2.1 建模第一步把业务需求翻译成“角色 × 任务”矩阵我接手过的项目里最常见的失败模式是业务方甩过来一张 Excel里面列了十几个应用的名字然后说“帮我把这些放到 Launchpad 上”。如果你照着这张表直接建组配置倒是很快但三个月后你就会收到一批“找不到应用”的工单。为什么呢因为应用清单不等于用户体验结构。用户登录 Fiori 工作台不是来看应用清单的他是来“完成工作”的。一个采购员打开工作台他脑子里想的是“今天有哪些采购申请要批”而不是“我要找 MRP 应用”“我要找采购订单应用”。所以在打开 Launchpad Designer 之前我先建议建模团队做一张“角色 × 任务 × 应用”矩阵这是内容建模的核心输入。做法不复杂三步列出目标角色比如采购员、采购经理、质检员。对每个角色梳理他高频的任务比如“审批采购申请”“查看未清订单”“创建质检报告”。把任务映射到具体的 Fiori 应用上并标出高频、中频、低频。有了这张矩阵你再看 Launchpad 的结构就会自然得出分组逻辑按任务或者按业务流程分组而不是按应用所属模块分组。一个采购员看到的首页应该是“待办审批”“采购执行”“报表分析”这种结构而不是“SAP 采购模块应用 1”“SAP 采购模块应用 2”。2.2 分组、目录、目标三个对象的职责边界内容建模的核心对象有三个组Group、目录Catalog、目标Target。这三个词很容易混但职责是完全分开的。目录是权限和功能的逻辑集合。一个目录里可以放多个应用目标通常按模块或业务域划分。目录的典型特点是要和角色体系挂钩你把某个目录分配给某个业务角色用户才能看到里面的应用。所以目录起名的第一原则应该是可读、可归属。比如Z_PUR_Purchasing_Fiori_Apps一看就知道是采购模块的自定义 Fiori 应用目录。不要用Test1、Apps123这种名字后面维护的时候真的会让人崩溃。组是登录后的可视分组也就是用户打开 Launchpad 时看到的那些磁贴区域。同一个目录下的应用可以被组织进不同的组同一个应用也可以出现在多个组里。组的设计原则是“用户的任务视角”而不是“管理员的功能视角”。比如“待办审批”这个组里面可能既有采购申请审批又有质检任务审批它们可以来自不同目录但都归属同一个用户任务。目标是导航的落点。每个目标背后对应一个真实的应用地址同时配置了语义对象Semantic Object和动作Action。为什么这两件事重要因为 Fiori 的跨应用导航本质上是语义对象和动作的匹配。比如一条物料主数据记录在物料应用里点“查看供应商”系统会找供应商应用的“显示”动作条件是它能匹配同一个语义对象。你在配置目标时如果语义对象拼写、大小写不一致跨应用导航就会静默失败——用户点了没反应又不报错。2.3 磁贴字段用户第一眼看到的信息是设计过的提示具体到磁贴本身Launchpad Designer 里可以配标题、副标题、图标、信息文本等字段。大多数人会随便填一句话就保存但这里其实是一个体验设计点。磁贴标题建议控制在 60 个字符以内中文大约 20 字副标题只放最关键的说明不要在这里写“本应用用于……”这种废话。图标的选择也有一点讲究优先选 SAP 图标库里的语义化图标比如“审批”用打勾“报表”用柱状图不要图好看挑一些和业务毫无关系的图案。多语言环境还要注意标题回退机制。如果你在默认语言下填了中文标题英文环境下用户会看到中文标题因为系统用的是语言键对应已经翻译好的文本如果那个语言没有翻译就会落到默认语言。所以第一个经验是在 Designer 里新增磁贴文本时尽量同时维护好多语言翻译文本别只维护一种语言然后指望它自动切换。第二个经验是磁贴文本不要放版本信息比如不要写“V2.1”这种。版本号应该跟随应用自身的标题或描述去维护放进磁贴等于给自己埋了一个定时炸弹——发版时还要记得回来改磁贴漏掉一个就会产生多个版本并存的错觉。3. 分层治理目录、权限与站点各自守好边界3.1 用一张责任矩阵约住所有人我参与过的 Fiori 项目里最容易失控的阶段不是初始建设而是上线半年后的“持续变更期”。业务需求每天都在变今天加一个应用明天改一个分组后天又要调整磁贴顺序。如果没有治理规则Launchpad 会很快变成一个没人说得清的大杂烩。所以我给项目组推荐了一个分层治理模型四层各管一段层级责任人核心职责常见产出应用层应用开发负责人应用是否可发布、接口是否稳定应用发布清单内容层Fiori 内容管理员目录/组/目标的增删改、磁贴设计规范内容建模评审记录权限层安全顾问/业务角色负责人目录与角色的授权矩阵、访问审计角色说明文档站点层平台管理员站点 URL、主题、用户入口站点验收清单这张矩阵没什么高深技术但在实际项目中特别管用。为什么因为它把变更入口统一了一个业务需求要上线必须经过内容层管理员审核由他把需求翻译成“新增哪个目录、放到哪个组、配上哪个目标”再由权限层确认角色授权最后由站点层验证上线。任何一层缺失变更都会变成隐性问题。3.2 命名规范治理最便宜、最有效的切入点分层治理如果只能选一件事先做我一定选命名规范。命名规范不需要开会讨论很久只需要定几个简单规则然后强制执行目录名前缀 业务域 内容类型。比如Z_PUR_Fiori_AppsZ_QUM_Quality_Apps。组名直接表达用户任务。比如Z_GRP_Purchase_Approval、Z_GRP_Material_Analysis。目标名语义对象_动作_后缀。比如PurchaseRequisition_Approve_App。为什么要这样定三个原因第一是可检索半年之后你想找出“采购审批那个应用的配置”Z_PUR_*一过滤就全出来了第二是可审计传输清单里出现一批对象时命名规范能让你一眼判断哪些是正常变更、哪些是误操作的脏数据第三是可交接不管谁接手都能通过名字理解它的用途不需要拉人开半天会。还有一条我特别想强调的细节不要在名字里使用日期和临时标记比如Temp_20240101这种。你当时觉得是临时的过两个月就没人敢删因为怕影响线上。临时对象清理本身就是一个治理任务你应该在每次上线前专门过一遍临时对象清单而不是放任它们沉淀。3.3 权限与传输的分层配合权限这块要再展开一点。Fiori 的权限逻辑不是一个点而是一条链用户登录工作台 → 根据 PFCG 业务角色获得目录授权 → 目录里包含的目标被允许显示 → 应用被点击后后端 OData 服务再检查数据权限。这条链上任何一环断了用户都会说“我看不到应用”但真正的原因可能五花八门。我在实际排查中看到最多的三类问题是第一角色里加了目录但目录里没有目标用户看到空目录第二目标里配了应用地址但应用本身没有集成到前端服务器磁贴点进去 404第三目录和角色的分配做了但应用的后端 OData 服务没有放开登录后应用白屏。这三类问题的共同点就是每个人只负责了自己的那一层没有人从用户视角完整过一遍链路。传输的配合也是一个重点。内容层创建的目录、组、目标在 ABAP 环境下会作为资源对象进入系统传输管理正确的做法是把开发环境里的配置收集进传输请求经过 Quality 验证后再随标准流程传到生产。不是网上的教程那样“你在生产环境照着再配一遍”。环境一多手工重建必出错这条原则写进运维手册能省下无数故障工单。3.4 变更评审小需求也要走轻量流程分层治理之下哪怕是一个“加一个磁贴”的小需求我也建议走一个极简流程需求描述 → 内容管理员建模 → 开发确认应用可用 → 测试验证 → 传输生产 → 用户验收。这个流程不一定要开长会很多时候在同一个工单系统里就能完成但对于项目健康度来说极其重要。一旦允许绕过流程今天因为“就是加个链接”打破了规则明天有人会觉得改个标题也无所谓后天系统里就会出现一堆来路不明的对象。4. 配置过程中最常踩的五个坑4.1 磁贴标题和图标没有做“提示性设计”先说一个看起来很小但是影响高频使用体验的坑磁贴标题被截断。Launchpad 的磁贴在不同分辨率下是有宽度限制的如果标题太长系统会显示省略号用户得悬停才能看全。更麻烦的是有些应用的名字在业务部门内部叫“采购审批”在系统里叫“采购订单审批工作流”结果磁贴标题跟用户的实际语言习惯对不上。我的建议是做磁贴设计稿的时候至少看一眼 1366 和 1920 两种分辨率下的表现标题尽量短必要时用副标题补充图标最好选用业务语义明确的别用系统图标库里那些抽象的几何图形。你可以把这一项写进磁贴验收 checklist每次新增磁贴就自查一遍。4.2 用户刷新后看不到新磁贴先查三层再怪缓存这是运维群里出现频率最高的一个问题。用户说“你配了但我看不到”管理员第一反应往往是“清缓存”。但清缓存这个操作本质上掩盖了一整类问题。正确的排查链路是三层检查先查目录是否包含目标再查目录是否分配到角色最后查角色是否分配给用户和站点。如果三层都对了用户还是看不到才考虑浏览器缓存和工作台会话缓存的问题。这里有一点经验工作台的前端资源有缓存刷新周期新磁贴不能绝对做到“立等可见”。我一般会在更新说明里写上“如有遗漏请注销后重新登录”或“刷新浏览器页面”而不是直接让用户去清空缓存。引导用户养成“先退出重新登录再看终端是否生效”的习惯能过滤掉一大批假故障。4.3 跨应用导航失效语义对象对不上号Fiori 最有价值的能力之一是跨应用导航。比如从采购申请审批跳到采购订单详情、从物料主数据跳到库存报表。这个能力的底层依赖是语义对象和动作的精确匹配而不是 URL 拼接。很多自开发团队第一次做跨应用导航时习惯在磁贴里直接写跳转 URL这样短期能用但一旦应用收敛、入口改造就全断了。如果你要实现跨应用导航记住三个要点第一源场景和目标场景必须使用同一套语义对象与动作定义第二大小写敏感PurchaseRequisition和purchaserequisition会被当成两个不同的对象第三目标应用要能正确解析从 Launchpad 传入的导航参数参数名不一致界面跳过去了但数据是空的看起来比跳不过去更诡异。4.4 命名混乱半年之后没人敢动我在 3.2 节已经讲了命名规范的正面做法这里补一个真实的反面案例。有一个客户系统里目录列表长这样test1、NewFolder(2)、pur_apps_old、Pur 123、folder_newest。没人知道哪些在用、哪些已废弃最后不得不逐个盘点、导出日志比对花了整整一个迭代才清理完。这件事对团队的教训是命名规范必须从第一天就执行不要等“有空再整理”。整理一个混乱的 Launchpad比从零规划要慢得多。4.5 一个组里塞二十个磁贴最后是体验问题。有些业务方总觉得“组越少越好”于是把二十几个应用都塞进一个组美其名曰“都在一页方便”。但用户的真实操作是他登录后看到一屏挤满的磁贴视觉压力很大找目标的时间反而变长在移动端上更是灾难。我一般会建议一个组里的磁贴数量控制在 9 到 12 个以内。超过这个数量优先拆组按任务细化。与其让用户在长长的一页里找应用不如让他在两三个组之间轻松切换。5. 日常维护与内容演进把配置当成产品来养5.1 设计好的内容生命周期Fiori Launchpad 的内容不该是一次性工程上线之后它更像一个需要持续运营的产品。内容生命周期我建议按这四步来管理第一步需求进入。任何新增、修改、删除都从需求工单开始工单里写清楚业务背景、目标用户、影响范围。第二步内容评审。内容管理员负责评审“建在哪个目录、放哪个组、导航参数怎么传”这一步直接决定未来的可维护性。第三步测试验证。至少在一个单独的测试环境里用接近生产的角色和数据验证一遍。第四步传输发布。通过标准传输机制带入生产并在发布说明中记录变更内容。你会发现这套流程其实和软件开发里的小版本发布是一个思路。只不过很多人觉得 “只是个磁贴而已”就跳过了中间两步结果就是生产环境频繁出现肉眼可见的配置错误。5.2 用使用数据驱动清理和调整内容治理还有一个大家容易忽略的数据来源使用日志。Launchpad 入口和应用访问记录能告诉你哪些组真的被高频使用哪些目标几乎没被点过。我建议每季度做一次内容体检检查是否有目录分配给了角色但从未产生访问。检查是否有目标已经不存在了但磁贴还挂在组里。检查每个组的点击热度趋势低热度的组考虑合并或调整位置。检查命名规范是否被遵守有没有“漏网之鱼”悄悄混进来。这些检查不是要追求极端精简而是让 Launchpad 的内容结构与真实的业务活动保持一致。三个月前的需求今天可能已经没有意义了不及时清理下一次变更时它还会继续干扰判断。5.3 文档与交接清单配置不写下来等于没做最后一件事是文档。Launchpad Designer 里的配置点点鼠标就能完成但它背后的建模决策不写下来的话等于没有做。我见过太多项目上线后配置管理员离职新人面对几百个目录完全不敢动。所以请在项目一开始就维护一份《Fiori 内容配置手册》至少包含命名规范和对象清单目录、组、目标、磁贴的类型与用途。角色与目录的授权矩阵哪个角色能看到哪些目录定期核对。关键导航路径从哪个应用可以跳到哪个应用依赖哪些语义对象。变更记录每次变更的日期、内容、责任人、相关工单号。交接时不要只交接账号密码把这份手册连同一个季度体检报告一起交出去。新人看的不是“怎么配”而是“为什么这么配”——这才是 Launchpad Designer 背后真正值钱的部分。我后来再回访那个出问题的客户时发现他们最需要改进的并不是某个按钮的位置而是团队心里那张“边界图”。有人管开发、有人管内容、有人管权限、有人管站点大家知道彼此在整条链上的位置配置后的 Launchpad 自然就稳了。如果你所在的团队也正在被磁贴、目录、权限这些问题困扰建议先从一个小范围开始挑一个业务域做一次完整的建模、配好目录和组、写一篇简单的配置说明把这套流程走通再推广到全公司。工具人人都能学会真正拉开差距的是你用它的思路。