前几年第一次在 SPRO 里看到 LPD_CUST 这个名字我第一反应是这又是哪个模块的配置表。后来做 SAP Fiori LaunchpadFLP项目的次数多了才意识到这张表才是很多“导航目标”问题的真正源头。不管你是想让一个外部网页在 FLP 里能点开还是想把 Web Dynpro 老应用包装成 Fiori 入口又或者是用户反馈“换个设备就看不到入口”最后大概率都要回到 LPD_CUST 的字段级调试上。这篇就把 LPD_CUST 从表结构、配置步骤到常见坑一次讲清楚适合刚接手 Fiori 定制项目的顾问也适合被业务方追问“为什么我配了没反应”的 ABAP 开发。1. 先搞清楚 LPD_CUST 是干嘛的一张表背后的导航机制1.1 名字里的信息Launchpad Customizing 从哪来LPD_CUST 全称 Launchpad Customizing意思是“启动板自定义”。它在 SAP NetWeaver 的 Fiori 体系里承担一个朴素但重要的角色把导航目标Navigation Target维护到一张可被 FLP 运行时读取的配置表里。你可以把它理解成一个“总机接线表”——用户在前端点某个入口FLP 根据这张表去决定跳到哪里、给谁看、用什么设备打开。为什么会有这张表Fiori 这套东西刚出来的时候SAP 希望大家用“语义对象 动作”的方式来描述导航意图而不是直接拿 URL 写死。一个入口的完整描述是语义对象Semantic Object 动作Action组合成 Intent比如ZOrder-Display。LPD_CUST 就是用来维护这套“意图 落地地址 可见性”映射关系的表。换句话说它比 Launchpad Designer 更早是 FLP 定制能力的老前辈但到现在仍然被大量项目沿用。1.2 LPD_CUST 和 Standard Launchpad、Custom Launchpad 的关系很多同事在这里栽过跟头所以先把这个关系讲清楚。Fiori Launchpad 有两种展示视图Standard Launchpad 和 Custom Launchpad。Standard Launchpad 就是我们通常看到的磁贴tile界面它基于目录Catalog和分组Group模型配置存放在/UI2/开头的一系列表里通过 Launchpad Designer 或 Fiori 管理员 App 维护。Custom Launchpad 则是一个类似经典 SAP Easy Access 的树形菜单视图。用户在 FLP 右上角可以对视图做切换而 Custom Launchpad 的目录树正是由 LPD_CUST 驱动。每条 LPD_CUST 记录可以是一个文件夹也可以是一个具体导航目标通过 PARENT 字段挂接父节点就形成了一棵树。这解释了一个常见现象业务方说“我在 SPRO 里配好了Fiori 前端怎么看不到”。答案往往是——你看的是 Standard Launchpad而 LPD_CUST 的入口在 Custom Launchpad 视图里或者你配了 Custom Launchpad 的文件夹但用户角色根本没触发该条记录的可见性。两种视图差异是 LPD_CUST 调试时第一件要确认的事。1.3 核心字段一次讲透我平时维护 LPD_CUST 主要通过 SM30 输入 V_LPD_CUST 这个维护视图。不同 NetWeaver 版本显示的字段会略有差异但核心逻辑基本一致。下表列出项目里最常用、也是排查时最先会盯住的字段。字段作用填法/注意点SEQNR记录序号同一 Client 内唯一建议用 1000、2000 这样的步长后续插入记录不用大改FOLDER是否文件夹X 是文件夹本身不打开页面只作为树节点容器PARENT父节点 SEQNR空表示根节点子节点填父文件夹的 SEQNRSEMANTIC_OBJECT语义对象建议大写开头如 ZZMaterial自定义对象要先注册SEMANTIC_ACTION动作如 Display、Create、Launch与语义对象一起定位意图INTENT意图即 语义对象-动作FLP 解析导航时按这个值匹配DEVICE_TYPE设备类型Desktop/Tablet/Phone注意多端覆盖ROLES可见角色过滤留空对所有用户可见填写角色关键字做白名单ITEM_TEXT节点/入口显示文本用户看到的名称要短、可辨识URL实际跳转地址外部地址带协议内部路径注意编码ICON图标名配合前端图标库使用可选DESCRIPTION描述给顾问自己看的说明不影响运行这里最容易被忽略的是 DEVICE_TYPE。很多项目只在 Desktop 上配了入口结果同事用平板开 FLP发现某个菜单没了查半天最后发现是设备类型没配。建议如果业务上不区分设备就三种都配上或者直接确认当前版本支持通配符。字段里还有一层业务逻辑SEMANTIC_OBJECT 和 SEMANTIC_ACTION 是“意图层”URL 是“落地层”。FLP 导航时先拿 INTENT 找入口再按设备类型挑 URL。意图相同但 URL 不同是完全允许的这正是设备分流的基础。表格里 FOLDER 和 PARENT 则决定了入口在树上的位置配合 ROLES 就能做到“不同角色看到不同层级树”。2. 什么场景下才值得动 LPD_CUST选型思路和典型使用场景2.1 场景一外部页面、老系统、Web Dynpro 快速接入 FLP最常见的一个需求公司有一个自研门户页面、一套老 Web Dynpro 应用或者另一个系统比如 BI 报表、客户门户的 URL希望能在 Fiori Launchpad 里给用户一个入口点开就在新页面看到它。这种场景不需要做复杂的 Fiori 应用开发也不需要把页面做成 OData 服务用 LPD_CUST 配一条记录加一个图标就够了。我在一个制造客户那边干过类似的事他们把车间的 MES 看板页面直接嵌到 FLP 里用的就是 LPD_CUST。配置上只做了三件事定语义对象 ZZMesBoard动作 LaunchURL 填车间看板的 HTTPS 地址角色限定到 MES 相关工厂角色。从提出需求到上线不到半小时这比走一遍 Fiori 应用发布流程省太多了。为什么不用 Launchpad Designer 的“外部链接”方案也可以但 LPD_CUST 在角色条件控制和树形组织上更接近业务习惯。尤其当外部页面数量多、需要按模块归类时用 PARENT 搭文件夹比做一堆 Catalog、Group 再来回调样式要直观。2.2 场景二同一入口按设备分流到不同地址移动场景下一套桌面端页面直接甩给手机用户体验基本是灾难。LPD_CUST 的 DEVICE_TYPE 字段就是为这个准备的。可以给同一个 INTENT 维护多条记录分别指定 Desktop、Tablet、Phone 的 URL。桌面端打开完整 BI 报表手机端打开同一个报表的移动版地址。这里有个实操细节一旦你打算做设备分流URL 之间最好保持“同一业务功能、不同终端体验”的关系而不是完全不同的内容。否则用户从手机切到电脑发现入口还在但内容对不上业务方会认为导航目标配置有 bug。我习惯在 DESCRIPTION 里写清楚每个设备 URL 对应的版本避免后任顾问接手时靠猜。2.3 场景三旧菜单树迁移 / 轻量级“类 Easy Access”导航有些客户是从经典 SAP GUI 界面迁移过来的用户习惯了树形菜单点开“生产制造”下面是一排事务码入口。FLP 的标准磁贴界面虽然好看但老用户不见得买账。Custom Launchpad 配合 LPD_CUST 的文件夹层级能快速复刻这种树形体验而且角色过滤玩熟了以后比 PFCG 菜单还容易维护。我在项目里见过最狠的用法是把 SAP 标准事务码比如 MM03、ME23N也用 LPD_CUST 包了一层入口文本写成业务人员看得懂的“查询物料”“查看采购订单”URL 指向事务码对应的 GUI 启动地址或 ICF 服务。这样既保住了业务既有习惯又用 Fiori 外壳统一了入口。注意这种用法本质上是“把旧入口换个壳”不是标准 Fiori 应用后期做 S/4 迁移时要评估是否要替换成新一代应用。2.4 什么时候别用它与 Launchpad Designer 的边界LPD_CUST 再好用也不是万能。如果你要做的入口需要运行时动态参数比如用户点一个订单带着订单号跳到另一个 AppApp 到 App 的跨应用导航、参数回传复杂的目标映射Target Mapping按条件选不同应用地址在 Standard Launchpad 上以磁贴方式呈现并参与目录/分组管理那就老老实实用 Launchpad Designer 做 Tile Target Mapping。LPD_CUST 适合的定位是“轻量、静态、以角色和设备为维度”的导航入口。选型错误是 LPD_CUST 项目里最隐蔽的风险因为它表面看起来什么都能配配到后面发现无法表达业务动态跳转需求返工成本比一开始就用对方案高得多。3. 实操从计划到落地的完整配置步骤3.1 配置前先定三件事意图、命名规范、入库入口动手前先花十分钟做三个约定能省掉后面大量返工。第一语义对象和动作的命名。自开发对象建议遵循 Z 前缀比如 ZMaterial、ZBpmTask。动作尽量用标准英文动词Display、Create、Launch、Manage。命名一旦上线后面改起来会牵连角色、菜单、甚至已打开的 FLP 缓存所以第一次就定严谨。第二SEQNR 规划。虽然字段只是数字序号但层级树的可维护性全靠它。我习惯按模块分区间1000 起步做根文件夹1100 到 1999 放该模块下的入口2000 开始另一个模块。中间留出冗余下次插入不用改别人序号。第三确定维护入口。SPRO 路径一般可以在 SAP NetWeaver 相关章节里找到 Fiori Launchpad 的 Customizing 节点具体活动名称是 Define Navigation Targets 一类但实际项目里大部分人直接用 SM30 视图 V_LPD_CUST 维护。两种方式本质一样SPRO 的好处是带了文档链接SM30 的好处是快。我推荐日常用 SM30上线前用 SPRO 过一遍配置审查。3.2 用 SM30 维护 V_LPD_CUST字段填写与层级设计现在演示一个完整例子。假设要加一个模块工厂能耗看板外部页面。规划如下根文件夹SEQNR1000FOLDERXITEM_TEXT生产运营ROLES 留空DEVICE_TYPE 三种都配子入口SEQNR1010FOLDER 空PARENT1000SEMANTIC_OBJECTZEnergySEMANTIC_ACTIONLaunchINTENTZEnergy-LaunchITEM_TEXT能耗看板URLhttps://ies.example.com/board/energyROLESZ_ENERGY_VIEWERDEVICE_TYPE 三种都配。操作步骤进入 SM30输入 V_LPD_CUST点 Maintain维护如果系统提示弹窗或维护对话框按提示进入表内容维护界面新建一条记录按上面字段填保存前确认 Client 是你希望生效的逻辑层比如开发/生产配置请求保存后系统会要求生成/更新一个配置请求Customizing Request按公司传输规则填写
前几年第一次在 SPRO 里看到 LPD_CUST 这个名字我第一反应是这又是哪个模块的配置表。后来做 SAP Fiori LaunchpadFLP项目的次数多了才意识到这张表才是很多“导航目标”问题的真正源头。不管你是想让一个外部网页在 FLP 里能点开还是想把 Web Dynpro 老应用包装成 Fiori 入口又或者是用户反馈“换个设备就看不到入口”最后大概率都要回到 LPD_CUST 的字段级调试上。这篇就把 LPD_CUST 从表结构、配置步骤到常见坑一次讲清楚适合刚接手 Fiori 定制项目的顾问也适合被业务方追问“为什么我配了没反应”的 ABAP 开发。1. 先搞清楚 LPD_CUST 是干嘛的一张表背后的导航机制1.1 名字里的信息Launchpad Customizing 从哪来LPD_CUST 全称 Launchpad Customizing意思是“启动板自定义”。它在 SAP NetWeaver 的 Fiori 体系里承担一个朴素但重要的角色把导航目标Navigation Target维护到一张可被 FLP 运行时读取的配置表里。你可以把它理解成一个“总机接线表”——用户在前端点某个入口FLP 根据这张表去决定跳到哪里、给谁看、用什么设备打开。为什么会有这张表Fiori 这套东西刚出来的时候SAP 希望大家用“语义对象 动作”的方式来描述导航意图而不是直接拿 URL 写死。一个入口的完整描述是语义对象Semantic Object 动作Action组合成 Intent比如ZOrder-Display。LPD_CUST 就是用来维护这套“意图 落地地址 可见性”映射关系的表。换句话说它比 Launchpad Designer 更早是 FLP 定制能力的老前辈但到现在仍然被大量项目沿用。1.2 LPD_CUST 和 Standard Launchpad、Custom Launchpad 的关系很多同事在这里栽过跟头所以先把这个关系讲清楚。Fiori Launchpad 有两种展示视图Standard Launchpad 和 Custom Launchpad。Standard Launchpad 就是我们通常看到的磁贴tile界面它基于目录Catalog和分组Group模型配置存放在/UI2/开头的一系列表里通过 Launchpad Designer 或 Fiori 管理员 App 维护。Custom Launchpad 则是一个类似经典 SAP Easy Access 的树形菜单视图。用户在 FLP 右上角可以对视图做切换而 Custom Launchpad 的目录树正是由 LPD_CUST 驱动。每条 LPD_CUST 记录可以是一个文件夹也可以是一个具体导航目标通过 PARENT 字段挂接父节点就形成了一棵树。这解释了一个常见现象业务方说“我在 SPRO 里配好了Fiori 前端怎么看不到”。答案往往是——你看的是 Standard Launchpad而 LPD_CUST 的入口在 Custom Launchpad 视图里或者你配了 Custom Launchpad 的文件夹但用户角色根本没触发该条记录的可见性。两种视图差异是 LPD_CUST 调试时第一件要确认的事。1.3 核心字段一次讲透我平时维护 LPD_CUST 主要通过 SM30 输入 V_LPD_CUST 这个维护视图。不同 NetWeaver 版本显示的字段会略有差异但核心逻辑基本一致。下表列出项目里最常用、也是排查时最先会盯住的字段。字段作用填法/注意点SEQNR记录序号同一 Client 内唯一建议用 1000、2000 这样的步长后续插入记录不用大改FOLDER是否文件夹X 是文件夹本身不打开页面只作为树节点容器PARENT父节点 SEQNR空表示根节点子节点填父文件夹的 SEQNRSEMANTIC_OBJECT语义对象建议大写开头如 ZZMaterial自定义对象要先注册SEMANTIC_ACTION动作如 Display、Create、Launch与语义对象一起定位意图INTENT意图即 语义对象-动作FLP 解析导航时按这个值匹配DEVICE_TYPE设备类型Desktop/Tablet/Phone注意多端覆盖ROLES可见角色过滤留空对所有用户可见填写角色关键字做白名单ITEM_TEXT节点/入口显示文本用户看到的名称要短、可辨识URL实际跳转地址外部地址带协议内部路径注意编码ICON图标名配合前端图标库使用可选DESCRIPTION描述给顾问自己看的说明不影响运行这里最容易被忽略的是 DEVICE_TYPE。很多项目只在 Desktop 上配了入口结果同事用平板开 FLP发现某个菜单没了查半天最后发现是设备类型没配。建议如果业务上不区分设备就三种都配上或者直接确认当前版本支持通配符。字段里还有一层业务逻辑SEMANTIC_OBJECT 和 SEMANTIC_ACTION 是“意图层”URL 是“落地层”。FLP 导航时先拿 INTENT 找入口再按设备类型挑 URL。意图相同但 URL 不同是完全允许的这正是设备分流的基础。表格里 FOLDER 和 PARENT 则决定了入口在树上的位置配合 ROLES 就能做到“不同角色看到不同层级树”。2. 什么场景下才值得动 LPD_CUST选型思路和典型使用场景2.1 场景一外部页面、老系统、Web Dynpro 快速接入 FLP最常见的一个需求公司有一个自研门户页面、一套老 Web Dynpro 应用或者另一个系统比如 BI 报表、客户门户的 URL希望能在 Fiori Launchpad 里给用户一个入口点开就在新页面看到它。这种场景不需要做复杂的 Fiori 应用开发也不需要把页面做成 OData 服务用 LPD_CUST 配一条记录加一个图标就够了。我在一个制造客户那边干过类似的事他们把车间的 MES 看板页面直接嵌到 FLP 里用的就是 LPD_CUST。配置上只做了三件事定语义对象 ZZMesBoard动作 LaunchURL 填车间看板的 HTTPS 地址角色限定到 MES 相关工厂角色。从提出需求到上线不到半小时这比走一遍 Fiori 应用发布流程省太多了。为什么不用 Launchpad Designer 的“外部链接”方案也可以但 LPD_CUST 在角色条件控制和树形组织上更接近业务习惯。尤其当外部页面数量多、需要按模块归类时用 PARENT 搭文件夹比做一堆 Catalog、Group 再来回调样式要直观。2.2 场景二同一入口按设备分流到不同地址移动场景下一套桌面端页面直接甩给手机用户体验基本是灾难。LPD_CUST 的 DEVICE_TYPE 字段就是为这个准备的。可以给同一个 INTENT 维护多条记录分别指定 Desktop、Tablet、Phone 的 URL。桌面端打开完整 BI 报表手机端打开同一个报表的移动版地址。这里有个实操细节一旦你打算做设备分流URL 之间最好保持“同一业务功能、不同终端体验”的关系而不是完全不同的内容。否则用户从手机切到电脑发现入口还在但内容对不上业务方会认为导航目标配置有 bug。我习惯在 DESCRIPTION 里写清楚每个设备 URL 对应的版本避免后任顾问接手时靠猜。2.3 场景三旧菜单树迁移 / 轻量级“类 Easy Access”导航有些客户是从经典 SAP GUI 界面迁移过来的用户习惯了树形菜单点开“生产制造”下面是一排事务码入口。FLP 的标准磁贴界面虽然好看但老用户不见得买账。Custom Launchpad 配合 LPD_CUST 的文件夹层级能快速复刻这种树形体验而且角色过滤玩熟了以后比 PFCG 菜单还容易维护。我在项目里见过最狠的用法是把 SAP 标准事务码比如 MM03、ME23N也用 LPD_CUST 包了一层入口文本写成业务人员看得懂的“查询物料”“查看采购订单”URL 指向事务码对应的 GUI 启动地址或 ICF 服务。这样既保住了业务既有习惯又用 Fiori 外壳统一了入口。注意这种用法本质上是“把旧入口换个壳”不是标准 Fiori 应用后期做 S/4 迁移时要评估是否要替换成新一代应用。2.4 什么时候别用它与 Launchpad Designer 的边界LPD_CUST 再好用也不是万能。如果你要做的入口需要运行时动态参数比如用户点一个订单带着订单号跳到另一个 AppApp 到 App 的跨应用导航、参数回传复杂的目标映射Target Mapping按条件选不同应用地址在 Standard Launchpad 上以磁贴方式呈现并参与目录/分组管理那就老老实实用 Launchpad Designer 做 Tile Target Mapping。LPD_CUST 适合的定位是“轻量、静态、以角色和设备为维度”的导航入口。选型错误是 LPD_CUST 项目里最隐蔽的风险因为它表面看起来什么都能配配到后面发现无法表达业务动态跳转需求返工成本比一开始就用对方案高得多。3. 实操从计划到落地的完整配置步骤3.1 配置前先定三件事意图、命名规范、入库入口动手前先花十分钟做三个约定能省掉后面大量返工。第一语义对象和动作的命名。自开发对象建议遵循 Z 前缀比如 ZMaterial、ZBpmTask。动作尽量用标准英文动词Display、Create、Launch、Manage。命名一旦上线后面改起来会牵连角色、菜单、甚至已打开的 FLP 缓存所以第一次就定严谨。第二SEQNR 规划。虽然字段只是数字序号但层级树的可维护性全靠它。我习惯按模块分区间1000 起步做根文件夹1100 到 1999 放该模块下的入口2000 开始另一个模块。中间留出冗余下次插入不用改别人序号。第三确定维护入口。SPRO 路径一般可以在 SAP NetWeaver 相关章节里找到 Fiori Launchpad 的 Customizing 节点具体活动名称是 Define Navigation Targets 一类但实际项目里大部分人直接用 SM30 视图 V_LPD_CUST 维护。两种方式本质一样SPRO 的好处是带了文档链接SM30 的好处是快。我推荐日常用 SM30上线前用 SPRO 过一遍配置审查。3.2 用 SM30 维护 V_LPD_CUST字段填写与层级设计现在演示一个完整例子。假设要加一个模块工厂能耗看板外部页面。规划如下根文件夹SEQNR1000FOLDERXITEM_TEXT生产运营ROLES 留空DEVICE_TYPE 三种都配子入口SEQNR1010FOLDER 空PARENT1000SEMANTIC_OBJECTZEnergySEMANTIC_ACTIONLaunchINTENTZEnergy-LaunchITEM_TEXT能耗看板URLhttps://ies.example.com/board/energyROLESZ_ENERGY_VIEWERDEVICE_TYPE 三种都配。操作步骤进入 SM30输入 V_LPD_CUST点 Maintain维护如果系统提示弹窗或维护对话框按提示进入表内容维护界面新建一条记录按上面字段填保存前确认 Client 是你希望生效的逻辑层比如开发/生产配置请求保存后系统会要求生成/更新一个配置请求Customizing Request按公司传输规则填写
