SAP Fiori白屏根因解析：OData服务注册与网关权限全链路排查

发布时间：2026/11/3 8:30:47
SAP Fiori白屏根因解析：OData服务注册与网关权限全链路排查

1. 这不是一份“说明书”，而是一份白屏现场抢救记录

你刚配完SAP Fiori Launchpad，浏览器一刷新——一片纯白。没有错误提示，没有加载动画，连F12控制台都安静得像关了机。你翻遍官方文档，查了十几篇博客，发现所有人写的都是“按步骤操作即可”，可偏偏你的环境就是卡在第7步不动。这不是配置失败，是系统在沉默中拒绝沟通。

这就是我写这份手册的起点：它不叫《Fiori配置指南》，它叫《从Launchpad白屏到OData服务注册的完整指南》。标题里两个关键词，“白屏”和“OData服务注册”，不是并列关系，而是因果链——90%以上的白屏问题，根源不在UI5前端，而在后端OData服务根本没被正确识别、注册或授权。你看到的是前端白板，实际是后端断联。

核心关键词“SAP Fiori配置”背后藏着三层真实需求：第一层是运维人员要快速恢复用户访问；第二层是ABAP开发人员要确保自定义CDS视图能被前端消费；第三层是系统架构师要厘清Gateway、Backend、Frontend三端之间到底谁该向谁注册、谁该给谁授权、谁又在哪个环节偷偷加了拦截。这三类人打开同一份文档，看到的应该是三套不同视角的路径图，而不是一套通用流程。

我试过用标准事务码/IWFND/MAINT_SERVICE直接注册服务，结果前端依然白屏；也试过把/IWFND/GW_CLIENT里的所有服务全打勾，反而触发了权限风暴。真正起效的，是一次在/IWFND/ERROR_LOG里逐条翻出的HTTP 403响应，它指向一个被忽略的SICF节点权限缺失。所以这份手册不会教你“点哪里”，而是告诉你“为什么点这里会生效”、“不点这里会死在哪一步”、“日志里哪一行字才是真正的判决书”。它适配三类读者：刚接手Fiori运维的新人（需要明确每一步的验证动作）、正在调试CDS暴露逻辑的ABAP开发者（需要知道CDS视图如何映射为OData实体）、以及负责跨系统集成的架构师（需要看清Gateway中间件的真实路由逻辑）。接下来的内容，每一句都来自某次凌晨三点的生产环境排障现场。

2. 整体设计思路：为什么必须绕开“标准流程”走野路

2.1 标准配置流程的三大幻觉陷阱

几乎所有官方文档和培训材料都默认一个前提：你的系统是全新安装、无定制、无补丁冲突、无权限继承异常的“理想模型”。但现实中的Fiori环境，99%都踩在三个幻觉陷阱上：

幻觉一：“注册服务=前端可见”
你以为在/IWFND/MAINT_SERVICE里勾选了服务，Launchpad就能自动发现它？错。Fiori Launchpad的Tile Catalog不是扫描已注册服务列表，而是读取/UI2/CHIP表中预定义的catalog条目。这个表的数据来源有两个：一是通过/UI2/CHIP_CATALOG事务码手动维护，二是通过/UI2/CHIP_CATALOG_GEN后台作业自动生成——但该作业只扫描/IWFND/MAINT_SERVICE中状态为“Active”的服务，且要求服务元数据（$metadata）能被Gateway服务器自身成功解析。如果CDS视图里用了@EndUserText.label但未维护语言文本，元数据解析就会静默失败，服务状态卡在“Registered”而非“Active”，Catalog生成作业就直接跳过它。你看到的白屏，其实是Catalog压根没把它编进去。

