陈劳斯前阵子给一家制造业客户做Fiori权限迁移，接手了三十多个PFCG角色。客户运维经理很自信，说权限已经给得很全了，但新来的采购经理登录SAP Fiori Launchpad，页面上就是看不到报销审批入口。这种问题我一年里能碰上十几次：每个人都以为把PFCG角色往用户身上一挂，Fiori的角色维护就算完成，其实还缺一道非常关键的环节——由SAP_FLP_ADMIN这类管理应用承载的业务目录、业务组、业务角色逻辑。这篇就把这条链路彻底讲明白，给还在用老思路配Fiori权限的顾问、Basis以及权限专员做个参考。
1. 权限能看见不等于权限能执行：先分清PFCG技术角色和Fiori业务角色
1.1 为什么一个PFCG角色解决不了Fiori“看不到图块”的问题
传统GUI里，PFCG角色维护的是“事务码+权限对象+组织级别”的授权数据。用户拿了一个包含ZMM01的角色，他就能用事务码ZMM01，这是很直接的执行权限。但Fiori里软件运行的形态变了，前端是一个个Tile（磁贴），点击Tile会触发一个Intent导航，这个Intent最终会去调用后端某个OData服务或某个事务。用户能不能看到这个Tile，能不能点进去，是两层独立设计。
先看能不能看到，这由Fiori Launchpad的Catalog和Group决定。Catalog是应用的逻辑集合，你可以把它理解成“一套App货架”，SAP交付时会按业务域打包，比如SAP_SFIN_BC_GL_ACCOUNTANT；用户被分配了这个Catalog，他理论上才可能看到货架上的应用。而Group则是货架在启动面板上的摆放规则，它决定用户打开FLP后，哪些Tile摆在默认页面的“组”里。没有组，App可能在App Finder里能找到，却不一定会直接出现在用户的首页上。
再看能不能执行，这取决于PFCG技术角色背后的授权数据。当用户点击Tile，浏览器会向后端发起OData调用。后端在响应的过程中会执行ABAP授权检查，检查的是用户是否有访问该OData服务对应权限对象、RFC权限、S_TCODE或者自定义权限对象的权利。如果这层检查失败，前端的状态不是“看不到”，而是点击后报错，尤其是在浏览器Network面板里看到HTTP 403。
所以PFCG本身没有过时，它依然是后端授权的主体。“从PFCG到SAP_FLP_ADMIN”这句话容易造成误解，好像新工具要取代旧工具，真实情况是：业务角色最终落在技术层，仍然是一组PFCG角色，只不过定义和交付的方式从经典事务码搬到了Fiori界面。
1.2 SAP_FLP_ADMIN到底是个什么入口
SAP_FLP_ADMIN在SAP生态里不是一个传统ABAP事务码，也不是开发人员常说的报表程序。它是一个Fiori管理应用的标识，实际界面上经常叫“Launchpad Admin”或者“业务角色维护”，登录后你能看到一整套和角色、目录、组、站点设置有关的卡片。我的理解里，SAP_FLP_ADMIN代表的是Fiori时代面向管理员的新维护范式：业务管理员不用钻到PFCG的权限字段矩阵里，而是用业务语言来操作角色。
举个例子，过去要在PFCG里维护一个财务经理角色，你得知道他的业务事务范围，还要处理一堆S_TCODE、S_PROGRAM、授权对象、Activity等字段，稍微漏一个，功能就异常。SAP_FLP_ADMIN则会引导你把“业务角色”当成一个完整的对象来维护：从业务角色出发，给它添加业务目录、业务组、用户，系统再根据这些选择，在后台拼装出授权数据。这个过程里，很多技术性内容被封装了。
不过我得提醒一句：这里说的“封装”不是“消灭”。我做过的项目里，Fiori界面上维护完角色，后台依然能看到对应生成的技术角色，很多情况下这些技术角色还是以PFCG角色形式存放的。换句话说，SAP_FLP_ADMIN更像是PFCG的“前端翻译器”，差异点在操作体验，不在底层权限模型。想真正解决问题，两者都得懂，不能只抱着一头。
1.3 什么时候走PFCG，什么时候走SAP_FLP_ADMIN
为了少走弯路，我自己在项目上习惯用一个简单判断规则：面向单个技术用户、临时调整、权限对象细节排查，用PFCG；面向业务岗位、需要长期维护、希望给业务管理员甚至用户自己去理解的，优先走SAP_FLP_A