抹茶柚子冰在 SAP Fiori Launchpad 里找一个 Tile ID，听起来像是个一次性小操作，但真碰上了你会发现：有人是开发要做扩展，有人是 Basis 要配权限，还有人是做集成方案时需要拿到准确的 App 标识。问题是 Fiori Launchpad 不像传统 SAP GUI 那样，右键就能看到对象属性，想定位一个 Tile ID 往往要在前端配置、目录（Catalog）和角色（Role）之间来回倒腾。这篇文章就把我这些年常用的排查路径完整梳理一遍，从浏览器 F12 日志入手，再到后台目录和角色配置，最后附上常见问题速查，希望能帮正在被这件事卡住的同行节省点时间。
先说清楚一个概念：Fiori Launchpad 里的 Tile，本质上是一个入口卡片，它背后挂着的是一组配置，包括 target 映射、semantic object、action 以及所属于哪个 Catalog。所以在查 Tile ID 前，先把这几个名词在脑子里对齐一下，操作起来不会乱。
1. 为什么要在意 Tile ID：三个真实场景与概念对齐
1.1 三种高频场景：配置、授权、二次开发
我接触到的找 Tile ID 需求，基本可以归成三类。
第一类是 Fiori 管理员做 Launchpad 配置。比如用户说某个 App 不见了，或者想让某个 Tile 在特定用户组里显示，就必须先确认这个 Tile 在哪个 Catalog 里、它的 ID 是多少，然后在 Launchpad Designer 或者通过目录配置去调整归属。没有 Tile ID，甚至连从哪个目录查起都不知道。
第二类是权限配置。Fiori 的权限模型和传统 R/3 差别很大，在 PFCG 里面给用户分配的是“Catalog + Group”的组合，而不是简单给一个事务代码。如果用户反映“App 能搜到但点开报错”或者“完全看不到这个入口”，你要在角色里排查，就得知道这个 App 对应的 Tile 属于哪个 Catalog，然后才能去检查角色里是否也分配了这个目录。这中间绕不开 Tile ID。
第三类是开发侧。SAPUI5 扩展开发、自定义 Tile、Workflow 配置、或者通过 API 去读取 Launchpad 配置时，代码里需要显式引用 Tile ID。我见过不少开发同学在代码里写死了一个看起来像 UUID 的字符串，结果换了环境就失效，原因就是没有真正搞清楚这个 ID 是从哪来的、由谁生成的。
1.2 Tile ID 和 Target、Semantic Object 的区别
这三个概念容易混淆，实际操作中经常因为名字对不上而浪费半天时间。
Tile ID 是 Launchpad 配置里那条磁贴记录的唯一标识，它指向一个具体的前端展示单元。Target 则是 App 加载时的内部导航目标，通常由 semantic object + action 组合而成。Semantic Object 是业务语义对象，例如 “PurchaseOrder”，“SalesOrder”，Action 是对象上的操作，例如 “Display”、“Create”。三者是按层级关联的：一个 Tile 包含一个 Target，一个 Target 由 Semantic Object 和 Action 推导出来。在 Launchpad Designer 里你能同时看到这三列。
| 名称 | 层级 | 作用 | 常见出现位置 |
|---|---|---|---|
| Tile ID | 最外层 | 唯一标识一张磁贴 | Launchpad Designer / 配置表 |
| Semantic Object | 中间层 | 业务语义分类 | Target 配置 / URL 参数 |
| Action | 最内层 | 具体操作行为 | Target 配置 / URL 参数 |
所以当你拿着一个语义对象名字（比如“SalesOrder”）去找 Tile ID 时，得先确认它是不是唯一对应的。同一个语义对象可能对应多个 Tile（比如一个创建、一个显示），这时只能靠上下文去判断到底要找哪一个。搞清楚这层关系，下面所有排查步骤的思路就顺了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 前端日志三板斧：用浏览器拿到 Tile ID 的第一手证据
2.1 F12 Network 抓取 FLP 配置请求
在 Fiori Launchpad 页面里按 F12 打开开发者工具，切到 Network 标签，页面刷新一下，就能看到浏览器向后端发起的各种请求。FLP 启动时，前端会请求配置服务来获取当前用户可见的 Tile 列表、Catalog 列表和 Group 信息。这些请求通常集中在 /sap/bc/ui2/ 路径下，最典型的是 /sap/bc/ui2/flp 这个入口。
一个容易踩的坑：如果你不勾选 Preserve log、直接在已经打开的状态下切换用户或重新加载配置，可能啥也抓不到。建议操作顺序是：先打开 F12 → 勾选 Preserve log → 再按 F5 刷新页面。如果请求数量太多，可以直接在 Network 的过滤框里输入 flp 或 catalog，把范围收敛到跟 Launchpad 配置相关的请求上。
这里贴一个典型的请求 URL 样例，不同系统可能有些差异，但整体结构类似：
text复制/sap/bc/ui2/flp?sap-client=100&sap-language=EN
响应体通常是 JSON，里面会返回当前用户所有可见的 App 配置，包括 Tile ID、Title、Semantic Object、Action、Catalog 归属等信息。这个响应是前端渲染的数据源，也是我们在浏览器侧能拿到的第一手“官方数据”。如果你在后端版本较低的环境里，响应结构可能略有不同，但核心字段基本一致。
2.2 在响应体里精准定位 Tile ID
拿到响应后，直接在 Network 里点开那条请求，切到 Preview 或者 Response 标签，在响应的 JSON 里搜索关键词。我习惯先搜业务标题，比如用户报告“采购订单审批”这个 App 不见了，我就在响应里搜 PurchaseOrder 或者 Approval，这样能快速定位到对应的配置块。
以一个常见结构为例，你会看到类似下面的内容：
json复制{
"id": "F0013_Tile_1234",
"title": "Purchase Order Approval",
"semanticObject": "PurchaseOrder",
"action": "Approval"
}
这里的 id 字段就是我们需要的 Tile ID。有时也会写成 tileId，或者嵌套在一个 tile 对象里。另外，响应里除了当前用户的可见配置，还会列出目录信息，比如每个 Catalog 的 ID 和名称，这正好可以作为第三部分目录排查的输入。
如果响应太大、不好在浏览器里慢慢翻，可以直接用 Chrome 开发者工具里 Network 的 Search 功能（快捷键 Ctrl+Shift+F），输入标题关键词或语义对象名，就可以跳到包含这个关键词的那一行。这个功能比肉眼在响应里拖拽高效得多，尤其当响应体有几兆大小的时候，强烈推荐。
2.3 直接在页面上用 DOM/Console 取巧
除了 Network 之外，还有一个取巧的方式，适合只想快速拿到当前页面某个 Tile ID 的场景。在 Launchpad 页面上，鼠标右键点击目标 Tile，选择“检查”（Inspect），会直接定位到对应 DOM 元素。FLP 渲染出来的 Tile 通常会带有 data-* 属性或内部绑定 ID，但不同版本表现不一致，有的版本直接能看见，有的版本要往上翻几层父元素才能找到。
如果 DOM 里确实找不到，可以在 Console 里用一段小脚本提取当前页面所有 tile 相关的链接和 ID。下面是我常用的一个简单脚本，遍历页面上带 data-id 或 href 中带 sap-ui2 特征的元素：
javascript复制let tiles = document.querySelectorAll('[data-id], [class*="tile"]');
let result = [];
tiles.forEach(el => {
let id = el.dataset.id || el.getAttribute('data-id');
if (id) {
result.push({ title: el.innerText || '', id: id });
}
});
console.table(result);
这个方式不一定在所有系统版本里都有效，毕竟前端框架渲染产物会变，但作为一种辅助手段值得一试。真正可靠、可以复现的路径，还是回到第 2.2 节说的：从 FLP 配置请求的响应体里去取。前端日志的价值在于它是用户当前看到界面的真实快照，不受后台表结构差异影响，不管系统是 S/4HANA 还是 Suite on HANA，只要是标准 Fiori Launchpad，这个方法都通用。
3. 目录排查：从 Launchpad 配置端反向锁定 Tile 归属
3.1 用 Launchpad Designer 建一条“目录→Tile”的查找路径
拿到 Tile ID 之后，下一步通常是要确认它归属于哪个 Catalog。这里有一个很容易误导人的细节：Tile ID 和 Catalog ID 是两回事。Catalog 是一组 Tile 的集合，Tile 挂在 Catalog 下面，权限分配的最小单位之一是 Catalog，而不是单个 Tile。所以在角色配置里，你看到的是目录 ID / 目录名称，而不是 Tile ID。
在后台用事务代码 /UI2/FLP_DESIGNER 打开 Launchpad Designer，左边选到 Catalogs 页签，会列出当前系统的所有目录。点进某个 Catalog，右侧会显示其中的所有 Tile 和 Target 映射，Tile 的 ID 就在列表里。如果你手头已经有前端日志里拿到的 Tile ID，直接在 Catalog 页签的搜索框里搜这个 ID，就能反向找到它所属的目录。
目录命名通常带有业务含义，比如 SUPPLIER_INVOICING、PURCHASING_CATALOG 之类，但也有不少自定义目录是企业自己起的名字，从名字根本看不出业务语义。这种时候，从前端日志里拿到 Catalog ID 再去 Designer 里反查，会比从头到尾翻目录快得多。
实际操作中还有一个入口值得注意，事务代码 /UI2/FLP_CUS_CONF 也可以维护 Catalog 配置，它和 Designer 的区别在于：/UI2/FLP_CUS_CONF 偏向配置管理，能看到目录 ID 和描述、用途等字段；/UI2/FLP_DESIGNER 偏向可视化编辑，更适合鼠标点点点地查看 Tile 与 Catalog 的关系。两个事务代码配合使用，基本能覆盖目录排查的所有场景。
3.2 从后台表角度补充排查
如果你更习惯用 SE16N 去后台查表，也可以用表的方式补充排查。Fiori 配置相关的表在不同版本里表名有所差异，常见的有 /UI2/TILE、/UI2/PAGE_TILE、/UI2/CATALOG 等，但并不是每个系统都完全一样，我自己的习惯是用 SE16N 查 /UI2/TILE，如果报错或者查不到就换系统层面搜一下表名，或者直接用 Designer 界面看。
需要注意的是：不要在表里花太多时间。Fiori 的 Tile 配置缓存机制比较复杂，后台表里的内容不一定和前端实际渲染一致，查出来的数据未必真。一个靠谱的排障逻辑是：前端日志（用户实际看到什么）→ 后台目录配置（系统设计目标是什么）→ 权限角色（为什么用户看不到），按这个顺序走，表查询只作为补充而不是主导手段。
另外，如果系统启用了缓存（FLP 的配置服务一般是有缓存的），你在后台改了目录或 Tile 归属，前端不刷新就不生效。此时需要清缓存或者等缓存失效，具体方法在第四部分角色排查里会提到。记住一个原则：目录排查解决的是“这个 Tile 在哪里能配置”，而不是“用户为什么能看到它”，后者必须走到角色链路里才能查清楚。
4. 角色排查：权限链路不打通，有了 ID 也白搭
4.1 前端“角色”与 PFCG 权限角色的关系
Fiori 里头谈到“角色”，要区分两个层面。第一层是前端 Launchpad 的 Group（用户组），它决定的是用户登录后首页能看到哪几个分组的 Tile；第二层是 PFCG 权限角色，它决定了用户的后端权限和可访问的 Catalog 范围。平时我们说的“给用户分配角色”，在 Fiori 项目里通常是指 PFCG 角色里同时包含权限部分和 Fiori 目录部分。
为什么这个关系重要？因为很多排查场景是“用户反馈在 Launchpad 里看不到某个 Tile”，这种问题十有八九不是 Tile 配置本身的问题，而是 PFCG 角色里没有分配该 Tile 所在的 Catalog。前端日志里给的是“用户当前可见”的信息，你拿它定位到 Tile ID、再定位到 Catalog ID，最后去 PFCG 里看角色是否包含这个 Catalog——这一步才是闭环。
还要注意一个常见误解：用户登录后的 Group 是可以在前端个人化设置里变动的前端展示层面，而 Catalog 跟权限强绑定。一个用户即使后来通过 URL 直接访问某个 App 的入口，如果没有对应 Catalog 分配，后端权限也会拦截掉对后端服务的访问，表现出来就是登录后看不到 Tile，或者从 URL 直接访问时报权限错误。
4.2 把 Tile 与 PFCG 角色对上的操作步骤
实际操作时，我会用事务代码 PFCG 打开目标角色，在 Menu 页签下，左边选择“SAP Fiori”节点，然后添加 Catalog 引用。一般情况下是用事务代码 /UI2/FLP_CUS_CONF 先去确认 Catalog ID，然后在 PFCG 里用这个 ID 去勾选对应的目录。
路径大致是：PFCG 打开角色 → 菜单页签 → 右侧“添加”按钮 → 选择“SAP Fiori → 添加目录”→ 在弹出的对话框里按 Catalog ID 搜索并添加。保存后，如果用户仍然看不到，就要考虑缓存和后台同步的问题。
这里有一个比较隐蔽的点：PFCG 角色里的 Fiori 目录并不是简单的“所见即所得”同步，它要把目录内容映射到 PFCG 菜单树里，再由后台的 Launchpad 服务计算最终的用户可见列表。这个链路里任何一步缓存没刷新，都会导致前端数据不对。
通用做法是执行事务代码 /UI2/SYNC（部分系统里也叫 /UI2/CACHE，版本不同入口不同），或者通过 SMICM 在 ICM 层面刷新缓存。我自己习惯的做法是：改了角色后，先在 PFCG 里重新生成角色、保存并传输，然后去 /UI2/SYNC 同步一下，再让用户重新登录。如果用户的浏览器端还有旧页面缓存，直接让它关闭浏览器重开，或者 Ctrl+F5 强制刷新一次，而不是让用户在已经开着的页面上反复点刷新。
4.3 用户看不到 Tile 时的权限排查顺序
当用户报告看不到某个 Tile，我推荐按下面的顺序过一遍：
- 用用户账号打开 Launchpad，F12 看配置请求的响应里有没有这个 Tile。如果没有，说明用户的可见配置里压根没有它，这时就去角色链路查。
- 在
/UI2/FLP_DESIGNER里搜到这个 Tile 的 Catalog ID，确认它在中后端配置里正常存在。 - 用 SU01 查看用户主数据，确认它分配了哪些 PFCG 角色。
- 逐个检查 PFCG 角色是否包含对应 Catalog，注意 Catalog 可能包含在父角色或复合角色里。
- 如果有多个角色，注意 Catalog 之间的叠加关系。Fiori 的角色分配是并集关系，一个 Catalog 只要在任何一个角色里被分配，用户就应该能看到。
还有一个在项目里踩过坑的点：用户主数据里“用户类型”的设置。SAP 里 Fiori 用户要求用户类型不能是 Dialog，一般是 Service 或者 Communication。如果用户类型设置错误，即使角色和目录都分配了，前端也可能不显示。很多新手排查了半天角色，结果问题出在 SU01 里一个下拉框。
另外，在 PFCG 角色里添加 Fiori 目录时，记得检查角色的“事务代码”权限是不是完整。有些 Fiori App 不仅要看到 Tile，还要后端 OData 服务的权限，否则会出现“Tile 看得到，点进去 500”的诡异问题。这种问题在前端日志里会有明显报错，排查方向和 Tile ID 本身就不一样了。
5. 常见问题与排查技巧实录
5.1 典型症状速查表
把常见问题和排查方向整理成一张速查表，方便现场排障时对照：
| 症状 | 可能原因 | 排查方向 |
|---|---|---|
| 用户完全看不到某个 Tile | 角色未分配对应 Catalog | Tcode /UI2/FLP_DESIGNER 找 Catalog，PFCG 检查角色 |
| 前端能看到 Tile，但点击报权限错误 | OData 服务权限缺失 | SU53 检查权限报错，补齐后端服务授权 |
| 后台修改了 Tile 配置，前端不变化 | 缓存未刷新 | /UI2/SYNC 同步，清浏览器缓存 |
| Network 里找不到 FLP 配置请求 | 浏览器缓存了旧配置或过滤条件问题 | 勾选 Disable cache，重新刷新页面 |
| 拿到了 Tile ID 但在 Designer 里搜不到 | 跨系统或跨客户端查错对象 | 确认客户端和系统环境一致，检查目录 ID 而不是 Tile ID |
| URL 直接访问能打开，但 Launchpad 不显示 | Tile 未分配到用户可见 Group | 检查 Group 配置，或在用户个人化设置里添加 |
这张表不能覆盖所有情况，但能覆盖我遇到过的 80% 问题。排障时建议先看前端日志，再查目录，最后查角色，不要一上来就翻后台表，那样很容易绕远路。
5.2 几个实战心得
分享几个只有真正操作过才体会得到的细节。
第一个是：尽量用“Tile Title + Semantic Object + Action”三个字段组合来确认身份，不要只依赖 Tile ID 或只管语义对象名。因为 Tile 的 ID 在不同系统导入时可能会变，而语义对象名比较稳定。如果你要写跨环境的交付文档，建议把三列都标注出来，别人照着做才不会对不上号。
第二个是：配置请求的响应里如果数据量特别大，可以通过添加自定义参数缩小范围。有些系统支持在后端通过用户过滤、通过目录类型过滤，但每个项目差异大，需要自己看运维文档。我试过最多的情况是直接搜索业务标题关键词，快、直接，命中率高。
第三个是：改完配置最终确认时，不要只用 IT 管理员的账号去看，一定要用一个最终用户账号去验证。管理员账号往往会自动包含一些额外权限，看到的结果不代表用户视角。我在项目里不只一次遇到管理员说“我能看到啊”，结果换了个测试账号就完全不一样，最后还是靠 F12 日志定位到用户角色差异。
5.3 从前端日志到目录再到角色的完整链路怎么串
从头到尾串一次这个完整链路，你可以在纸上画一条线：浏览器 F12 抓配置请求 → 响应体里拿 Tile ID 和 Catalog ID → 后台 Designer 里按 Catalog ID 找到目录配置 → PFCG 角色里核对目录是否分配 → SU01 确认用户类型和角色分配 → 清缓存 → 用户重新登录验证。每一步的输入输出都是上一个步骤的输出，链条是唯一的。
前端日志是最接近用户真实体验的一层，目录配置是系统的设计意图，角色则是权限是否被正确授予的关键。三者对齐了，Tile ID 的问题就彻底解决了。
最后再多说一句：Fiori Launchpad 的排查，本质上就是对“前、中、后”三层的状态一致性检查。不管问题看起来多复杂，先把用户实际看到什么固化下来，再往后台追溯，这条路几乎不会走偏。遇到搞不定的情况，别急着改配置，先多看几遍 F12 日志，很多答案已经在里面了。