1. 从用户界面到业务入口Fiori Launchpad的核心价值如果你接触过SAP Fiori那么Launchpad启动板绝对是你绕不开的第一个界面。很多刚入门的朋友可能会把它简单地理解成一个“应用菜单”或者“门户首页”这种看法其实只对了一半。在我过去十多年的项目实施经验里Launchpad的定位远不止于此它本质上是企业数字化工作台的统一入口和业务情境的调度中心。想象一下你每天上班打开电脑需要一个界面来聚合你所有的工作待办、常用应用、关键数据和通知并且这个界面能根据你的角色比如财务专员、销售经理、采购员自动呈现最相关的内容这就是Fiori Launchpad要解决的核心问题。它解决的痛点非常明确在传统的ERP或复杂业务系统中用户往往需要记住冗长的事务代码T-Code在不同的系统客户端和浏览器标签页之间反复切换操作路径深且效率低下。Launchpad通过基于角色的、磁贴化的直观界面将分散的业务流程和事务聚合到一个统一的、响应式的Web界面上。用户不再需要关心后台是S/4HANA、ECC还是SuccessFactors他们只需要关注自己的“工作台”上有什么任务需要完成。因此无论是业务用户、关键用户还是开发顾问深入理解Launchpad的配置与运作机制都是构建高效、用户友好的Fiori体验的基石。2. Launchpad架构与核心组件拆解要玩转Launchpad的配置不能只停留在点击按钮的层面必须对其背后的架构和核心组件有一个清晰的认知。这就像装修房子你得先知道承重墙、水管和电路在哪里才能进行有效的设计和改造。2.1 三层结构模型前端、网关与后端一个完整的Fiori Launchpad体验通常涉及三个逻辑层理解它们之间的协作关系是进行一切配置和问题排查的基础。前端层Frontend即用户直接与之交互的浏览器界面。它主要由SAPUI5框架渲染负责呈现磁贴、目录、组等视觉元素并处理用户的操作事件点击、搜索等。这一层是静态的其内容和布局信息需要从后端动态获取。SAP Fiori前端服务器层Frontend Server 常与ABAP环境集成这是Launchpad的“大脑”和“配置中心”。在ABAP栈的Fiori部署中例如基于NetWeaver的Fiori Frontend Server或S/4HANA嵌入式Fiori这一层运行着关键的Launchpad服务。它存储并管理着所有的配置元数据包括Catalogs目录所有可用应用的集合池。可以理解为应用商店的“总仓库”。Groups组分配给特定用户或角色的应用集合。这是用户最终在Launchpad首页上看到的一个个“文件夹”或区域。Target Mappings目标映射定义了磁贴Tile或链接Link点击后具体导航到哪个后端业务应用例如一个SAP GUI事务、一个Web Dynpro应用或一个Fiori App的规则。它包含了应用的技术URL、语义对象Semantic Object和动作Action等信息。后端业务套件层Backend即提供实际业务数据和逻辑的SAP系统如S/4HANA、ECC、CRM等。Launchpad本身不处理业务数据它通过OData服务、RFC或直接URL调用等方式与后端通信。当用户点击一个磁贴时Launchpad会根据目标映射的配置向对应的后端系统发起请求并打开相应的应用。注意在纯粹的SAP Cloud Platform现称BTPFiori环境中Launchpad服务托管在BTP上其配置工具和架构与ABAP环境有所不同例如使用SAP Build Work Zone但核心概念目录、组、角色是相通的。本文主要聚焦于基于ABAP环境的Fiori Launchpad配置这是目前大多数On-Premise或私有云部署的常见场景。2.2 核心配置对象详解在Launchpad的配置世界里有几个核心对象你必须像熟悉自己的工具一样熟悉它们。它们之间具有清晰的包含和分配关系。磁贴TileLaunchpad界面上最小的可视化单元代表一个应用的入口。它通常包含图标、标题、副标题有时还有动态数字例如待审批单据数量。磁贴分为静态磁贴和动态磁贴。静态磁贴就是固定的链接动态磁贴则能通过OData服务实时获取并显示后端数据例如“我的待办事项12”。目标映射Target Mapping这是连接前端磁贴和后端应用的“桥梁”或“路由规则”。它不是一个用户直接可见的UI元素而是一个后台配置项。一个目标映射定义了semantic_object语义对象如“PurchaseOrder”代表业务对象类型。semantic_action语义动作如“display”或“create”代表要对这个对象执行的操作。url实际的应用启动URL通常是一个指向特定Fiori App或传统事务的链接。 当用户点击一个磁贴时Launchpad引擎会查找与这个磁贴关联的目标映射然后根据映射的URL导航到应用。目录Catalog一个逻辑上的容器用于归类和管理所有可分配的应用通过目标映射表示。例如你可以创建一个“财务专用目录”里面包含所有财务相关的应用目标映射。目录通常与业务领域相关但目录本身不会直接显示给最终用户。它是管理员用来管理应用池的工具。组Group这才是最终用户能在其Launchpad首页上看到的容器。一个组包含一系列磁贴并以一个标签如“我的财务”、“采购工作台”展示。管理员通过将目录中的目标映射应用分配到一个或多个组来为不同角色的用户定制他们的首页内容。角色RoleSAP中的权限控制单元。Launchpad内容的分配最终是与PFCG角色绑定的。通过事务代码PFCG你可以将特定的目录和组分配给一个角色。当用户被分配了这个角色后其Launchpad就会自动显示该角色所关联的组和目录中的应用。它们的关系链可以简化为创建目标映射应用 → 将目标映射放入目录 → 将目录中的目标映射以磁贴形式添加到组 → 将目录和组分配给角色 → 将角色分配给用户。这个链条是Launchpad配置的黄金法则。3. 实战从零开始配置一个Fiori Launchpad应用理论说得再多不如动手操作一遍。下面我将以一个常见的场景为例为采购员配置一个能够快速查看采购订单Purchase Order的Fiori应用磁贴。我们假设后端是S/4HANA前端Fiori Launchpad环境已就绪。3.1 第一步确定后端应用与语义对象首先我们需要知道用哪个Fiori App来“查看采购订单”。在S/4HANA中有一个标准的Fiori App叫做“Manage Purchase Orders”应用ID:Fiori2_F1730。其标准的语义对象和动作是语义对象Semantic Object:PurchaseOrder语义动作Semantic Action:manage你可以通过SAP的官方应用库Fiori Apps Library或在后端系统通过事务码/UI2/FLP查看已部署的应用及其语义信息。这一步至关重要因为目标映射的配置必须与后端应用声明的语义对象和动作严格匹配否则导航会失败。3.2 第二步创建目标映射Target Mapping这是最核心的配置步骤。我们通过事务码LPD_CUSTLaunchpad定制来操作。进入LPD_CUST选择“目标映射”视图。点击“创建”按钮。填写关键字段目标映射ID定义一个唯一的技术ID如ZM_PO_MANAGE。语义对象填入PurchaseOrder。语义动作填入manage。URL类型选择“事务”如果对应传统GUI事务或“URL”。对于标准Fiori App通常系统已经预置了配置你可能只需要“采用”Adopt一个现有的映射。如果是自定义应用则需要手动构造URL。标准Fiori App的URL模式通常类似于/sap/bc/ui5_ui5/sap/ypo_manage/index.html。URL如果手动输入需要完整的路径。更推荐使用“采用”功能从系统已注册的应用列表中选择。标题文本定义磁贴上显示的名称如“管理采购订单”。副标题文本可选如“查看与处理采购订单”。图标从SAP图标库中选择一个例如/SAP/ICONS/PO。保存并激活这个目标映射。实操心得在配置URL时一个常见的坑是忽略了跨客户端导航Cross-Client Navigation的需求。如果你的Fiori Launchpad服务器和后端业务系统是分开的分布式部署那么URL中可能需要包含系统别名System Alias信息。这时URL可能会以sap/bc/ui2/flp开头并附带sap-client和sap-system等参数。务必根据你的系统架构参考SAP Note或部署指南来配置正确的URL格式。3.3 第三步创建目录Catalog并添加应用接下来我们需要一个“采购应用目录”来收纳这个目标映射。在LPD_CUST中切换到“目录”视图。点击“创建”输入目录ID如Z_PURCHASING_CATALOG和描述。进入目录的详细配置页面在“目标映射分配”子标签页下点击“添加”。在弹出的搜索框中找到你刚才创建的目标映射ZM_PO_MANAGE并将其添加到目录中。保存并激活目录。你可以把多个相关的应用目标映射都加到这个目录里比如创建采购申请、监控供应商等应用。3.4 第四步创建组Group并设计布局目录是仓库组才是用户的桌面。现在我们来创建一个“采购工作台”组。在LPD_CUST中切换到“组”视图。点击“创建”输入组ID如Z_PURCHASING_WORKCENTER和描述。进入组的详细配置页面在“磁贴分配”子标签页下点击“添加”。系统会列出所有已分配给当前登录用户角色的目录中的目标映射。因为我们还没进行角色分配这里可能看不到。我们可以通过“手动添加磁贴”的方式直接搜索并添加ZM_PO_MANAGE这个目标映射。添加后它就成为了组里的一个磁贴。布局设计你可以在“组编辑器”中拖动磁贴来调整它们在页面上的位置。你还可以创建多个“行”或“区域”来分组磁贴使页面更整洁。例如你可以将“查询类”应用放在一行“创建类”应用放在另一行。3.5 第五步通过角色Role进行权限分配最后也是最关键的一步将目录和组与权限角色绑定。打开事务码PFCG创建一个新的角色或编辑一个现有的采购员角色如Z_PURCHASER。进入“菜单”标签页。这里就是为角色分配Launchpad内容的地方。点击“添加其他对象”在对象类型中选择“SAP Fiori”。系统会打开Fiori内容分配界面。在这里你可以在“目录”标签下搜索并分配你创建的目录Z_PURCHASING_CATALOG。这赋予了角色“可以看到这些应用”的权限。在“组”标签下搜索并分配你创建的组Z_PURCHASING_WORKCENTER。这决定了用户的Launchpad首页具体显示哪些磁贴以及如何布局。保存角色并执行“角色权限概览”生成权限参数文件。最后在PFCG的“用户”标签页将这个角色分配给相应的采购用户。完成以上步骤后当采购员登录Fiori Launchpad时其首页就会出现“采购工作台”组里面包含“管理采购订单”的磁贴点击即可直接跳转到对应的Fiori应用。4. 高级配置与个性化功能探索基础的磁贴配置只是开始要让Launchpad真正强大和贴心还需要掌握一些高级配置和个性化功能。4.1 动态磁贴与实时数据静态磁贴只是一个入口而动态磁贴能直接传递信息。最常见的动态磁贴是“数字磁贴”它通过一个OData服务定期轮询后端数据并将数量显示在磁贴右上角例如“我的审批5”。配置动态磁贴的关键在于目标映射的“可视化”设置在创建或编辑目标映射时找到“可视化”相关字段。指定一个“信息源”OData Service。这个服务需要返回特定的数据结构通常包含一个number字段。设置刷新间隔如每5分钟。在磁贴模板中选择支持数字显示的模板例如“数字磁贴”。注意事项动态磁贴的OData服务需要精心设计和优化避免频繁调用对后端系统造成性能压力。同时要确保该服务包含必要的权限检查用户只能看到自己有权限访问的数据计数。4.2 搜索与语义对象集成Fiori Launchpad的全局搜索功能非常强大。用户不仅可以通过应用名称搜索还可以直接搜索业务数据如采购订单号“4500001234”。这得益于语义对象的集成。要使你的应用支持这种深度搜索需要确保目标映射正确配置了语义对象和动作我们在第一步就做了。在后端应用Fiori App中实现相应的manifest.json配置和搜索模型Search Model告诉Launchpad搜索时应该调用哪个OData服务的哪个实体集EntitySet来查找数据。在Launchpad设计器中可以配置搜索连接器Search Connector将语义对象与特定的后端搜索服务关联起来。当这些配置完成后用户在Launchpad搜索框输入一个采购订单号搜索结果中不仅会出现“管理采购订单”这个应用还可能直接出现一条指向该订单详细信息的链接实现一键直达。4.3 用户个性化与页面变式除了管理员集中配置Launchpad也支持最终用户进行一定程度的个性化这大大提升了用户体验。个性化编辑模式用户点击Launchpad右上角的“编辑”按钮可以进入编辑模式。在此模式下他们可以在已分配的组内自由拖动磁贴调整位置。将常用磁贴固定在主页即使它属于一个需要滚动才能看到的组。从已分配目录中将其他应用磁贴添加到现有组或创建新的个人组。隐藏不需要的磁贴。页面变式Page Variants对于关键用户或特定团队管理员可以创建不同的页面布局变式。例如为“采购经理”和“采购专员”创建两个不同的组布局变式然后通过业务角色分配不同的变式。这比维护完全不同的两个角色和组要灵活得多。这些个性化设置会保存在用户个人配置中不会影响其他用户。管理员在LPD_CUST中可以通过“传输个性化设置”功能将某个用户的优秀布局作为模板推广给其他同角色用户。5. 常见问题排查与配置优化实录在实际配置和运维中你肯定会遇到各种问题。下面我整理了几个最典型的问题和排查思路这些都是用时间和教训换来的经验。5.1 问题一磁贴点击后报错“无法启动应用程序”这是最常见的问题。请按照以下链条顺序排查检查目标映射的URL这是首要怀疑对象。直接在浏览器新标签页中粘贴目标映射里配置的完整URL看是否能独立打开应用。如果打不开说明URL本身错误可能是路径不对、系统别名错误或缺少参数。检查语义对象/动作确保目标映射中配置的语义对象和动作与Fiori应用manifest.json文件中sap.app章节下定义的crossNavigation配置完全一致包括大小写。检查后端系统可达性对于分布式部署确保Fiori前端服务器能通过网络访问到后端业务系统并且相关的逻辑端口是开放的。使用事务码SM59测试RFC连接或直接在服务器上用浏览器测试后端服务的URL。检查用户权限确保测试用户不仅拥有Launchpad前端角色还在后端业务系统拥有执行该事务或访问该OData服务所需的权限。可以尝试用SU01将用户与SAP_ALL这类全权限临时关联测试以排除权限问题。检查应用状态通过事务码/UI2/FLP检查该Fiori应用是否已正确部署并处于激活状态。5.2 问题二用户登录后看不到预期的磁贴或组这通常是角色分配或缓存问题。确认角色分配在PFCG中双重检查目录和组是否已正确添加到角色中并且角色已分配给用户。记得在PFCG中保存并生成权限参数文件。检查用户菜单以该用户登录GUI执行事务码SU01查看“菜单”标签页确认Fiori内容目录和组是否出现在其个人菜单中。如果没有可能是角色未正确传输。清除前端缓存Launchpad前端有缓存机制。指导用户按下ShiftCtrlAltS在打开的“技术支持”弹窗中点击“删除本地数据”清除浏览器缓存。或者在前端服务器运行事务码/UI2/INVALIDATE_CLIENT_CACHE输入客户端号来清除服务器端缓存。检查组是否为空在LPD_CUST中检查该组确保里面已经添加了磁贴。一个没有分配任何磁贴的组即使分配给用户也不会显示。5.3 问题三动态磁贴不显示数字或显示错误检查OData服务首先在浏览器中直接调用动态磁贴配置的OData服务URL看是否能返回正确的JSON数据并且数据结构符合预期通常根节点下有一个value数组里面包含number等字段。检查服务权限确保当前用户有权限调用这个OData服务。可以使用工具如Postman带上用户的登录凭证测试服务。检查刷新配置在目标映射配置中确认“信息刷新间隔”设置合理且已保存。间隔太短可能被服务器限流太长则数据更新不及时。查看浏览器控制台按F12打开开发者工具查看网络Network选项卡和控制器Console选项卡寻找加载磁贴信息时的错误请求或JavaScript错误。5.4 配置优化建议分组与命名规范为目录、组、目标映射建立清晰的技术命名规范和业务描述。例如目录ID以ZCAT_开头组ID以ZGRP_开头目标映射以ZM_开头。业务描述要能让其他管理员一眼看懂。利用传输请求所有的LPD_CUST配置都应该在某个开发/定制客户端进行并通过传输请求Transport Request移动到测试和生产系统。绝对避免在生产系统直接修改。在传输后记得在生产系统激活相关配置对象。性能考量一个用户的Launchpad首页不宜加载过多动态磁贴每个磁贴的OData调用都会增加页面加载时间。对于非关键信息考虑使用静态磁贴或延长刷新间隔。定期审计与清理随着业务变化定期回顾不再使用的目录、组和目标映射并将其标记为不活跃或删除以保持配置环境的清晰。
1. 从用户界面到业务入口Fiori Launchpad的核心价值如果你接触过SAP Fiori那么Launchpad启动板绝对是你绕不开的第一个界面。很多刚入门的朋友可能会把它简单地理解成一个“应用菜单”或者“门户首页”这种看法其实只对了一半。在我过去十多年的项目实施经验里Launchpad的定位远不止于此它本质上是企业数字化工作台的统一入口和业务情境的调度中心。想象一下你每天上班打开电脑需要一个界面来聚合你所有的工作待办、常用应用、关键数据和通知并且这个界面能根据你的角色比如财务专员、销售经理、采购员自动呈现最相关的内容这就是Fiori Launchpad要解决的核心问题。它解决的痛点非常明确在传统的ERP或复杂业务系统中用户往往需要记住冗长的事务代码T-Code在不同的系统客户端和浏览器标签页之间反复切换操作路径深且效率低下。Launchpad通过基于角色的、磁贴化的直观界面将分散的业务流程和事务聚合到一个统一的、响应式的Web界面上。用户不再需要关心后台是S/4HANA、ECC还是SuccessFactors他们只需要关注自己的“工作台”上有什么任务需要完成。因此无论是业务用户、关键用户还是开发顾问深入理解Launchpad的配置与运作机制都是构建高效、用户友好的Fiori体验的基石。2. Launchpad架构与核心组件拆解要玩转Launchpad的配置不能只停留在点击按钮的层面必须对其背后的架构和核心组件有一个清晰的认知。这就像装修房子你得先知道承重墙、水管和电路在哪里才能进行有效的设计和改造。2.1 三层结构模型前端、网关与后端一个完整的Fiori Launchpad体验通常涉及三个逻辑层理解它们之间的协作关系是进行一切配置和问题排查的基础。前端层Frontend即用户直接与之交互的浏览器界面。它主要由SAPUI5框架渲染负责呈现磁贴、目录、组等视觉元素并处理用户的操作事件点击、搜索等。这一层是静态的其内容和布局信息需要从后端动态获取。SAP Fiori前端服务器层Frontend Server 常与ABAP环境集成这是Launchpad的“大脑”和“配置中心”。在ABAP栈的Fiori部署中例如基于NetWeaver的Fiori Frontend Server或S/4HANA嵌入式Fiori这一层运行着关键的Launchpad服务。它存储并管理着所有的配置元数据包括Catalogs目录所有可用应用的集合池。可以理解为应用商店的“总仓库”。Groups组分配给特定用户或角色的应用集合。这是用户最终在Launchpad首页上看到的一个个“文件夹”或区域。Target Mappings目标映射定义了磁贴Tile或链接Link点击后具体导航到哪个后端业务应用例如一个SAP GUI事务、一个Web Dynpro应用或一个Fiori App的规则。它包含了应用的技术URL、语义对象Semantic Object和动作Action等信息。后端业务套件层Backend即提供实际业务数据和逻辑的SAP系统如S/4HANA、ECC、CRM等。Launchpad本身不处理业务数据它通过OData服务、RFC或直接URL调用等方式与后端通信。当用户点击一个磁贴时Launchpad会根据目标映射的配置向对应的后端系统发起请求并打开相应的应用。注意在纯粹的SAP Cloud Platform现称BTPFiori环境中Launchpad服务托管在BTP上其配置工具和架构与ABAP环境有所不同例如使用SAP Build Work Zone但核心概念目录、组、角色是相通的。本文主要聚焦于基于ABAP环境的Fiori Launchpad配置这是目前大多数On-Premise或私有云部署的常见场景。2.2 核心配置对象详解在Launchpad的配置世界里有几个核心对象你必须像熟悉自己的工具一样熟悉它们。它们之间具有清晰的包含和分配关系。磁贴TileLaunchpad界面上最小的可视化单元代表一个应用的入口。它通常包含图标、标题、副标题有时还有动态数字例如待审批单据数量。磁贴分为静态磁贴和动态磁贴。静态磁贴就是固定的链接动态磁贴则能通过OData服务实时获取并显示后端数据例如“我的待办事项12”。目标映射Target Mapping这是连接前端磁贴和后端应用的“桥梁”或“路由规则”。它不是一个用户直接可见的UI元素而是一个后台配置项。一个目标映射定义了semantic_object语义对象如“PurchaseOrder”代表业务对象类型。semantic_action语义动作如“display”或“create”代表要对这个对象执行的操作。url实际的应用启动URL通常是一个指向特定Fiori App或传统事务的链接。 当用户点击一个磁贴时Launchpad引擎会查找与这个磁贴关联的目标映射然后根据映射的URL导航到应用。目录Catalog一个逻辑上的容器用于归类和管理所有可分配的应用通过目标映射表示。例如你可以创建一个“财务专用目录”里面包含所有财务相关的应用目标映射。目录通常与业务领域相关但目录本身不会直接显示给最终用户。它是管理员用来管理应用池的工具。组Group这才是最终用户能在其Launchpad首页上看到的容器。一个组包含一系列磁贴并以一个标签如“我的财务”、“采购工作台”展示。管理员通过将目录中的目标映射应用分配到一个或多个组来为不同角色的用户定制他们的首页内容。角色RoleSAP中的权限控制单元。Launchpad内容的分配最终是与PFCG角色绑定的。通过事务代码PFCG你可以将特定的目录和组分配给一个角色。当用户被分配了这个角色后其Launchpad就会自动显示该角色所关联的组和目录中的应用。它们的关系链可以简化为创建目标映射应用 → 将目标映射放入目录 → 将目录中的目标映射以磁贴形式添加到组 → 将目录和组分配给角色 → 将角色分配给用户。这个链条是Launchpad配置的黄金法则。3. 实战从零开始配置一个Fiori Launchpad应用理论说得再多不如动手操作一遍。下面我将以一个常见的场景为例为采购员配置一个能够快速查看采购订单Purchase Order的Fiori应用磁贴。我们假设后端是S/4HANA前端Fiori Launchpad环境已就绪。3.1 第一步确定后端应用与语义对象首先我们需要知道用哪个Fiori App来“查看采购订单”。在S/4HANA中有一个标准的Fiori App叫做“Manage Purchase Orders”应用ID:Fiori2_F1730。其标准的语义对象和动作是语义对象Semantic Object:PurchaseOrder语义动作Semantic Action:manage你可以通过SAP的官方应用库Fiori Apps Library或在后端系统通过事务码/UI2/FLP查看已部署的应用及其语义信息。这一步至关重要因为目标映射的配置必须与后端应用声明的语义对象和动作严格匹配否则导航会失败。3.2 第二步创建目标映射Target Mapping这是最核心的配置步骤。我们通过事务码LPD_CUSTLaunchpad定制来操作。进入LPD_CUST选择“目标映射”视图。点击“创建”按钮。填写关键字段目标映射ID定义一个唯一的技术ID如ZM_PO_MANAGE。语义对象填入PurchaseOrder。语义动作填入manage。URL类型选择“事务”如果对应传统GUI事务或“URL”。对于标准Fiori App通常系统已经预置了配置你可能只需要“采用”Adopt一个现有的映射。如果是自定义应用则需要手动构造URL。标准Fiori App的URL模式通常类似于/sap/bc/ui5_ui5/sap/ypo_manage/index.html。URL如果手动输入需要完整的路径。更推荐使用“采用”功能从系统已注册的应用列表中选择。标题文本定义磁贴上显示的名称如“管理采购订单”。副标题文本可选如“查看与处理采购订单”。图标从SAP图标库中选择一个例如/SAP/ICONS/PO。保存并激活这个目标映射。实操心得在配置URL时一个常见的坑是忽略了跨客户端导航Cross-Client Navigation的需求。如果你的Fiori Launchpad服务器和后端业务系统是分开的分布式部署那么URL中可能需要包含系统别名System Alias信息。这时URL可能会以sap/bc/ui2/flp开头并附带sap-client和sap-system等参数。务必根据你的系统架构参考SAP Note或部署指南来配置正确的URL格式。3.3 第三步创建目录Catalog并添加应用接下来我们需要一个“采购应用目录”来收纳这个目标映射。在LPD_CUST中切换到“目录”视图。点击“创建”输入目录ID如Z_PURCHASING_CATALOG和描述。进入目录的详细配置页面在“目标映射分配”子标签页下点击“添加”。在弹出的搜索框中找到你刚才创建的目标映射ZM_PO_MANAGE并将其添加到目录中。保存并激活目录。你可以把多个相关的应用目标映射都加到这个目录里比如创建采购申请、监控供应商等应用。3.4 第四步创建组Group并设计布局目录是仓库组才是用户的桌面。现在我们来创建一个“采购工作台”组。在LPD_CUST中切换到“组”视图。点击“创建”输入组ID如Z_PURCHASING_WORKCENTER和描述。进入组的详细配置页面在“磁贴分配”子标签页下点击“添加”。系统会列出所有已分配给当前登录用户角色的目录中的目标映射。因为我们还没进行角色分配这里可能看不到。我们可以通过“手动添加磁贴”的方式直接搜索并添加ZM_PO_MANAGE这个目标映射。添加后它就成为了组里的一个磁贴。布局设计你可以在“组编辑器”中拖动磁贴来调整它们在页面上的位置。你还可以创建多个“行”或“区域”来分组磁贴使页面更整洁。例如你可以将“查询类”应用放在一行“创建类”应用放在另一行。3.5 第五步通过角色Role进行权限分配最后也是最关键的一步将目录和组与权限角色绑定。打开事务码PFCG创建一个新的角色或编辑一个现有的采购员角色如Z_PURCHASER。进入“菜单”标签页。这里就是为角色分配Launchpad内容的地方。点击“添加其他对象”在对象类型中选择“SAP Fiori”。系统会打开Fiori内容分配界面。在这里你可以在“目录”标签下搜索并分配你创建的目录Z_PURCHASING_CATALOG。这赋予了角色“可以看到这些应用”的权限。在“组”标签下搜索并分配你创建的组Z_PURCHASING_WORKCENTER。这决定了用户的Launchpad首页具体显示哪些磁贴以及如何布局。保存角色并执行“角色权限概览”生成权限参数文件。最后在PFCG的“用户”标签页将这个角色分配给相应的采购用户。完成以上步骤后当采购员登录Fiori Launchpad时其首页就会出现“采购工作台”组里面包含“管理采购订单”的磁贴点击即可直接跳转到对应的Fiori应用。4. 高级配置与个性化功能探索基础的磁贴配置只是开始要让Launchpad真正强大和贴心还需要掌握一些高级配置和个性化功能。4.1 动态磁贴与实时数据静态磁贴只是一个入口而动态磁贴能直接传递信息。最常见的动态磁贴是“数字磁贴”它通过一个OData服务定期轮询后端数据并将数量显示在磁贴右上角例如“我的审批5”。配置动态磁贴的关键在于目标映射的“可视化”设置在创建或编辑目标映射时找到“可视化”相关字段。指定一个“信息源”OData Service。这个服务需要返回特定的数据结构通常包含一个number字段。设置刷新间隔如每5分钟。在磁贴模板中选择支持数字显示的模板例如“数字磁贴”。注意事项动态磁贴的OData服务需要精心设计和优化避免频繁调用对后端系统造成性能压力。同时要确保该服务包含必要的权限检查用户只能看到自己有权限访问的数据计数。4.2 搜索与语义对象集成Fiori Launchpad的全局搜索功能非常强大。用户不仅可以通过应用名称搜索还可以直接搜索业务数据如采购订单号“4500001234”。这得益于语义对象的集成。要使你的应用支持这种深度搜索需要确保目标映射正确配置了语义对象和动作我们在第一步就做了。在后端应用Fiori App中实现相应的manifest.json配置和搜索模型Search Model告诉Launchpad搜索时应该调用哪个OData服务的哪个实体集EntitySet来查找数据。在Launchpad设计器中可以配置搜索连接器Search Connector将语义对象与特定的后端搜索服务关联起来。当这些配置完成后用户在Launchpad搜索框输入一个采购订单号搜索结果中不仅会出现“管理采购订单”这个应用还可能直接出现一条指向该订单详细信息的链接实现一键直达。4.3 用户个性化与页面变式除了管理员集中配置Launchpad也支持最终用户进行一定程度的个性化这大大提升了用户体验。个性化编辑模式用户点击Launchpad右上角的“编辑”按钮可以进入编辑模式。在此模式下他们可以在已分配的组内自由拖动磁贴调整位置。将常用磁贴固定在主页即使它属于一个需要滚动才能看到的组。从已分配目录中将其他应用磁贴添加到现有组或创建新的个人组。隐藏不需要的磁贴。页面变式Page Variants对于关键用户或特定团队管理员可以创建不同的页面布局变式。例如为“采购经理”和“采购专员”创建两个不同的组布局变式然后通过业务角色分配不同的变式。这比维护完全不同的两个角色和组要灵活得多。这些个性化设置会保存在用户个人配置中不会影响其他用户。管理员在LPD_CUST中可以通过“传输个性化设置”功能将某个用户的优秀布局作为模板推广给其他同角色用户。5. 常见问题排查与配置优化实录在实际配置和运维中你肯定会遇到各种问题。下面我整理了几个最典型的问题和排查思路这些都是用时间和教训换来的经验。5.1 问题一磁贴点击后报错“无法启动应用程序”这是最常见的问题。请按照以下链条顺序排查检查目标映射的URL这是首要怀疑对象。直接在浏览器新标签页中粘贴目标映射里配置的完整URL看是否能独立打开应用。如果打不开说明URL本身错误可能是路径不对、系统别名错误或缺少参数。检查语义对象/动作确保目标映射中配置的语义对象和动作与Fiori应用manifest.json文件中sap.app章节下定义的crossNavigation配置完全一致包括大小写。检查后端系统可达性对于分布式部署确保Fiori前端服务器能通过网络访问到后端业务系统并且相关的逻辑端口是开放的。使用事务码SM59测试RFC连接或直接在服务器上用浏览器测试后端服务的URL。检查用户权限确保测试用户不仅拥有Launchpad前端角色还在后端业务系统拥有执行该事务或访问该OData服务所需的权限。可以尝试用SU01将用户与SAP_ALL这类全权限临时关联测试以排除权限问题。检查应用状态通过事务码/UI2/FLP检查该Fiori应用是否已正确部署并处于激活状态。5.2 问题二用户登录后看不到预期的磁贴或组这通常是角色分配或缓存问题。确认角色分配在PFCG中双重检查目录和组是否已正确添加到角色中并且角色已分配给用户。记得在PFCG中保存并生成权限参数文件。检查用户菜单以该用户登录GUI执行事务码SU01查看“菜单”标签页确认Fiori内容目录和组是否出现在其个人菜单中。如果没有可能是角色未正确传输。清除前端缓存Launchpad前端有缓存机制。指导用户按下ShiftCtrlAltS在打开的“技术支持”弹窗中点击“删除本地数据”清除浏览器缓存。或者在前端服务器运行事务码/UI2/INVALIDATE_CLIENT_CACHE输入客户端号来清除服务器端缓存。检查组是否为空在LPD_CUST中检查该组确保里面已经添加了磁贴。一个没有分配任何磁贴的组即使分配给用户也不会显示。5.3 问题三动态磁贴不显示数字或显示错误检查OData服务首先在浏览器中直接调用动态磁贴配置的OData服务URL看是否能返回正确的JSON数据并且数据结构符合预期通常根节点下有一个value数组里面包含number等字段。检查服务权限确保当前用户有权限调用这个OData服务。可以使用工具如Postman带上用户的登录凭证测试服务。检查刷新配置在目标映射配置中确认“信息刷新间隔”设置合理且已保存。间隔太短可能被服务器限流太长则数据更新不及时。查看浏览器控制台按F12打开开发者工具查看网络Network选项卡和控制器Console选项卡寻找加载磁贴信息时的错误请求或JavaScript错误。5.4 配置优化建议分组与命名规范为目录、组、目标映射建立清晰的技术命名规范和业务描述。例如目录ID以ZCAT_开头组ID以ZGRP_开头目标映射以ZM_开头。业务描述要能让其他管理员一眼看懂。利用传输请求所有的LPD_CUST配置都应该在某个开发/定制客户端进行并通过传输请求Transport Request移动到测试和生产系统。绝对避免在生产系统直接修改。在传输后记得在生产系统激活相关配置对象。性能考量一个用户的Launchpad首页不宜加载过多动态磁贴每个磁贴的OData调用都会增加页面加载时间。对于非关键信息考虑使用静态磁贴或延长刷新间隔。定期审计与清理随着业务变化定期回顾不再使用的目录、组和目标映射并将其标记为不活跃或删除以保持配置环境的清晰。
)