幻觉二：“Gateway配置一次搞定”
/IWFND/MAINT_SERVICE只是服务注册入口，真正的路由控制在SICF节点。每个OData服务对应一个SICF路径，如/sap/opu/odata/sap/ZMM_MATERIAL_SRV。但这个路径能否被外部访问，取决于其父节点/sap/opu/odata/sap/的激活状态和权限设置。更隐蔽的是，SAP在7.52+版本引入了“Service Binding”机制：同一个物理服务可以绑定多个逻辑别名（如ZMM_MATERIAL_SRV_V1和ZMM_MATERIAL_SRV_V2），每个别名对应独立的SICF节点和权限对象。如果你只激活了主路径却忘了绑定别名的SICF节点，前端调用别名时就会返回404，而控制台只显示“Failed to load resource”，连具体URL都不给你看全。

幻觉三：“权限配置=勾选标准角色”
标准角色SAP_UI2_USER_700确实包含基础Launchpad访问权，但它不包含任何OData服务的执行权限。OData服务权限由两层组成：第一层是SICF节点访问权（事务码SICF中为节点分配S_ICF权限对象），第二层是服务级数据权限（事务码PFCG中为角色分配S_RFC权限对象，并在“Activity”字段填入EXECUTE，在“RFC Destination”字段填入服务对应的RFC目的地名称，通常是LOCAL或GW_CORE）。漏掉任意一层，前端请求都会在网关层被拦截，返回403且不写详细错误。而/IWFND/ERROR_LOG里只会记下“Authorization check failed”，不会告诉你缺的是SICF还是RFC权限。

2.2 本手册的“野路”设计逻辑：以日志为路标，逆向推导故障点

既然标准流程不可靠，我们就放弃“正向配置”，改用“逆向溯源”。整个手册的骨架基于Fiori请求的真实生命周期：

  1. 前端发起请求→ 浏览器向/sap/bc/ui5_ui5/sap/zfiori_launchpad/index.html发起GET
  2. Launchpad加载Catalog→ 调用/sap/opu/odata/UI2/CHIP获取Tile列表
  3. 用户点击Tile→ Launchpad根据Tile定义的targetMapping，向对应OData服务URL发起GET（如/sap/opu/odata/sap/ZMM_MATERIAL_SRV/MaterialSet?$top=20）
  4. Gateway路由→/IWFND/...前缀被SICF节点捕获，转发至Backend系统
  5. Backend处理→ ABAP程序执行CDS查询，返回JSON数据

白屏只可能发生在第2步（Catalog为空）或第3步（Tile点击后无响应）。因此，我们的排查必须从这两步的日志源头切入：

  • Catalog空问题→ 查/UI2/CHIP_CATALOG_GEN作业日志 +/IWFND/ERROR_LOG中CHIP相关错误
  • Tile调用失败问题→ 查/IWFND/ERROR_LOG中ZMM_MATERIAL_SRV相关错误 +SM21系统日志中RFC调用记录

这种设计让手册彻底脱离“先装什么再配什么”的线性思维，转为“看到什么现象，立刻查哪条日志，对应改哪个配置”的反射式操作。比如，当你在浏览器控制台看到GET https://<host>/sap/opu/odata/sap/ZMM_MATERIAL_SRV/$metadata 404 (Not Found)，手册会直接跳转到“SICF节点未激活”章节，而不是让你从头检查Gateway配置。

2.3 工具链选择：为什么只用原生事务码，不用第三方工具

市面上有若干Fiori配置辅助工具，但我在三个客户现场验证过：它们要么过度封装导致关键参数不可见（如隐藏SICF节点路径），要么在权限校验时绕过真实RFC调用（用模拟数据代替真实Backend响应）。本手册坚持使用SAP原生事务码，原因有三：

  • 事务码/IWFND/ERROR_LOG是唯一能捕获网关层完整HTTP状态码的地方。浏览器控制台只显示404/403，但/IWFND/ERROR_LOG会记录完整的请求头、响应头、后端系统返回的RFC错误码（如RFC_ERROR_SYSTEM_FAILURE），这是定位Backend侧问题的黄金线索。

  • 事务码SM21系统日志能验证RFC调用是否真正抵达Backend。当/IWFND/ERROR_LOG显示“Connection refused”，你需要立刻查SM21里是否有RFC destination ZMM_MATERIAL_SRV not found记录。如果SM21里完全没这条RFC调用痕迹，说明请求根本没离开Gateway，问题一定在SICF或服务注册状态；如果SM21里有调用但返回SY-SUBRC = 4，那就要去Backend系统查CDS视图语法错误。

  • 事务码SU53权限追踪是唯一能区分SICF权限和RFC权限的工具。在Launchpad页面按F9启动权限追踪，点击Tile后查看SU53结果：如果报错S_ICF对象缺失，说明SICF节点没授权；如果报错S_RFC对象缺失，说明RFC权限没配。这种实时追踪比静态角色分析准确十倍。

