前阵子帮一个客户做 S/4HANA 升级需求列表里有一条很典型把老 NetWeaver Portal 上的 CHIP 组件搬进新的 Fiori Launchpad原话就是把CHIP加到Catalog里。单看这句话好像就是配置一下菜单的事真上手你会发现Catalog、Group、磁贴目标、发布状态、角色分配和缓存刷新一环扣一环少一步最终用户那边就是看不到。这篇文章我就把这条链路完整拆开从草稿 Catalog 到正式可用讲清楚每一步背后的原因和踩过的坑。1. 先想清楚CHIP在Fiori内容体系里的位置在动手配置之前我建议你先花十分钟想明白一个问题你要放进Catalog的CHIP在Fiori Launchpad里到底以什么身份存在这个想清楚了后面每一步配置都不容易跑偏。1.1 CHIP不是Fiori原生对象它从NetWeaver Portal来这里说的CHIP指的是SAP NetWeaver Portal时代提出的那套可复用Web Dynpro UI组件中文社区里有人叫它门户小部件它和前端框架里常见的chip标签不是一回事。CHIP注册在Portal Content DirectoryPCD里可以被拖到门户页面上支持参数化适合做成跨部门共用的信息块比如员工自助的三张报表、订单查询小窗之类。很多老客户在升级到S/4HANA或者转向Fiori Launchpad之后不想把这些现成组件丢掉于是就有了把CHIP加入Catalog这样的需求。但Fiori Launchpad的内容单位不是CHIP而是磁贴Tile。Fiori也没有一个叫CHIP的对象可以直接拖进去。所谓把CHIP加入Catalog本质上是在Fiori里给CHIP做一个入口封装让它能以磁贴的身份进目录最终通过启动板展示给用户。理解这一点非常重要因为后面所有操作其实都是在围绕入口封装做文章。1.2 挂载CHIP的三种常见形态根据CHIP的部署位置和能力常见有以下三种做法我列一张表供你快速判断形态实现方式优点局限URL磁贴在Catalog中直接创建一个URL磁贴粘贴CHIP的完整访问地址最快几分钟就能看到效果没有语义对象和动作的概念权限和导航上下文较弱Web Dynpro目标映射用LPD_CUST配置目标映射Fiori通过该映射打开CHIP底层的Web Dynpro应用符合Fiori对传统Web Dynpro组件的官方接入方式可配合导航规则和PFCG权限需要CHIP本身在ABAP服务器上可被Web Dynpro应用访问配置步骤多一点自开发封装Tile用SAPUI5/Fiori Elements写一个封装页面内嵌CHIP的URL或调用其接口可以加上现代UI的头、筛选器、异常处理开发和运维成本高不建议一上来就选从我们项目里的经验看如果CHIP是部署在ABAP后端的Web Dynpro应用优先走第二种如果CHIP只在Java Portal或其它站点上用URL磁贴最简单后续再考虑要不要封装。这里没有绝对标准关键是先判断CHIP本身能不能被目标环境直接访问到。2. Catalog的草稿与正式发布机制和真正决定可见性的因素Catalog建好了和Catalog正式可用了是两回事。很多实施顾问觉得在FLPCM里保存了就等于上线了结果用户端一直看不到最后排查半天发现就是没发布。2.1 从Draft到PublishedCatalog发布到底改变了什么在Fiori Launchpad Content ManagerFLPCM里新建一个Catalog时它默认是Draft状态。草稿状态下只有管理员或者能访问FLPCM的人能看到这个目录里的内容最终用户加载启动板时根本不会拿到它。你需要显式地点击发布把状态改成Published之后这个Catalog才进入运行时可见范围。这里有个特别容易踩的坑发布之后你再回去改Catalog哪怕只改了一个磁贴的图标状态也会重新回到Draft。很多项目上线后临时调整磁贴标题忘了重新发布结果用户那边看到的始终是旧版本。所以我在团队里立了一条规矩任何对Catalog的改动最后一步必须是发布。2.2 用户启动板上其实看不到CatalogGroup和角色的作用Catalog是内容的仓库按业务域把磁贴组织起来。用户在Fiori Launchpad上看到的其实是Group组不是一个一个Catalog。一个Group可以从多个Catalog里选取磁贴按用户日常使用习惯排列反过来某一个Catalog下的磁贴也可以根据业务需要出现在多个Group里。所以完整的链路是这样的Catalog负责承载和发布磁贴Group负责决定用户屏幕上出现哪些磁贴、以什么顺序出现角色PFCG或S/4HANA业务角色负责决定哪些用户拿到这个Group。Catalog、Group、角色缺一环最终用户都看不到你新加的CHIP入口。我见过不少项目把Catalog和Group混为一谈这是新手最容易卡住的地方。2.3 一个目录从草稿到正式可用的完整流转我平时给客户讲的时候喜欢把这套流程拆成下面八步你可以直接拿去做项目计划确认CHIP底层地址可用浏览器直接访问能正常打开在LPD_CUST中配置目标映射Web Dynpro/CHIP场景在FLPCM中创建Catalog此时是Draft把CHIP以磁贴形式加入Catalog保存发布Catalog状态变为Published创建Group把Catalog中的CHIP磁贴加入Group并发布把Group挂到角色菜单并给相关用户分配角色执行全局缓存失效用测试账号验证完整链路。这八步串起来就是标题里从草稿Catalog到正式可用的完整含义。后面几章我会把其中最容易出问题的步骤展开讲。3. 实操把CHIP封装成Tile并挂进Catalog这一节进入硬操作。我以On-Premise环境的FLPCM为例按实际点击顺序走一遍。Fiori版本不同按钮位置可能有差异但思路是通用的。3.1 前置条件目标映射LPD_CUST与ICF服务先打开事务代码LPD_CUST。这里有几种入口类型常用的是Transaction、Web Dynpro Application、URL。对CHIP这种底层是Web Dynpro的组件来说选中Web Dynpro Application维护Application名称以Z开头比如ZCHIP_TEST给它一个清晰的别名例如ZF_CHIP_TEST保存并激活。为什么要做这一步因为Fiori Launchpad在运行时需要知道这个磁贴点下去到底调用哪个目标LPD_CUST就是Web Dynpro应用与启动板之间的桥。如果CHIP只是一个普通URL那这一步可以跳过后面直接在Catalog里建URL磁贴就行。同时要确认ICF服务SICF树中对应Web Dynpro的路径是激活的否则最终用户点磁贴会得到404或401。这两个前置条件一起检查能让你后面少折腾。实测中很多磁贴打不开的问题最后查下来都是SICF服务没激活或者路径在测试环境能通、在生产环境没配好。3.2 在FLPCM中创建Catalog并添加CHIP Tile通过/n/UI2/FLPCM进入Fiori Launchpad Content Manager。选择Catalog相关入口新建一个Catalog。ID我建议按项目约定来比如ZCHIP_CATALOG_001标题写成业务能看懂的名称例如Portal旧组件迁移目录。新建完成之后点击添加磁贴/添加应用。如果你用的是LPD_CUST维护的目标映射在应用列表中按别名搜索到这个目标选中即可如果用的是URL方案就创建URL磁贴把CHIP的完整地址粘进去并配置标题、副标题和图标。这些元数据会直接显示在用户启动板上所以标题一定要通俗业务用户不关心底层是什么技术。保存之后Catalog还是Draft接下来点发布状态才会变为Published。请记住这一步发布的是Catalog不是Group两者都需要单独的发布动作。3.3 创建Group并发布让最终用户真正可见的关键一步Catalog发布完了但用户启动板还是不会出现。接下来要建Group。在FLPCM中新建一个Group比如ZCHIP_GROUP_001给它一个用户友好的名称。然后把刚加入Catalog的CHIP磁贴赋给这个Group。Group本身也有草稿和发布状态改完记得也要发布。再往后是角色授权。编辑角色时在菜单里选择添加SAP Fiori应用按目录或组去选择把这个Group引用进角色菜单然后在SU01中给目标用户分配该角色。如果用户的角色是通过业务角色管理的就在业务角色里维护对应的Fiori内容目录和组。这里我要特别强调Catalog和Group是两套对象不能混着用。我看到过不少新手把Catalog当Group结果磁贴怎么都到不了用户启动板因为Catalog本身并不会直接渲染到用户界面。3.4 批量场景通过内容导出导入复制目录配置如果是在质量系统调好配置再往生产搬可以优先用FLPCM自带的内容导出导入能力或者把Catalog、Group、目标映射放到CTS传输请求里。Fiori内容对象支持基于传输请求的传输这一点比手工在生产环境从头配一遍快得多。但有一个经验传输过去之后目录状态不一定是Published。我们在项目里吃过亏导入生产后Catalog仍是草稿状态用户看不到排查了一圈才发现是没在目标系统再次发布。所以批量迁移后依然要走一遍发布Catalog→发布Group→清缓存→测试账号验证的收尾动作不要以为导完就结束了。4. 发布后用户仍看不到磁贴完整排查链路这是整个主题里最值钱的部分。配置看起来全对用户就是看不到往往是这几种原因。4.1 内容状态还是权限问题先按下面顺序排查排查项检查方式常见原因Catalog状态FLPCM中打开Catalog看是否Published改过内容后回到DraftGroup状态FLPCM中确认Group已发布并包含磁贴只建Group没发布角色引用PFCG/业务角色中是否引用了该Group角色菜单没同步用户分配SU01中确认用户有该角色且角色激活分配后未保存或用户未重新登录启动板日志检查浏览器控制台和后端网关日志目标映射、服务不可用这个表我建议贴在项目群里。大多数看不到的问题走到第二步就能定位没那么玄。4.2 缓存导致的幽灵问题全局缓存失效怎么处理就算内容、权限全对用户端看到的仍可能是旧配置。Fiori Launchpad对Catalog和Group的配置是带缓存的尤其是上线初期老配置很容易在浏览器或服务器端被缓存住。服务端的处理办法是运行事务代码/UI2/INVALIDATE_GLOBAL_CACHES让所有用户的启动板配置缓存失效或者通过等效的管理员页面操作。执行完后用户下次刷新启动板时会重新拉取配置。要注意这个操作影响面大建议选非业务高峰做并提前通知用户强刷一下浏览器CtrlF5。4.3 一次状态全对但看不到的真实案例复盘说一个我实际遇到的案例。当时客户反馈某个CHIP磁贴看不到我检查了Catalog、Group、PFCG角色都是Published和已分配状态用户角色也正常理论上不应该有问题。后来在浏览器开发者工具里看启动板请求发现磁贴请求的目标URL在用户环境下返回401因为CHIP所在的Web服务路径对这个用户没有放行。调整权限后用户还是说看不到我让他强制刷新浏览器才真正恢复。这个案例给我的教训是配置层没问题时一定要往后端URL是否对所有目标用户可访问和前端浏览器缓存这两个方向延伸排查。前者通常是应用服务器授权问题后者往往就是一次强刷的事。排查顺序别搞反不然很容易在配置层面反复兜圈子。5. 从单目录到标准流程沉淀一套可复用的发布规范一次配置完成不算真正解决问题把流程固化下来后面维护十几个Catalog才会轻松。5.1 我总结的检查清单从草稿到正式可用我整理了一张核对清单每次上线前都会过一遍[ ] CHIP/Web Dynpro地址通过浏览器直接访问验证[ ] LPD_CUST目标映射已配置并激活如适用[ ] Catalog已创建CHIP磁贴已加入[ ] Catalog状态为Published[ ] Group已创建并发布包含CHIP磁贴[ ] 角色菜单已引用Group用户已分配[ ] 全局缓存已失效[ ] 使用独立测试账号验证登录→看到Group→点击磁贴→CHIP正常打开这张清单的优势在于把草稿到正式可用的每一步都变成可勾选的动作而不是凭感觉。凡是变更都走编辑草稿→测试确认→发布→全局缓存失效→通知关键用户验证这套动作固定下来团队成员之间交接也省事。5.2 面向混合技术栈的维护建议当目录里既有原生的SAPUI5应用又有Web Dynpro、CHIP这些旧组件时命名和分组非常影响维护效率。我建议Catalog按技术来源命名比如Z_CHIP_PORTAL、Z_WDA_LEGACY、Z_FIORI_NATIVE这样哪怕过了半年看到Catalog名称也知道里面是什么来头的。另外底层组件有版本变更时先改草稿Catalog在测试账号上验证确认无误再发布发布后立刻做全局缓存失效。遇到过很多次的问题都出在改完忘了重新发布。把发布做成变更必选步骤团队协作会省心很多。我在实际项目中一直坚持一个原则宁可让Catalog发布慢一点也不要让用户在启动板上看到一个点不开的磁贴。从草稿到正式可用的每一个环节都要以最终用户的视角去验证一遍。