尧图网站建设 
做SAP Fiori项目这几年接到过不少Launchpad相关的工单一半以上都和磁贴Tile有关。要么是某张磁贴不显示要么是点完报错要么是同一个应用出现两遍再要么是用户说“我的启动板里多了一个图标”。排查这类问题第一步往往不是去看ABAP代码也不是去盯网关服务而是先把Tile ID找出来。可偏偏就是这一步卡住了不少人——明明在Launchpad Designer里看到了对应的磁贴却不知道它的唯一标识藏在哪一栏更不知道这个ID拿到手之后后面该怎么用。这篇文章是给Fiori顾问、BASIS、ABAP开发以及做Fiori项目运维的同行看的。如果你正在做S/4HANA的启动板配置或者已经投入到Fiori项目的运维支持里那文中的思路基本可以拿来直接用。我会从三个层面展开先在界面上把Tile ID的获取路径摸清楚再从数据层说明如何反查最后用一个项目排障的完整案例把这些操作串起来。这样即便你之前没怎么用过Launchpad Designer也能少走几步弯路。我先把话放在前面定位Tile ID本身不是什么高深技术真正考验人的是你拿到这个ID之后如何判断它是哪个Catalog里的、对应哪个Target Mapping、分配给了哪几个业务角色。这套排查逻辑才是这篇内容的重点。1. 理解Tile ID先搞清楚启动板里的“门牌号”体系1.1 Fiori Launchpad的层级关系Fiori Launchpad不是简单地把一堆网址堆在页面上它有一套完整的配置层级。从高到低大致是这样业务角色Business Role在PFCG里维护决定用户登录后能看到哪些内容。目录Catalog一组磁贴和相关应用的集合属于逻辑分组可以理解为“内容容器”。分组Group实际展示在Launchpad页面上的栏位或Section。同一个Catalog下的Tile可以被分配到不同的Group里。磁贴Tile用户看到的每一个图标和标题组合是交互的入口。目标映射Target Mapping磁贴点击后实际触发的导航目标通过Semantic Object和Action来定义。这个层级我打过一个比方Catalog就像仓库里的货架区Group是仓库对应的门店展台Tile是展台上的商品而Target Mapping是贴在商品上的配送单告诉系统“把这件商品送到哪个门店、哪个位置”。权限配置时角色把一个Catalog分配给用户用户才能看到这个Catalog下的Tile而Group则控制这些Tile在页面上怎么摆放、放在哪个区域。理解这个链条后你就能明白一个核心结论Tile ID只是磁贴的“身份标识”它本身不决定权限也不决定导航。但如果这个ID抓不准后面所有的排障操作都会跑偏。1.2 Tile ID到底是个什么东西Tile ID在系统里对应的字段名通常是Tile Key。它是一段全局唯一的字符串用来在系统内部标识一个磁贴配置。不同系统的Tile ID命名风格不太一样有的是SAP标准预置ID看起来像是一串有规律的英文加下划线比如ap_pa_approve_tile这种风格有的是客户在项目里自定义的可能类似zmm_purchase_order_tile还有早期系统自动生成的可能是一长串字符或由系统内部命名规则生成。在Launchpad Designer界面中这个ID通常显示为“Tile Key”或“ID”在磁贴的详情页面能看到。很多人第一次接触时会误以为磁贴标题就是ID其实标题可以重复、可以改但Tile Key必须在同一个系统里唯一。所以排查问题、做配置传输、写脚本批量修改时都要以Tile Key为准。1.3 为什么定位Tile ID会成为“高频问题”既然只是找一个字段为什么能成为Fiori群里常问的问题我观察下来主要有三个原因第一界面入口隐蔽。Fiori Launchpad Designer本身不是一个很显眼的事务码很多做运维的同事平时只碰过PFCG压根不知道/ui2/flpd_cust能打开配置界面。即便打开了左侧导航里有Tiles、Catalogs、Groups、Target Mappings好几个标签页不熟悉的人往往会在不该选的页签里翻半天。第二不同系统版本的界面有差异。S/4HANA 1909、2020、2021这些版本里Fiori Launchpad Designer的布局会略微不同有的版本磁贴标题和Tile Key显示在同一行有的版本需要点进去才看得到。如果只看网上零散的教程对不上自己的系统版本就会一脸懵。第三排障现场往往不是“看ID”这么简单。比如用户报“某个磁贴消失了”你即使找到了Tile ID还要继续查这个磁贴属于哪个Catalog再查PFCG角色有没有分配这个Catalog。这就涉及到跨模块、跨界面的知识很多人卡在中间不知道下一步怎么办。所以这篇文章不只是在说“怎么把ID抄出来”而是把从定位到使用的一整条链路讲透。2. 界面操作在Launchpad Designer中定位Tile ID的三种方法2.1 方法一从Tiles标签页直接搜索定位最直接的方式就是打开Fiori Launchpad Designer的磁贴列表按标题或Tile Key搜索。打开事务码/UI2/FLPD_CUST系统会启动Launchpad Designer的维护界面。左侧标签页选“Tiles”你会看到一个可搜索的列表。页面上方有搜索框可以输入Tile标题的一部分也可以输入Tile Key的一部分进行模糊搜索。搜索结果会列出磁贴的标题、Tile Key、所属目录等信息。这里有一个细节如果你在“Tiles”列表里看到某个磁贴但不确定是不是用户报的那个可以先双击打开磁贴详情。详情页里除了Tile Key还能看到这个问题磁贴对应的Target Mapping、配置参数、应用链接等信息。把这些信息截个图存进工单后面排查会方便很多。不过在实际项目里客户的标准目录里可能有几千个磁贴如果只是知道标题里的某个单词直接搜Tiles列表往往也能命中但效率不高。更推荐先确认用户看到磁贴的标题和分组区域再决定用哪个搜索维度和关键词。2.2 方法二从Group或Catalog反向追踪这个方法比第一种更适合“用户说某个区域里有个磁贴有问题”的场景。用户反馈问题的时候通常会告诉你“我启动板里‘采购审批’那个栏目下有个磁贴点不动”。这时候你其实应该先找到对应的Group再在Group里定位到这个磁贴这样能直接看到它所属的Catalog和Tile ID。操作步骤是这样的打开/UI2/FLPD_CUST进入“Groups”标签页。搜索用户提到的栏目名称比如“采购审批”。打开这个Group里面会列出该区域下已经分配的磁贴。点中目标磁贴在配置里查看它的Tile Key以及它引用的Catalog。这种反向追踪方式最大的好处是你不仅拿到了Tile ID还同时确认了“这个磁贴在哪个Group里”这对于后续判断“为什么只有部分用户能看到”非常关键。2.3 方法三通过Target Mapping校验磁贴的绑定关系有时候用户报的问题不是“磁贴不见了”而是“点了没反应”或者“跳到了错误的应用”。这种情况下光找到Tile ID还不够你还需要确认Tile绑定的Target Mapping是否正确。在Launchpad Designer的“Target Mappings”标签页里你可以按Semantic Object Action搜索也可以直接按Tile Key反查。打开目标映射详情能看到它导航到哪个应用App ID、请求方式是哪种以及附加的参数。大多数磁贴导航问题都是因为Semantic Object或Action的配置和前端应用不匹配导致的。这个方法里有一个经验值得记下来同一个Semantic Object Action可以关联多个不同的Tile也可以被多个Tile引用反过来一个Tile只能绑定一个Target Mapping。如果系统里存在多个Target Mapping指向同一组Object Action而且参数不同磁贴的实际跳转行为取决于匹配规则。排查这类问题仅盯Tile ID是找不到答案的必须结合Target Mapping一起看。3. 数据层反查用SE16N和后台表确认Tile ID3.1 关键表/UI2/TILE界面操作能解决80%的问题但有些场景必须在数据层确认。比如要写批量脚本、要做数据迁移或者用户反馈的磁贴根本不在Launchpad Designer的可视化列表里可能是数据被改乱了。这时我们就要直接看后台表。SAP Fiori的磁贴配置核心标准表是/UI2/TILE。通过SE16N或SE16进入这张表可以按标题关键字、TILEKEY字段进行模糊查询。表格结构通常包含Tile Key、标题、描述、图标、目录关联等字段。不过要注意的是不同版本的表结构可能略有差异具体字段名以系统里的数据元素为准。用表查询的好处是可以做组合过滤。比如我想找所有标题包含“Approval”且Tile Key以“Z”开头的磁贴我可以在SE16N里同时设置两个过滤条件一次性筛出来比在界面上一个个看高效得多。3.2 通过Tile ID关联出Catalog和Group拿到Tile ID不是终点更常见的是要反查这个磁贴被挂到了哪些Catalog和Group下。在/UI2/TILE表里有字段会关联到Catalog键值而Group与Tile之间的关联也有对应的标准表。在项目实操中我更习惯直接在SE16N里查看/UI2/TILE然后通过Tile Key去关联关系表这里不展开每一张表的字段清单因为不同版本的SAP Fiori底层表的使用方式会有差异但查询思路是通用的。如果不太熟悉这些表的字段有一个更稳妥的办法在Launchpad Designer中搜索到目标磁贴后直接看“Catalogs”选项卡里列出了哪些目录。这种方式虽然慢一点但不容易出错适合刚开始接触数据表的同事。3.3 数据表操作的安全提醒在后台表里查看数据时有几个坑必须提醒一下第一只建议用SE16N或SE16做查询不建议直接修改。/UI2/TILE这类配置表在系统里属于Fiori基础配置一旦改错可能导致整批磁贴在Launchpad里消失或重复。如果一定要调整请走正常的配置传输流程而不是在表里硬改。第二表里的数据可能有多语言文本。如果你的系统是英文环境但客户用中文登录可能会出现表里查得到、界面上看不到的情况这不一定是你找错了Tile ID而是语言参数导致的显示差异。用标题关键字查询时尝试用英文关键词多搜一次。第三Fiori相关配置在系统中有时会存在缓存。你在后台表里看到的数据和前端Launchpad实际渲染出来的内容不一定立即一致。改完配置后通常需要执行缓存清理或等待缓存刷新。不要拿着表里的数据跟前端页面逐字对比发现对不上就慌。4. 前端排障辅助从浏览器调试信息反查Tile ID4.1 在Network请求里搜索TileKey有些时候用户报的磁贴问题只在某个特定客户端复现你自己打开Launchpad Designer却一切正常。这种情况就不要只盯着配置界面了要从前端运行的实际情况入手。打开浏览器按F12进入开发者工具切到Elements或Sources面板。先在Launchpad页面上找到报错的磁贴右键选择“检查”查看对应元素的ID和数据属性。有些前端版本的Fiori页面磁贴的HTML节点会带有> SAP Fiori Launchpad磁贴定位与排障：掌握Tile ID是关键
做SAP Fiori项目这几年接到过不少Launchpad相关的工单一半以上都和磁贴Tile有关。要么是某张磁贴不显示要么是点完报错要么是同一个应用出现两遍再要么是用户说“我的启动板里多了一个图标”。排查这类问题第一步往往不是去看ABAP代码也不是去盯网关服务而是先把Tile ID找出来。可偏偏就是这一步卡住了不少人——明明在Launchpad Designer里看到了对应的磁贴却不知道它的唯一标识藏在哪一栏更不知道这个ID拿到手之后后面该怎么用。这篇文章是给Fiori顾问、BASIS、ABAP开发以及做Fiori项目运维的同行看的。如果你正在做S/4HANA的启动板配置或者已经投入到Fiori项目的运维支持里那文中的思路基本可以拿来直接用。我会从三个层面展开先在界面上把Tile ID的获取路径摸清楚再从数据层说明如何反查最后用一个项目排障的完整案例把这些操作串起来。这样即便你之前没怎么用过Launchpad Designer也能少走几步弯路。我先把话放在前面定位Tile ID本身不是什么高深技术真正考验人的是你拿到这个ID之后如何判断它是哪个Catalog里的、对应哪个Target Mapping、分配给了哪几个业务角色。这套排查逻辑才是这篇内容的重点。1. 理解Tile ID先搞清楚启动板里的“门牌号”体系1.1 Fiori Launchpad的层级关系Fiori Launchpad不是简单地把一堆网址堆在页面上它有一套完整的配置层级。从高到低大致是这样业务角色Business Role在PFCG里维护决定用户登录后能看到哪些内容。目录Catalog一组磁贴和相关应用的集合属于逻辑分组可以理解为“内容容器”。分组Group实际展示在Launchpad页面上的栏位或Section。同一个Catalog下的Tile可以被分配到不同的Group里。磁贴Tile用户看到的每一个图标和标题组合是交互的入口。目标映射Target Mapping磁贴点击后实际触发的导航目标通过Semantic Object和Action来定义。这个层级我打过一个比方Catalog就像仓库里的货架区Group是仓库对应的门店展台Tile是展台上的商品而Target Mapping是贴在商品上的配送单告诉系统“把这件商品送到哪个门店、哪个位置”。权限配置时角色把一个Catalog分配给用户用户才能看到这个Catalog下的Tile而Group则控制这些Tile在页面上怎么摆放、放在哪个区域。理解这个链条后你就能明白一个核心结论Tile ID只是磁贴的“身份标识”它本身不决定权限也不决定导航。但如果这个ID抓不准后面所有的排障操作都会跑偏。1.2 Tile ID到底是个什么东西Tile ID在系统里对应的字段名通常是Tile Key。它是一段全局唯一的字符串用来在系统内部标识一个磁贴配置。不同系统的Tile ID命名风格不太一样有的是SAP标准预置ID看起来像是一串有规律的英文加下划线比如ap_pa_approve_tile这种风格有的是客户在项目里自定义的可能类似zmm_purchase_order_tile还有早期系统自动生成的可能是一长串字符或由系统内部命名规则生成。在Launchpad Designer界面中这个ID通常显示为“Tile Key”或“ID”在磁贴的详情页面能看到。很多人第一次接触时会误以为磁贴标题就是ID其实标题可以重复、可以改但Tile Key必须在同一个系统里唯一。所以排查问题、做配置传输、写脚本批量修改时都要以Tile Key为准。1.3 为什么定位Tile ID会成为“高频问题”既然只是找一个字段为什么能成为Fiori群里常问的问题我观察下来主要有三个原因第一界面入口隐蔽。Fiori Launchpad Designer本身不是一个很显眼的事务码很多做运维的同事平时只碰过PFCG压根不知道/ui2/flpd_cust能打开配置界面。即便打开了左侧导航里有Tiles、Catalogs、Groups、Target Mappings好几个标签页不熟悉的人往往会在不该选的页签里翻半天。第二不同系统版本的界面有差异。S/4HANA 1909、2020、2021这些版本里Fiori Launchpad Designer的布局会略微不同有的版本磁贴标题和Tile Key显示在同一行有的版本需要点进去才看得到。如果只看网上零散的教程对不上自己的系统版本就会一脸懵。第三排障现场往往不是“看ID”这么简单。比如用户报“某个磁贴消失了”你即使找到了Tile ID还要继续查这个磁贴属于哪个Catalog再查PFCG角色有没有分配这个Catalog。这就涉及到跨模块、跨界面的知识很多人卡在中间不知道下一步怎么办。所以这篇文章不只是在说“怎么把ID抄出来”而是把从定位到使用的一整条链路讲透。2. 界面操作在Launchpad Designer中定位Tile ID的三种方法2.1 方法一从Tiles标签页直接搜索定位最直接的方式就是打开Fiori Launchpad Designer的磁贴列表按标题或Tile Key搜索。打开事务码/UI2/FLPD_CUST系统会启动Launchpad Designer的维护界面。左侧标签页选“Tiles”你会看到一个可搜索的列表。页面上方有搜索框可以输入Tile标题的一部分也可以输入Tile Key的一部分进行模糊搜索。搜索结果会列出磁贴的标题、Tile Key、所属目录等信息。这里有一个细节如果你在“Tiles”列表里看到某个磁贴但不确定是不是用户报的那个可以先双击打开磁贴详情。详情页里除了Tile Key还能看到这个问题磁贴对应的Target Mapping、配置参数、应用链接等信息。把这些信息截个图存进工单后面排查会方便很多。不过在实际项目里客户的标准目录里可能有几千个磁贴如果只是知道标题里的某个单词直接搜Tiles列表往往也能命中但效率不高。更推荐先确认用户看到磁贴的标题和分组区域再决定用哪个搜索维度和关键词。2.2 方法二从Group或Catalog反向追踪这个方法比第一种更适合“用户说某个区域里有个磁贴有问题”的场景。用户反馈问题的时候通常会告诉你“我启动板里‘采购审批’那个栏目下有个磁贴点不动”。这时候你其实应该先找到对应的Group再在Group里定位到这个磁贴这样能直接看到它所属的Catalog和Tile ID。操作步骤是这样的打开/UI2/FLPD_CUST进入“Groups”标签页。搜索用户提到的栏目名称比如“采购审批”。打开这个Group里面会列出该区域下已经分配的磁贴。点中目标磁贴在配置里查看它的Tile Key以及它引用的Catalog。这种反向追踪方式最大的好处是你不仅拿到了Tile ID还同时确认了“这个磁贴在哪个Group里”这对于后续判断“为什么只有部分用户能看到”非常关键。2.3 方法三通过Target Mapping校验磁贴的绑定关系有时候用户报的问题不是“磁贴不见了”而是“点了没反应”或者“跳到了错误的应用”。这种情况下光找到Tile ID还不够你还需要确认Tile绑定的Target Mapping是否正确。在Launchpad Designer的“Target Mappings”标签页里你可以按Semantic Object Action搜索也可以直接按Tile Key反查。打开目标映射详情能看到它导航到哪个应用App ID、请求方式是哪种以及附加的参数。大多数磁贴导航问题都是因为Semantic Object或Action的配置和前端应用不匹配导致的。这个方法里有一个经验值得记下来同一个Semantic Object Action可以关联多个不同的Tile也可以被多个Tile引用反过来一个Tile只能绑定一个Target Mapping。如果系统里存在多个Target Mapping指向同一组Object Action而且参数不同磁贴的实际跳转行为取决于匹配规则。排查这类问题仅盯Tile ID是找不到答案的必须结合Target Mapping一起看。3. 数据层反查用SE16N和后台表确认Tile ID3.1 关键表/UI2/TILE界面操作能解决80%的问题但有些场景必须在数据层确认。比如要写批量脚本、要做数据迁移或者用户反馈的磁贴根本不在Launchpad Designer的可视化列表里可能是数据被改乱了。这时我们就要直接看后台表。SAP Fiori的磁贴配置核心标准表是/UI2/TILE。通过SE16N或SE16进入这张表可以按标题关键字、TILEKEY字段进行模糊查询。表格结构通常包含Tile Key、标题、描述、图标、目录关联等字段。不过要注意的是不同版本的表结构可能略有差异具体字段名以系统里的数据元素为准。用表查询的好处是可以做组合过滤。比如我想找所有标题包含“Approval”且Tile Key以“Z”开头的磁贴我可以在SE16N里同时设置两个过滤条件一次性筛出来比在界面上一个个看高效得多。3.2 通过Tile ID关联出Catalog和Group拿到Tile ID不是终点更常见的是要反查这个磁贴被挂到了哪些Catalog和Group下。在/UI2/TILE表里有字段会关联到Catalog键值而Group与Tile之间的关联也有对应的标准表。在项目实操中我更习惯直接在SE16N里查看/UI2/TILE然后通过Tile Key去关联关系表这里不展开每一张表的字段清单因为不同版本的SAP Fiori底层表的使用方式会有差异但查询思路是通用的。如果不太熟悉这些表的字段有一个更稳妥的办法在Launchpad Designer中搜索到目标磁贴后直接看“Catalogs”选项卡里列出了哪些目录。这种方式虽然慢一点但不容易出错适合刚开始接触数据表的同事。3.3 数据表操作的安全提醒在后台表里查看数据时有几个坑必须提醒一下第一只建议用SE16N或SE16做查询不建议直接修改。/UI2/TILE这类配置表在系统里属于Fiori基础配置一旦改错可能导致整批磁贴在Launchpad里消失或重复。如果一定要调整请走正常的配置传输流程而不是在表里硬改。第二表里的数据可能有多语言文本。如果你的系统是英文环境但客户用中文登录可能会出现表里查得到、界面上看不到的情况这不一定是你找错了Tile ID而是语言参数导致的显示差异。用标题关键字查询时尝试用英文关键词多搜一次。第三Fiori相关配置在系统中有时会存在缓存。你在后台表里看到的数据和前端Launchpad实际渲染出来的内容不一定立即一致。改完配置后通常需要执行缓存清理或等待缓存刷新。不要拿着表里的数据跟前端页面逐字对比发现对不上就慌。4. 前端排障辅助从浏览器调试信息反查Tile ID4.1 在Network请求里搜索TileKey有些时候用户报的磁贴问题只在某个特定客户端复现你自己打开Launchpad Designer却一切正常。这种情况就不要只盯着配置界面了要从前端运行的实际情况入手。打开浏览器按F12进入开发者工具切到Elements或Sources面板。先在Launchpad页面上找到报错的磁贴右键选择“检查”查看对应元素的ID和数据属性。有些前端版本的Fiori页面磁贴的HTML节点会带有>