这套工具链不依赖任何外部插件，所有操作都在SAP GUI或Web GUI内完成，确保你在任何受限网络环境下都能执行。

3. 核心细节解析：白屏背后的五个致命配置点

3.1 配置点一：OData服务注册状态的“Active”陷阱

服务注册状态不是非黑即白的“Registered/Active”，而是存在一个危险的灰色地带——“Registered but Metadata Parse Failed”。这个状态在/IWFND/MAINT_SERVICE界面中显示为绿色对勾，但实际服务无法被Catalog生成作业识别。

触发条件：CDS视图中使用了未维护语言文本的注释标签。例如：

@AbapCatalog.sqlViewName: 'ZC_MM_MATERIAL' @AbapCatalog.compiler.compareFilter: true @AccessControl.authorizationCheck: #CHECK @EndUserText.label: 'Material Master Data' // ← 关键：未维护中文文本 define view ZC_MM_MATERIAL as select from mara { key mara.matnr as MaterialNumber, mara.mtart as MaterialType }

当Gateway服务器尝试解析$metadata时，会调用CL_SADL_GW_METADATA_PROVIDER类，该类在生成XML时会尝试读取@EndUserText.label对应的语言文本。若系统语言为ZH，而T100表中无对应条目，解析过程抛出CX_SADL_METADATA_EXCEPTION异常，但/IWFND/MAINT_SERVICE界面不会显示错误，仅将服务状态设为“Registered”。

验证方法：

  1. 在浏览器中直接访问服务元数据URL：https://<host>:<port>/sap/opu/odata/sap/ZMM_MATERIAL_SRV/$metadata
  2. 如果返回HTTP 500且XML内容为空，或返回HTTP 200但XML中<edmx:Edmx>根节点下无<edmx:DataServices>子节点，则确认元数据解析失败。

修复步骤：

  1. 进入事务码SE63→ “Translation” → “ABAP Dictionary” → 输入CDS视图名ZC_MM_MATERIAL
  2. 选择语言ZH，点击“Create”新建翻译条目
  3. 在“Short Text”字段填入中文名称“物料主数据”，保存
  4. 回到/IWFND/MAINT_SERVICE，找到该服务，点击“Change” → “Activate Service”按钮（注意：不是“Register”，是“Activate”）
  5. 激活后状态变为“Active”，此时/UI2/CHIP_CATALOG_GEN作业才能扫描到它。

提示：不要依赖/UI2/CHIP_CATALOG_GEN的自动调度。首次修复后，手动运行该作业（事务码SM36创建后台作业，程序名UI2_SAP_CATALOG_GENERATE），并在作业日志中确认输出“Catalog generated for 1 services”。

3.2 配置点二：SICF节点权限的“父子继承断裂”

SICF节点权限不是孤立存在的。/sap/opu/odata/sap/ZMM_MATERIAL_SRV节点的权限，必须同时满足两个条件：

  • 其父节点/sap/opu/odata/sap/的SICF权限已激活且授权给用户
  • 该节点自身的SICF权限已激活且授权给用户

但SAP默认配置中，/sap/opu/odata/sap/节点的权限对象S_ICF的“Activity”字段值为GENERIC，这意味着它只允许访问“已显式授权”的子节点，而不自动继承。如果你只给子节点授权，却忘了激活父节点，请求会在父节点层就被拦截，返回403。

