第一次接触 SAP Fiori 的 Shell 扩展时，我其实走了不少弯路。当时业务方的需求很简单：希望在 Fiori Launchpad 顶栏右侧加一个自定义按钮，点开能跳转到企业内部的帮助系统。这种需求听起来不复杂，可当你真正打开 SAP 标准代码，准备在 SAPUI5 层面修改时，才发现升级兼容、多系统部署、权限控制全都变成问题。后来我调研了 SAP 官方提供的几种扩展方式，最终落在了 UI Plug-In 这个方案上——它不需要改标准前端代码，只需要在 ABAP 后端做一个 BSP 应用，然后通过角色激活来控制哪些用户能看到。整条链路从 Shell Header 的扩展点一直延伸到 PFCG 权限，跑通之后，效果非常理想。
这篇文章我就把从零开发 UI Plug-In、到最终通过角色激活让它在 Fiori Launchpad 上生效的完整过程记录下来。内容适合对 Fiori 架构有一定了解、但还没有深入做过 Shell 层扩展的 ABAP 开发顾问，也包括那些被业务需求追着要“在顶栏加个东西”的 Fiori 运维人员。文章里会包含原理分析、具体代码、配置路径，还有我在实际环境中踩过的坑和解决思路，希望能帮你少走点弯路。
1. 为什么要用 UI Plug-In：Fiori 扩展方案对比
1.1 Fiori 扩展的几个层级
SAP Fiori 的扩展方式其实可以按照影响的“层级”来划分。最底层是数据层面，比如在 OData 服务里做增强、写 BAdI 实现逻辑校验。往上一层是应用页面层面，可以改造 SAPUI5 应用的视图、控制器，或者用 ExtensionPoint 在标准页面里嵌入自定义块。再往上就是整个 Launchpad 的全局层面，也就是 Shell 层，UI Plug-In 就是在这个层级上工作的。
每个层级都有自己的适用场景。数据层面的扩展适合修改业务逻辑，但对界面表现无能为力。应用页面层面的扩展灵活度最高，能精准地改变某个 tile 对应的应用内部布局，但它的缺点是实施成本高，每次标准应用升级都要重新验证一次兼容性。而 Shell 层面的扩展则是一条“全局统一入口”的路子：无论用户此刻在哪个应用里，Shell Header 始终是稳定的，所以它非常适合放全局帮助入口、外部系统跳转、消息通知快捷键这类跨应用、跨功能的基础能力。
从项目管理和长期维护的角度看，Shell 层扩展还有一个隐藏优势：它不修改标准应用内部内容，所以升级风险相对可控。尤其是遇到 SAP 标准应用频繁打补丁、上 Enhancement Package 的场合，Shell 层独立于应用代码，可以减少回归测试范围。
1.2 UI Plug-In 的定位与原理
UI Plug-In 准确来说是一个基于 BSP（Business Server Pages）的扩展组件。Fiori Launchpad 在服务端生成页面时，会读取已经注册并分配给用户的插件列表，然后调用这些 BSP 应用来获取一段 HTML 片段，最终把片段嵌入到 Shell Header 指定的 DOM 区域。整个过程是在页面渲染阶段完成的，也就是说，用户打开 Launchpad 时，插件内容已经跟着 Shell 一起呈现了，不需要额外发 AJAX 请求。
这背后是有架构逻辑的：SAP Fiori Launchpad 虽然整体是 SAPUI5 应用，但它的首屏还是由后端统一渲染的。把 HTML 注入回调到后端做，既能复用系统现有的权限体系和用户上下文，又能避免在前端 JS 里硬编码服务地址和逻辑。对 ABAP 开发团队来说，这意味着不需要引入 Node.js 或者其他前端构建工具链，直接在 SE80 里就能完成开发、测试和部署。
从影响范围来看，UI Plug-In 一旦上线，它会出现在所有被分配了对应角色的用户的 Shell Header 上。这个全局属性既是优点也是风险：优点是全局入口统一、体验一致；风险是如果代码写得不够健壮，或者性能开销过大，会影响所有人的 Launchpad 加载速度。所以我在实际项目中，通常建议先拿一个小范围角色做灰度测试，确认无误后再扩大到批量用户。
2. 开发环境准备与 BSP 应用创建
2.1 检查后端环境和 SICF 服务
UI Plug-In 本质上依赖 BSP 运行环境，所以首先得确认你的后端系统具备基础条件。我这边开发用的版本是 S/4HANA 2020 和 NetWeaver 7.5，如果是比较老的 NetWeaver 7.40，建议确认一下系统是否安装了足够新的 BSP 组件，因为旧版本可能不支持接口 IF_BSP_EXTENSION 或者 FLP 集成的部分参数。
实际操作之前还有几个前置检查项，少一个后面都会出问题：
- 检查事务码 SICF 中
/sap/bc/bsp这个服务节点是否处于激活状态。这是 BSP 应用统一暴露的 HTTP 路径，插件最终要通过这个路径被外部请求。 - 确认你有 SE80 的开发权限，以及 SICF 服务维护权限。实际项目里权限这块常被忽略，实际测试时发现没有权限，临时去找 Basis 开权限，挺耽误时间的。
- 如果系统启用了 Web Dispatcher 或者负载均衡，还要确认
/sap/bc/bsp和/sap/bc/ui2/这些路径都被正确映射到了后端实例。我在一次测试中就遇到过 Web Dispatcher 把 /sap/bc/bsp 请求分发到了错误实例，导致插件内容时有时无。
这些都是基础环境项，虽然不起眼，但每一条都有可能变成“插件就是不显示”的罪魁祸首。建议开发开始前就把它们整理成清单，逐项核对，别等代码写完再去排查环境问题。
2.2 在 SE80 中创建 UI Plugin 类型的 BSP 应用
在 SE80 里创建 BSP 应用时，正常情况下可以选择应用类型。如果你的系统支持 UI Plugin 类型，流程会非常顺畅。操作路径是：打开 SE80，在下拉框里选择 BSP 应用，点击创建，输入应用名称和描述。接着在应用属性的下拉框里，把 Application Type 设置为 UI Plugin。这里的名称我建议用 Z 开头，并且带上项目上下文，比如ZFLP_PLUGIN_HELP，这样后续维护时一眼就能认出是哪个项目、什么用途。
设置好类型后保存并激活，系统会为这个应用生成一个控制器类。这个类是后续要写代码的核心位置。如果你用的版本没有这个下拉选项，也不要慌，可以手动创建一个普通 BSP 应用，然后在控制器类里自行实现后续要用的这个扩展接口。本质上 UI Plug-In 的入口约束就是控制器类要满足 FLP 集成的接口契约，用哪种方式创建只是走的路径不同而已。
创建完成后，通常会看到 BSP 应用下有几个节点：页面（Pages）、控制器（Controllers）、MIME 对象、视图等。UI 插件一般不需要写页面和视图文件，内容输出都在控制器类的方法里完成。所以即使其他节点是空的，也不用担心。
2.3 生成控制器类的关键节点
打开应用对应的控制器类，通常会看到一个基于接口 IF_BSP_EXTENSION 的类定义。这个接口定义了几个生命周期回调方法，核心是 DO_INIT、DO_REQUEST、DO_RESPONSE。其中 DO_REQUEST 是我们要聚焦的地方，FLP 渲染 Shell 时就是从这个方法拿输出内容。
我自己的理解是，这几个方法类似于 BSP 页面处理器里的生命周期钩子。DO_INIT 可以用来做一些只执行一次的初始化逻辑，比如从配置表读取参数；DO_REQUEST 是主体，负责拼装 HTML 片段；DO_RESPONSE 可用于收尾。实际开发里，大多数场景只需要实现 DO_REQUEST，其他方法保持空实现即可。
类定义大致长这样：
CLASS zcl_flp_plugin_help DEFINITION PUBLIC FINAL CREATE PUBLIC. PUBLIC SECTION. INTERFACES if_bsp_extension. ENDCLASS.请注意，类定义用了 FINAL，这是因为插件类本身没有继续被继承的需求。实际项目里保持简单的继承层级，也能避免后续被其他人误继承后产生逻辑混乱。
3. 在 Shell Header 注入内容：核心代码与实现
3.1 理解 Shell Header 的渲染时机
Shell Header 是 Fiori Launchpad 里常驻的那一条顶部区域，默认包含 Home 按钮、当前用户信息、搜索框、帮助入口等元素。无论用户从哪个 tile 进入应用，这条 Header 都稳稳地处于页面顶部。正是因为它的常驻特性，UI Plug-In 的内容才能做到全局可触及。
它在页面生命周期里的渲染节点很靠前：Fiori Launchpad 的后端页面生成器根据当前用户的角色和登录上下文，计算出需要加载的插件集合，然后逐一调用对应 BSP 应用的控制器，拿到返回的 HTML 片段，再把它插入到 Shell 布局的指定区域。这就意味着，插件的输出不能依赖任何页面级的 JavaScript 变量或 DOM 节点，因为它的内容被插入时，SAPUI5 应用可能还没有完成初始化。
所以我在编码时会特别强调一点：插件输出的 HTML 片段必须是自包含的。需要样式就内联 style，需要交互就自带脚本，不要寄希望于外部 CSS 文件能够命中插件里的类名，也不要在 HTML 里直接去操作 Shell 的 DOM 结构，因为这样很容易造成版本兼容问题。
3.2 覆写 DO_REQUEST 输出 HTML 片段
DO_REQUEST 方法是插件输出的主战场。我这里用一个最基础的例子来演示，怎么在 Shell Header 的右侧区域输出一段自定义内容。
CLASS zcl_flp_plugin_help IMPLEMENTATION. METHOD if_bsp_extension~do_request. DATA(lv_html) = `<div style="display:inline-block;margin-right:16px;font-size:14px;">` && `<a href="https://help.example.com/" target="_blank" ` && `style="color:#ffffff;text-decoration:none;">内部帮助中心</a>` && `</div>`. runtime->server->response->set_cdata( lv_html ). ENDMETHOD. ENDCLASS.代码本身很简单，就是把一段带内联样式的超链接 HTML 写到了 HTTP 响应里。FLP 拿到这段响应内容后，会把它作为插件内容呈现在 Shell Header 上。这里有几个细节值得留意：
set_cdata是直接把字符串写入响应体，所以你不能在这里再写一个完整的 HTML 页面结构，否则会破坏 Shell 的 DOM。- 样式一定要用内联方式写。第一次开发时我用的是自定义 CSS 类名，结果浏览器里样式始终不生效，检查后发现 Shell 的 CSS 作用域隔离把插件内容隔离开了，后来全部改成内联样式才搞定。
- 输出内容不要带
<html>、<body>这类标签，那属于页面级标签，插入到现有页面里会导致浏览器解析异常。
写完之后先不要急着做 FLP 配置，可以直接在浏览器里访问这个 BSP 应用的 URL，路径一般是/sap/bc/bsp/sap/zflp_plugin_help。如果能看到刚才写的那段内容，说明 BSP 应用本身工作正常，问题如果后面出现，大概率出在集成环节。
3.3 进阶：调用后端数据与跳转处理
上面的例子只是一个静态链接，实际业务里，我们往往需要让插件显示一些动态内容，甚至要结合用户身份做差异化展示。这里分享两个我实际用过的扩展点。
第一个是获取当前登录用户并通过权限字段动态拼装菜单。比如企业内部有多个系统入口，不同角色的人看到的内容不一样，就可以这样实现：
METHOD if_bsp_extension~do_request. DATA(lv_user) = sy-uname. DATA(lv_menu) = `<span>当前用户：` && lv_user && `</span>`. AUTHORITY-CHECK OBJECT 'S_TCODE' ID 'TCD' FIELD 'ZHELP_MENU'. IF sy-subrc = 0. lv_menu = lv_menu && `<a href="sap/vnd/help://special" style="margin-left:8px;">高级帮助</a>`. ENDIF. runtime->server->response->set_cdata( lv_menu ). ENDMETHOD.这种方式巧妙地利用了系统原有的权限校验体系，把“能看到什么插件内容”和“用户拥有什么权限”绑定在一起。不需要额外开发一套角色灰度逻辑，而是直接复用 PFCG 的权限对象。
第二个常见的需求是显示后端业务数据，比如待审批单据数量。这种场景下，插件里可以直接调用函数模块或查询数据库，但要注意性能问题。Shell Header 每次刷新都会执行插件逻辑，如果里面做太重的查询，整个 Launchpad 都会变慢。我的经验是：优先考虑把数量信息放在用户默认加载的模型里，或者用轻量级缓存，在函数模块结果的缓存周期内取数，不要每次都去数据库扫表。
4. 发布配置与角色激活：让插件真正生效
4.1 激活 BSP 应用与 SICF 服务
代码写好后，先回到 SE80 把 BSP 应用激活。激活操作和普通程序一样，点击激活按钮即可，这一步会确保新增的类和修改的代码以最新状态进入运行环境。
接着是 SICF 服务激活。在事务码 SICF 里找到/sap/bc/bsp/sap/zflp_plugin_help这个节点，如果之前创建 BSP 应用时自动生成了，就检查它的状态；如果没有，就需要手动创建对应的服务节点。右键节点选择“激活服务”，然后系统会提示输入服务名称、描述信息。激活完成后，可以再用浏览器直接访问一次插件 URL，确认 HTTP 200 正常。
这一步看似简单，其实很容易踩到“服务路径大小写”“前端系统缺少对应后端系统路由”这类环境坑。我曾经在一个 Hub 部署架构里，前端 Fiori 系统和后端 ECC 系统分离，结果插件 BSP 应用建在了后端系统，但 FLP 在前端系统，导致 FLP 调用插件时总是 404。解决方案是确认前端系统的 SICF 服务路径配置和跨系统调用逻辑是否一致，必要时需要把 BSP 应用也部署到前端系统。
4.2 在 FLP Shell 配置中注册插件
BSP 应用自己运行正常是一回事，Fiori Launchpad 不认识它又是另一回事。要让 Launchpad 主动去加载这个插件，还需要在 FLP 配置里把它注册进去。我使用的路径是事务码/UI2/FLP_CUST，进去后找到“Shell 设置”或者“UI 插件”相关的配置页签，在这里添加刚才创建的 BSP 应用名称。
这里提醒一点，不同版本系统的菜单标签可能不太一样。S/4HANA 2020 版本通常可以在 Launchpad Designer 或者 Fiori Launchpad 配置工具里处理；旧一点的 NetWeaver 7.4 系统则需要使用/UI2/FLP_CUST里的“系统配置”或“用户配置”去维护。注册时如果系统提示输入插件 ID，一般填 BSP 应用名即可。
注册成功并保存后，插件就会出现在系统的插件列表里。但它还没有面向真实用户生效，因为目前它只是“系统已录入”，并没有“用户已授权”。这就要进入整个流程中最关键的一步：角色激活。
4.3 PFCG 角色分配与激活流程
UI Plug-In 要最终显示在某个用户的 Shell 上，需要给它挂上角色这个“分发渠道”。具体操作是在事务码 PFCG 里，创建或修改一个业务角色，然后把插件的服务地址或者 BSP 应用名称加入到角色菜单中。
这里我以创建角色ZFLP_HELP_USER为例。进入 PFCG，点击新建角色，填入角色名称和描述。在“菜单”页签里，可以选择“添加事务”或“添加 BSP 应用”，把插件对应的 BSP 应用加到角色菜单中。保存后，把这个角色分配给实际需要查看插件的用户。最后也是最重要的一步，回到 PFCG 角色维护界面，点击“激活”按钮，让系统生成对应的授权参数文件。
激活这一步决定生死，但我发现很多新手都容易把它漏掉。角色虽然创建了、用户也分配了，但只要没点激活按钮，权限参数就不会真正生效。激活后，再用测试用户登录 FLP，刷新页面，这时候 Shell Header 上才会出现插件内容。
如果你需要控制不同用户看到不同插件内容，建议在 PFCG 里准备多个角色模板，比如管理员角色能看到“管理后台”入口或审计信息，普通用户只看到“在线帮助”链接。这样既实现了功能扩展，又兼顾了安全边界。
5. 常见问题与排查技巧
5.1 插件未显示：先别改代码，查缓存
插件开发完成并完成角色激活后，如果你用测试账号登录发现插件没有如期出现，会很怀疑代码是否有问题。但按照我的经验，至少有一半概率不是代码的问题，而是缓存。
Fiori Launchpad 有多个缓存层：后端缓存、前端缓存、浏览器缓存。修改插件代码后，SAP 的服务端可能会缓存旧的 BSP 内容；用户在浏览器端可能也还保留着旧页面的 DOM。建议按这个顺序排查：
- 用户是否重新登录了 Launchpad？Shell 内容在用户会话建立时生成，单纯刷新页面不一定能触发重新获取插件内容。
- 是否清除了 Fiori 相关缓存？可以在 SE38 里运行
/UI2/INVALIDATE_GLOBAL_CACHES清理全局缓存，也可以使用事务码/UI2/DELETE_CACHE清除 Launchpad 客户端缓存。 - 浏览器缓存是否清理干净？这一步可以用浏览器无痕模式验证，排除了浏览器缓存因素再判断代码问题。
如果做完这些还是没显示，再回头检查 PFCG 角色是否激活成功，以及用户是否真的存在这个授权信息。这些环节之间的逻辑是环环相扣的，哪个断了都会导致不显示。
5.2 权限不足导致的加载失败
权限问题往往是隐蔽而容易被忽视的。我在一次实际配置中就遇到过：插件功能开发完成，测试用户也有对应的 PFCG 角色，但打开 Launchpad 后，插件区域一直空着。通过浏览器开发者工具查看网络请求，发现调用插件 BSP 的 HTTP 请求返回了 403。
这个 403 就是典型的权限不足。排查思路是：
- 检查用户是否有访问 BSP 应用对应 HTTP 服务的权限。SICF 服务节点上有“服务授权”的配置，必须使用 SICF 里的服务数据，或为服务指定权限对象。
- 检查 PFCG 角色里是否真正包含了插件的授权数据，而不仅仅是添加了角色菜单。
- 如果系统里有多个客户端或逻辑系统，确认插件部署和用户登录的客户端一致。
这类问题比较耗费时间，关键排查技巧就是“分边走”：先测匿名访问插件 URL，再测带授权用户访问，通过对比 HTTP 状态码，能快速定位是服务端问题还是权限配置问题。
5.3 前端代码与 UI 插件的选择建议
在做 Fiori 全局扩展时，不少顾问会纠结到底用 SAPUI5 前端扩展还是 UI Plug-In 后端方案。这里我给你一个选择建议框架，也是我自己在实际项目中总结出来的。
如果你的需求只针对某一个具体的 Fiori 应用页面，比如“在该采购申请审批界面加一个按钮”，那么优先选择 SAPUI5 扩展点或者应用控制器扩展，因为这样能精确控制页面内部。但如果需求是“每个用户打开 Launchpad 都能看到顶栏上的统一帮助菜单”，那 UI Plug-In 明显更合适，因为它天然的全局角色控制机制，让扩展范围和发布范围都能通过权限体系管理。
从维护成本来说，UI Plug-In 也有优势。它不依赖前端构建工具链，上线时只要在 ABAP 系统里激活、配置角色即可。而 SAPUI5 扩展往往需要维护 JS 文件、构建压缩、部署到前端运维，后期标准应用升级时，还要重点回归页面扩展部分。相比之下，UI Plug-In 隔离在 Shell 层，升级影响范围要小很多。
不过也不是说 UI Plug-In 可以完全替代前端扩展。遇到需要深度定制 Shell 组件动画或交互效果的需求，还是需要回到 SAPUI5 的扩展机制。两种方案更像是互补关系，选择时从“影响范围”和“维护成本”两个维度去权衡即可。
最后一点实操体会
整个 UI Plug-In 从开发到角色激活，链路看起来不算长，真正做的时候却最容易在各种“小细节”上卡住。我自己最大的体会是：一定要先把“用户最终看到的 Shell 内容”还原成代码路径和配置路径两条线，然后用排除法逐段验证。遇到插件不显示，先验证 BSP 应用 URL 是否能直接访问，再检查 SICF 激活状态，然后是 FLP 注册信息，最后顺着 PFCG 角色激活一点一点排查，而不是一上来就改代码。
最后再分享一个小技巧：在插件开发的初期，可以先在 DO_REQUEST 方法里固定输出一段带明显颜色和边界的测试 HTML，比如一个红色边框的 div，这样在 Shell 上会非常醒目。确认插件机制打通后，再改成实际的业务内容。这个办法能帮你快速区分“插件机制没生效”和“页面样式没生效”这两类问题，省掉大量调试时间。