验证方法：

  1. 进入事务码SICF
  2. 导航至节点/sap/opu/odata/sap/→ 右键“Edit Service” → “Service Configuration”
  3. 检查“Activation Status”是否为“Active”，“Error Page”是否为空
  4. 点击“Authorization”标签页，确认“Authorization Object”为S_ICF，“Activity”为GENERIC
  5. 展开子节点/sap/opu/odata/sap/ZMM_MATERIAL_SRV，重复步骤3-4

修复步骤：

  1. 对父节点/sap/opu/odata/sap/：右键“Edit Service” → “Authorization” → “Maintain Authorization” → 为角色分配S_ICF权限，Activity填GENERIC
  2. 对子节点/sap/opu/odata/sap/ZMM_MATERIAL_SRV：同样操作，但Activity填EXECUTE（这是服务级执行权限）
  3. 保存后，必须重启SICF服务：在SICF界面按Ctrl+Shift+F9强制刷新缓存

注意：SICF权限修改后不会立即生效，必须执行Ctrl+Shift+F9。很多团队卡在这里长达数小时，就是因为没刷新缓存。

3.3 配置点三：RFC目的地配置的“LOCAL陷阱”

OData服务调用Backend时，需指定RFC目的地。标准配置中，目的地名称通常设为LOCAL，表示调用本系统ABAP Backend。但LOCAL不是一个魔法字符串，它对应着SM59中一个真实的RFC连接定义。

常见错误：

  • SM59中LOCAL目的地的状态为“Inactive”
  • LOCAL目的地的“Connection Type”设为3（TCP/IP），但“Target Host”留空
  • LOCAL目的地的“Logon & Security”选项卡中，“Client”字段填了错误的客户端号（如填了800但当前系统是100）

验证方法：

  1. 进入事务码SM59
  2. 找到目的地LOCAL，双击打开
  3. 点击“Connection Test”按钮 → 如果弹出“Connection test successful”，说明RFC连接正常
  4. 如果失败，查看错误消息：“No RFC destination defined”或“Logon failed”

修复步骤：

  1. 若LOCAL不存在，在SM59中创建新条目，名称填LOCAL
  2. “Connection Type”选3（TCP/IP）
  3. “Target Host”留空（本地调用不需填主机）
  4. “System Number”填当前系统编号（如00）
  5. “Logon & Security”选项卡中，“Client”填当前登录客户端号，“User”填DDIC或SAP*（需有足够权限）
  6. 保存后，务必点击“Remote Logon”测试，成功后激活

实操心得：不要用SAP*用户测试RFC。SAP*在部分系统中被禁用远程登录。建议创建专用测试用户ZRFC_TEST，赋予S_RFC权限，并在SM59中用此用户测试。

3.4 配置点四：Launchpad Catalog生成的“时间窗口漏洞”

/UI2/CHIP_CATALOG_GEN作业默认每天凌晨2点运行，但Catalog数据有缓存机制。即使作业成功生成Catalog，前端Launchpad仍可能读取旧缓存，导致新注册的服务不显示。

验证方法：

  1. 运行/UI2/CHIP_CATALOG_GEN作业后，进入事务码/UI2/CHIP_CATALOG
  2. 查询Catalog名称（如ZMM_CATALOG），确认其Last Generated时间是否为最新
  3. 在Launchpad页面按Ctrl+F5硬刷新，观察是否出现新Tile

修复步骤：

  1. 清除Launchpad前端缓存：在浏览器地址栏输入https://<host>/sap/fiori/launchpad/logoff登出，再重新登录
  2. 强制刷新Catalog缓存：在SAP GUI中运行程序/UI2/INVALIDATE_CACHE，输入CATALOG作为参数
  3. 验证Catalog内容：在/UI2/CHIP_CATALOG中打开Catalog，点击“Display Content”，确认ZMM_MATERIAL_SRV服务已出现在Service Name列

提示：/UI2/INVALIDATE_CACHE程序不会删除Catalog，只清除内存缓存。这是最安全的刷新方式，避免因误操作导致Catalog丢失。

3.5 配置点五：CDS视图暴露的“数据权限盲区”

即使OData服务注册成功、SICF激活、RFC连通，前端仍可能返回空数据或403错误。这是因为CDS视图本身有数据权限控制，而OData服务默认不继承ABAP权限对象。

典型场景：CDS视图ZC_MM_MATERIAL中添加了@AccessControl.authorizationCheck: #CHECK，但未定义对应的权限对象。此时，Gateway调用CDS时会触发权限检查，因找不到权限对象而静默拒绝。

验证方法：

  1. 在Backend系统中，进入事务码SE11，输入CDS视图名ZC_MM_MATERIAL
  2. 点击“Display” → “Source Code” → 查找@AccessControl注解
  3. 若存在#CHECK，则必须有配套权限对象；若为#NOT_REQUIRED，则跳过此检查

修复步骤：

  1. 创建权限对象：事务码SU21→ 新建对象类型ZMM_MAT_AUTH，字段MATNR（物料号）、MTART（物料类型）
  2. 在CDS视图中引用该对象：
@AccessControl.authorizationCheck: #CHECK @AccessControl.authorizationObject: 'ZMM_MAT_AUTH' define view ZC_MM_MATERIAL as select from mara { ... }
  1. 为角色分配该权限对象：事务码PFCG→ 编辑角色 → 添加ZMM_MAT_AUTH对象，设置字段值（如MATNR = *表示全部物料）

注意：CDS权限对象的字段名必须与CDS视图SELECT列表中的字段名完全一致，包括大小写。MATNR和matnr被视为不同字段。

4. 实操过程：从白屏到服务可用的七步闭环

4.1 第一步：确认白屏性质——是Launchpad未加载，还是Tile无响应？

这是所有排障的起点。打开浏览器开发者工具（F12），切换到“Network”标签页，然后刷新Launchpad页面。观察第一个请求：

  • 如果index.html返回200，但后续/sap/opu/odata/UI2/CHIP请求返回404或500，则是Catalog加载失败，问题在Gateway或Catalog生成环节
  • 如果/sap/opu/odata/UI2/CHIP返回200且有JSON数据，但点击某个Tile后，/sap/opu/odata/sap/ZMM_MATERIAL_SRV/...请求返回404/403，则是OData服务调用失败，问题在服务注册、SICF或RFC环节

实操记录：
某次排障中，/sap/opu/odata/UI2/CHIP返回200，但响应体为空JSON{}。这说明Catalog生成作业运行了，但没生成任何服务条目。立刻转向检查/IWFND/MAINT_SERVICE中服务状态——果然，所有服务都显示“Registered”，无一“Active”。执行元数据URL测试，确认是CDS语言文本缺失导致。

4.2 第二步：直击元数据——用$metadataURL验证服务健康度

构造URL：https://<host>:<port>/sap/opu/odata/sap/ZMM_MATERIAL_SRV/$metadata

  • HTTP 200 + XML含<edmx:DataServices>→ 元数据正常，服务可被Catalog识别
  • HTTP 500 + 空XML → 元数据解析失败，查CDS语言文本
  • HTTP 404 → SICF节点未激活或路径错误
  • HTTP 403 → SICF权限缺失

参数计算：端口号不是固定443。若系统使用HTTPS，端口在SICF节点属性中查看：/sap/opu/odata/sap/ZMM_MATERIAL_SRV节点的“Service Configuration” → “Port”字段。若为0，表示使用系统默认HTTPS端口（通常443）；若为8000，则URL中必须显式写出:<port>。

4.3 第三步：穿透SICF——用SICF事务码验证节点激活与权限

在SICF中定位节点/sap/opu/odata/sap/ZMM_MATERIAL_SRV：

  1. 右键“Test Service” → 如果弹出XML元数据，说明节点激活且权限OK
  2. 如果提示“Service is not active”，右键“Activate Service”
  3. 如果提示“Authorization check failed”，进入“Authorization” → “Maintain Authorization” → 为角色分配S_ICF权限，Activity填EXECUTE

关键技巧：SICF中“Test Service”按钮调用的是/IWFND/...路径，但实际生产中前端调用的是/sap/opu/...路径。因此，必须同时测试父节点/sap/opu/odata/sap/的“Test Service”，确保整条路径畅通。

4.4 第四步：核验RFC——用SM59确认LOCAL目的地连通性

在SM59中测试LOCAL：

  1. 选中LOCAL→ 点击“Connection Test”
  2. 若失败，查看错误代码：
    • RFC_ERROR_SYSTEM_FAILURE：Backend系统宕机
    • RFC_ERROR_LOGON_FAILURE：用户密码错误或权限不足
    • RFC_ERROR_COMMUNICATION_FAILURE：网络不通或防火墙拦截

避坑经验：SM59测试成功不代表OData调用成功。SM59只测试RFC连接，而OData调用还需经过Gateway的ABAP堆栈。因此，SM59成功后，必须再执行第五步。

4.5 第五步：捕获网关日志——用/IWFND/ERROR_LOG定位真实错误

在/IWFND/ERROR_LOG中设置筛选条件：

  • “Date From”设为当前时间前10分钟
  • “Service Name”填ZMM_MATERIAL_SRV
  • “HTTP Status Code”留空（先看所有错误）

典型错误解读：

错误消息含义解决方案
Metadata provider error: CX_SADL_METADATA_EXCEPTIONCDS元数据解析失败补充语言文本，重新激活服务
Authorization check failed for object S_ICFSICF权限缺失为角色分配S_ICF权限
RFC destination ZMM_MATERIAL_SRV not foundRFC目的地名称错误检查/IWFND/MAINT_SERVICE中服务名与SM59中目的地名是否一致
Error while calling backend systemBackend系统不可达检查SM59中LOCAL连接，或Backend系统状态

4.6 第六步：验证Backend执行——用SM21确认RFC是否抵达

在SM21中设置筛选：

  • “Time Interval”设为最后5分钟
  • “Message Class”填RFC
  • “Message Number”留空

查找包含ZMM_MATERIAL_SRV或ZC_MM_MATERIAL的条目。如果SM21中无任何记录，说明请求未离开Gateway，问题在SICF或服务注册；如果有记录且SY-SUBRC = 0，说明Backend执行成功；如果SY-SUBRC = 4，说明CDS视图执行时报错，需去Backend系统查ST22短dump。

4.7 第七步：最终验证——用SU53权限追踪锁定最后一环

在Launchpad页面按F9启动权限追踪，点击目标Tile，然后：

  1. 切换到SAP GUI，运行SU53
  2. 查看最新记录，重点关注Object列：
    • S_ICF→ SICF权限问题
    • S_RFC→ RFC权限问题
    • ZMM_MAT_AUTH→ CDS数据权限问题

实测案例：某次SU53显示S_RFC缺失，但角色中已分配S_RFC。深入检查发现，“RFC Destination”字段填的是ZMM_MATERIAL_SRV，而/IWFND/MAINT_SERVICE中服务名是ZMM_MATERIAL_SRV_001。修正目的地名称后，问题解决。

5. 常见问题与排查技巧实录

5.1 白屏但控制台无任何错误——这是最危险的信号

现象：浏览器控制台（Console）干净如初，Network标签页中index.html返回200，但页面空白。
真实原因：Launchpad前端JavaScript加载失败，但错误被全局异常处理器捕获并静默处理。
排查路径：

  1. 在Network标签页中，过滤js文件，查找shell.js、Component-preload.js等核心JS文件
  2. 如果这些文件返回404，说明UI5库路径配置错误
  3. 进入事务码SICF→ 节点/sap/public/bc/ui5_ui5→ 检查是否激活，权限是否OK
  4. 如果/sap/public/bc/ui5_ui5返回403，说明S_ICF权限未覆盖该路径

提示：/sap/public/bc/ui5_ui5是UI5库的公共访问路径，必须与/sap/opu/odata/sap/同级激活。很多团队只配了OData路径，忘了UI5库路径。

5.2 Tile显示但点击后无限转圈——后端响应超时的伪装

现象：Tile正常显示，点击后出现加载动画，但10秒后消失，无数据也无错误。
真相：Backend执行超时，Gateway返回HTTP 504（Gateway Timeout），但前端JavaScript未处理该状态码，导致静默失败。
验证方法：

  • Network标签页中找到对应OData请求，查看“Status Code”是否为504
  • SM21中查找RFC消息，看是否有TIMEOUT关键字
    解决方案：
  • 在CDS视图中添加@AbapCatalog.sqlViewName确保使用数据库视图而非运行时计算
  • 在Backend系统中，事务码RZ11设置参数rdisp/max_wprun_time = 600（10分钟）
  • 在Gateway系统中，事务码/IWFND/MAINT_SERVICE→ 服务详情 → “Runtime Settings” → 增加“Maximum Processing Time”

5.3 同一服务在Postman中能调通，但在Launchpad中失败——跨域与认证的暗战

现象：Postman调用/sap/opu/odata/sap/ZMM_MATERIAL_SRV/...返回200 JSON，但Launchpad调用同一URL失败。
根本原因：Postman发送的是匿名请求，而Launchpad携带了SAP Logon Ticket（SSO凭证）。Gateway在验证Ticket时失败，返回401，但前端未处理。
验证方法：

  • 在Network标签页中，点击失败的OData请求 → “Headers” → 查看“Request Headers”中是否有x-sap-logonticket
  • 如果有，说明是SSO问题；如果没有，说明前端未携带凭证，检查/UI2/USMD中用户主数据是否启用SSO
    修复步骤：
  • 进入事务码STRUST→ SSL证书管理 → 确保SAPSSL证书已导入且激活
  • 在/IWFND/MAINT_SERVICE中，服务详情 → “Security Settings” → 勾选“Enable SSO”

5.4 Catalog中有服务，但Tile不显示——Target Mapping的精确匹配

现象：/UI2/CHIP_CATALOG中能看到ZMM_MATERIAL_SRV，但Launchpad中无对应Tile。
原因：Tile定义中的targetMapping与Catalog中服务名不完全匹配。
验证方法：

  • 在/UI2/CHIP_CATALOG中，打开Catalog → “Display Content” → 记录Service Name字段值（如ZMM_MATERIAL_SRV）
  • 在/UI2/CHIP中，找到对应Tile → “Target Mapping” → 检查Semantic Object和Action是否与服务名一致
    关键规则：
  • Semantic Object必须等于服务名（ZMM_MATERIAL_SRV）
  • Action必须为display（标准显示动作）或自定义动作（需在Backend中实现）
  • 不能有多余空格或大小写差异（zmm_material_srv≠ZMM_MATERIAL_SRV）

5.5 权限配置后仍报403——权限对象字段值的“星号陷阱”

现象：PFCG中已为角色分配S_RFC权限，Activity=EXECUTE，RFC Destination=LOCAL，但调用仍403。
真相：“RFC Destination”字段值必须与/IWFND/MAINT_SERVICE中服务的“Backend System”字段完全一致。
验证方法：

  • 在/IWFND/MAINT_SERVICE中，打开服务 → “Backend System”字段值（如GW_CORE）
  • 在PFCG中，S_RFC权限的“RFC Destination”字段必须填GW_CORE，不能填LOCAL
    解决方案：
  • 在/IWFND/MAINT_SERVICE中，服务详情 → “Backend System” → 改为LOCAL（如果Backend确实在本系统）
  • 或在PFCG中，S_RFC权限的“RFC Destination”字段改为GW_CORE

最后一个实操心得：每次修改配置后，不要立即刷新浏览器。先执行/IWFND/ERROR_LOG清空日志（点击“Delete All”），再刷新。这样你能100%确认新错误是本次修改引发的，而不是历史残留。我在某次排障中，因为没清日志，花了3小时追查一个早已修复的旧错误。