上线第三周我被拉进一个会议业务那边第一句话就是为什么同样是采购员李四的 Fiori 首页能看到新上线的采购申请审批应用张三就是看不到我第一反应还是老套路查 PFCG 角色、查 S_TCODE、查 S_SERVICE折腾了一上午结论是权限数据都正常。最后翻到 Fiori Launchpad 的角色配置才发现问题出在Business Catalogs业务目录上——张三的角色里压根没有挂对应的目录应用就算在后端激活了也不会出现在他的首页上。这个场景我遇到过不止一次。从 ECC 时代转型到 S/4HANA 的权限顾问十有八九都会在这个地方栽跟头。原因很简单Fiori 权限体系和传统 ECC 权限体系的底层逻辑已经变了不再是你给角色塞几个事务码、配几个授权对象就能搞定的。这篇文章我就从权限视角把 Business Catalogs 这套机制掰开揉碎讲清楚它到底解决了什么、怎么搭一套能跟着业务演进的角色体系以及上线之后怎么维护不崩盘。无论你是 SAP Basis、安全顾问、Fiori 开发还是企业内部负责权限的 IT 管理员这篇都值得花十分钟看完。1. 先把语境对齐Fiori 权限和老 ECC 权限根本不是一回事1.1 那个权限正常却看不到应用的典型场景先复现一下开头那个案例的完整细节。张三和李四都是采购员角色都是从同一个模板复制出来的。新上线一个采购申请审批的 Fiori 应用后端网关服务激活了目录也发布到了开发系统测试环境里 QA 也验收通过。可到了生产环境张三的 launchpad 上新应用的磁贴就是死活不出现。我当时做的第一步是查 PFCG 角色里的授权对象S_TCODE、S_SERVICE、S_ICF 全都看了该有的都有甚至比李四还多。又让张三重登、清缓存还是不行。最后对照两个用户分配的 PFCG 角色名称发现李四的角色是业务角色类型里面挂了一个 Business Catalog张三的角色是传统单一角色里面塞了一堆事务码和授权对象唯独没有挂目录。这个案例的教训非常典型Fiori 应用的可见性和后端服务授权是通过业务目录传递的不是靠事务码传递的。你可以在角色里把 S_SERVICE 配得再全只要角色类型不对、目录没挂上用户在启动台上就找不到这个应用。1.2 PFCG 的老办法为什么在这里失灵传统 ECC 的权限模型核心是事务码 授权对象。一个角色里放三五个事务码再配一组授权对象字段值用户保存完 profile 就完事。这套模型在 GUI 时代很好用因为 SAP GUI 的操作入口就是事务码S_TCODE 控住入口其他授权对象控住操作范围边界清晰。到了 Fiori 时代应用入口变成了 Launchpad 上的磁贴操作入口变成了 UI5 组件和 OData 服务。一个 Fiori 应用的访问链路至少有四段前端加载 UI5 组件调用后端 OData 服务的元数据请求调用具体的 OData 实体集方法后台业务逻辑里涉及的传统授权对象检查比如采购组织、公司代码。如果还按老思路只给用户配 S_TCODE 或者干脆配一个很大的 S_SERVICE轻则应用不显示重则权限过度授权。更麻烦的是Fiori 应用上线时总要跟着改角色、补授权对象每加一个新应用就要手工动一次角色角色越攒越多、越攒越乱最后变成一团谁都不敢动的蜘蛛网。1.3 Business Catalogs 到底打包了什么SAP 在 S/4HANA 和 Fiori 体系里推出的Business Catalog业务目录本质是做了一个打包把一个业务场景相关的应用、它们依赖的 OData 服务、以及服务调用所需的授权默认值统一装进一个目录里。比如采购申请审批这个业务场景对应一个目录供应商主数据查询对应另一个目录。权限顾问不需要再关心某个应用底层调用了哪个 OData 服务、需要哪些授权对象只需要判断一件事这个用户要不要这个业务场景。要就把对应的目录挂到他的业务角色上不要就不挂。这样做带来的直接好处是角色可演进业务变了目录跟着变目录变了角色重新生成一下就好不用逐条去改授权对象。我做过一个对比表可以帮助团队快速理解两者的差异维度传统 PFCG 角色Business Role基于 Catalog最小授权单元事务码 授权对象业务目录一组应用 服务权限应用可见性不负责负责通过目录、组、空间传递后端服务授权手工维护 S_TCODE、S_SERVICE 等目录自带授权默认值自动带入新增一个应用手工改角色并补充授权对象更新目录后重新生成角色跨角色复用复用困难拷贝后容易失控同一目录可挂多个业务角色变更影响分析靠人肉排查按目录、角色、用户逐层追踪这个表我建议直接放进项目权限文档第一页。团队里如果有人还是事务码思维看一遍基本就能转过弯来。2. Business Catalog 体系拆解应用、目录、角色、用户的四层联动2.1 四层链路和每层的职责要设计好角色体系先得把 Business Catalog 相关的对象层次在心里立起来。我把它们分成四层App 层具体的 Fiori 应用由 UI5 组件、OData 服务、Intent语义对象 动作组成。比如一个采购申请的审批应用。Catalog 层业务目录把同一业务场景的若干 App 收集在一起并携带它们需要的授权默认值。Role 层业务角色Business Role一个业务角色可以挂一个或多个业务目录。角色保存后生成授权 profile。User 层用户通过 SU01 分配业务角色Launchpad 根据用户拥有的角色渲染可用的磁贴。这四层是逐级包含的关系用户拥有角色角色包含目录目录包含应用。理解了这个链条排错思路就清晰了看不到应用先看角色有没有挂目录有目录但点进去报 403再看目录里的服务授权和后端权限后端权限也没问题就开始查数据级别的限制。我在项目里经常跟同事讲一句话不要一开始就去翻授权对象先沿着用户 - 角色 - 目录 - 应用这条链路走一遍。80% 的 Fiori 权限问题都出在某一层断掉了。2.2 Authorization Defaults目录自带的默认权限建议目录里除了应用清单还有一层容易被忽略的内容就是Authorization Defaults授权默认值。这个机制可以类比传统 ECC 里的 SU24系统为每个事务码预置了一套建议的授权对象值你在 PFCG 里生成权限数据时系统会自动把这些建议值带进角色。Business Catalog 干的是同一件事只不过粒度从事务码换成了应用 OData 服务。当一个业务目录被挂进业务角色并生成 profile 时目录里预置的 OData 服务授权默认值会自动写入角色。这意味着权限顾问不需要知道某个采购应用到底调用的是/sap/opu/odata/sap/...下的哪个服务也不需要手工去建 S_SERVICE 授权目录已经把路铺好了。但这里有一个必须提醒的坑默认值不等于全部权限。Catalog 负责的是服务能不能调至于调了之后数据能不能看、能看哪些范围往往还要靠更底层的授权对象和 CDS 数据权限来控制。比如一个采购价格查询应用Catalog 让它能调用查询服务但用户能不能看到某个供应商的价格还要看角色里有没有配置对应的组织级别限制。所以Catalog 解决的是入口和通道业务规则级的安全控制仍然需要你认真做。2.3 内容目录与引用目录以及目录版本带来的坑在 Fiori 的角色配置界面你会看到同一类目录存在两种用法一种常被称为内容目录另一种是引用目录。不同版本、不同文档里的叫法略有差异判断标准只有一个这个目录是否承担授权传递。内容目录真正携带应用和授权默认值挂到角色里会同时授予应用可见性和后端服务权限。引用目录只是把应用引用到某个角色或空间里用于让应用显示出来但本身不重复携带授权。这样设计是为了避免同一套应用权限在多个角色里重复维护。比如你把某个应用放在内容目录里授权又在另一个需要仅显示应用的角色里用引用目录把它带上两者各司其职。实际项目里更容易踩的坑是目录版本。SAP 发布标准目录更新时可能把新应用、新服务加进一个你已经用着的标准目录里。但你正在使用的业务角色不会自动获得新增授权必须重新生成角色的权限数据新内容才会生效。很多项目上线后业务说新应用发布了为什么我们没有排查到最后就是角色没有重新生成、profile 还是旧版本。2.4 Groups、Spaces、Pages别把可见性当成权限我看到太多新人把用户能在 Launchpad 看到应用直接等同于用户有权限其实这是两个维度。Business Group业务组负责把应用或者目录分组成不同的 tab让磁贴按业务场景排列。它只影响显示不负责授权。Space空间和 Page页面这是新版 Launchpad 推荐的布局方式。空间是顶层容器页面是空间里的页签你把自己想要的应用/目录放进去。空间可以通过业务角色分配也可以由用户在 Launchpad 设计器里自定义。授权链是Catalog - Role - User可见性链是Catalog - Group/Space/Page - Role - User。两者在业务角色里同时存在但职责完全分离。我项目里出现过这样的乌龙用户权限是好的后端 OData 也能调通但就是看不到磁贴最后发现角色里挂的目录没放进任何 SpaceLaunchpad 渲染时自然就没有它的位置。所以遇到看不到的问题别急着怀疑权限先检查空间和页面的分配。2.5 业务角色与技术角色的组合规则Business Catalog 体系覆盖的是 Fiori 应用但现实世界里没有哪个企业是 100% 只用 Fiori 的。大量用户仍然要用 SAP GUI 跑后台事务比如物料管理的 MD04 查库存/需求、采购的 ME11 维护信息记录、财务月结的一堆事务码。这些老事务不会因为上了 S/4HANA 就消失它们需要的还是传统 PFCG 授权。因此绝大多数项目的标准做法是双轨制业务角色Business Role负责 Fiori 应用的可见性和 OData 服务授权技术角色Technical Role负责 SAP GUI 事务码和传统授权对象。这两个角色必须分开建、分开管不要混在一个角色里。混在一起的问题在于演进节奏不一致Fiori 应用更新快业务角色可能一个月要动好几次后台事务权限相对稳定技术角色半年都不需要碰。一旦混用每次业务角色变更都要做完整的回归测试拖累整个变更周期。我见过一个客户把 ME23N 这种事务码挂进业务角色结果 Fiori 应用升级时连带影响了一堆 GUI 用户差点造成月结事故。3. 构建可演进角色体系的落地套路命名规范、分层设计与实操步骤3.1 目录分类与命名规范很多项目输在起跑线上是因为目录和角色命名没有规范上线三个月后根本分不清哪个目录是干什么的。我的建议是自上而下先定好规则。先说目录。SAP 标准目录以SAP_开头比如财务、物料、销售各模块都有自己的一套。标准目录原则上不修改、不复制改造直接拿来用。自开发应用或需要裁剪的场景自定义目录用Y_或Z_开头推荐格式Y_BC_模块_业务场景_用途例如Y_BC_PUR_INQUIRY采购信息查询目录Y_BR_模块_岗位_层级例如Y_BR_PUR_BUYER采购员业务角色Y_TR_模块_岗位_层级例如Y_TR_PUR_USER采购后台事务技术角色。这套命名的价值在权限审计和变更影响分析时才会真正体现。项目上线半年后安全审计要你列出拥有采购查询权限的所有用户你只需要用角色名关键词在 SUIM 里过滤而不是打开几十个角色挨个看。3.2 三层角色模型基础、业务、技术长期运维下来我建议把角色体系沉淀成三层每层职责单一、维护频率不同基础层所有登录用户都要有的通用权限比如基本菜单、当前用户自有数据访问、必要的会话参数。维护频率极低。业务层按岗位职责组织的业务角色全部基于 Business Catalog 构建决定用户在 Fiori 里能做什么。维护频率中等。技术层按后台事务需求组织的技术角色只放 SAP GUI 相关的事务码和授权对象。维护频率低。这样分层的核心逻辑是把变的和不变的隔离。用户入职、转岗、离职权限变更主要发生在业务层系统升级带来的标准目录变化也只影响业务层。审计的时候可以按层去抽查规则是否合理不用把几十个角色当成一个整体来审查。3.3 从零搭建一个业务角色的完整步骤搭一个基于 Business Catalog 的业务角色看起来简单但每一步都有细节。我按常规路径走一遍创建业务角色。在 PFCG 里新建角色角色类型选择业务角色Business Role或者使用 Fiori Launchpad 里的Maintain Business Roles管理应用。具体入口不同版本有差异以你系统为准。维护角色描述和所属业务范围描述里写清楚这个角色对应的岗位不要写临时角色这种无法判断责任范围的名称。添加业务目录。在 Business Catalog 页签把需要的标准目录或自定义目录挂进来。这一步的核心是最小够用宁可少挂一个目录让用户真需要时再补也不要为了省事把整个模块的目录全挂上。如果有数据范围限制比如采购员只能看自己负责的采购组织在目录的限制配置里维护组织级别。不同版本限制配置的入口不同但记住一个原则限制是加在角色和目录的关联上的不是加在目录本身上的否则会影响所有使用这个目录的其他角色。如果该应用还需要额外调用自定义 RFC/BAPI或者有 Catalog 默认值覆盖不到的后端授权对象在 Authorizations 页签里手工补充。这一步和传统 PFCG 完全一样也是很多 Fiori 权限问题出现的地方别漏了。生成授权 profile。保存角色后执行生成授权数据系统才会把目录里的授权默认值落进角色的 profile。很多挂了目录但没权限的问题就是这一步没做。分配用户。SU01 里把业务角色分配给用户或者用 SU10 批量分配同时把对应的技术角色如果有一起分配。注意业务角色和技术角色要同时给否则用户可能 Fiori 能看到应用但跳转后台事务时报权限不足。配置 Space/Page 可见性。把业务角色挂到对应的空间/页面或者确认空间已经分配给用户。这一步直接决定用户能不能在 Launchpad 上看到磁贴。测试验收。用一个全新的测试用户只分配这个业务角色和技术角色登录 Launchpad 跑一遍端到端流程。不要复用你自己的超管账号测试那测不出来任何问题。3.4 权限验证闭环SU53、SUIM 和网关 Error Log角色搭完了怎么确认配得对我习惯用的排错路径是这样的先用 SU53 查用户最后一个失败的授权检查。如果用户运行 Fiori 应用报权限错误让他在 GUI 里复现问题如果有对应后台事务或在他的用户会话里查看失败对象。SU53 在 Fiori 场景下也适用它会告诉你缺少的授权对象和字段值。再用 SUIM 做整体分析。比如查用户分配了哪些角色、角色里有哪些授权对象、哪些用户拥有某个事务码都可以在 SUIM 的报表里覆盖。每周我做权限巡检时SUIM 是主力工具。Fiori 特有的问题去 SAP Gateway 的 Error Log 里看。如果 OData 请求在网关层被拒Error Log 会记录具体是哪个服务、哪一步授权失败。很多时候前端报 403根因在后端某个服务没有对当前用户开放网关日志比前端报错信息有用得多。这三个工具配合起来基本能定位 90% 的 Fiori 权限问题。剩下那 10%通常出在 CDS 数据权限和 UI 注解层需要到具体的服务实现里去看。4. 存量 PFCG 角色迁移到 Business Role 的取舍与顺序4.1 迁移前先做好三件盘点老系统一定有大量存量 PFCG 角色不可能全部推翻重来。迁移之前我会先做三件盘点盘点 Fiori 使用范围哪些岗位真的需要 Fiori 应用哪些岗位只碰 SAP GUI。只要用 GUI 的岗位技术角色原样保留不参与迁移。这个范围收得越窄迁移风险越低。盘点应用与目录的映射把当前 Fiori 使用的应用清单拉出来对照标准目录确认每个应用该挂哪个目录。这一步可以直接用 Fiori 的应用参考库App Reference Library或者团队自建的 Fiori Tracker 维护。盘点存量角色的孤儿权限老 PFCG 角色里通常有一堆历史遗留的授权对象很多已经没人知道当时为什么加。这些权限迁过去没有任何价值反而是审计风险。迁移前先做瘦身把无主权限清理掉。4.2 推荐迁移顺序从纯 Fiori 岗位开始迁移顺序我强烈建议先易后难第一批迁纯 Fiori 岗位这些用户只使用 Launchpad 上的应用不碰 GUI 事务。角色完全由业务角色构成不存在双轨制迁移后回归测试简单。第二批迁混合岗位既有 Fiori 应用又有 GUI 需求。这类岗位要拆成业务角色 技术角色两个对象拆的时候注意别把 GUI 事务码塞进业务角色。最后处理复杂岗位比如财务月结、跨模块流程这种既要用 Fiori 又要用多个 GUI 事务的高级用户。这类用户权限覆盖面大尽量保持业务角色和技术角色的严格分离必要时做一次完整的数据级权限梳理。SAP 为存量角色迁移提供了辅助工具具体程序名和操作路径请以你当前版本的 Release Note 为准。但我要提前给你泼盆冷水迁移工具只是把目录相关部分机械地转换真正决定迁移质量的还是迁移前的权限清理和岗位模型梳理。指望一键迁移不现实90% 的工作量在准备阶段。我用过一个笨办法迁移后把新旧角色的授权对象清单导出来做 diff逐条复核多出来的和少掉的。这个办法土但最可靠。你会在 diff 里发现很多想不到的历史包袱比如某个角色里居然有 SAP_ALL 子集授权这种问题早发现早处理拖到审计就晚了。4.3 混合模式的边界谁负责应用权限谁负责后台事务迁移完成后系统里长期存在双轨制。这个时候最容易乱的是边界——业务角色和技术角色到底以什么为界我的标准很简单凡是 Fiori 应用的前端可见性、OData 服务调用一律交给业务角色凡是 SAP GUI 事务码、旧式授权对象、批处理作业需要的后台权限一律交给技术角色遇到两端都涉及的对象宁可两边各配一次也不要集中在某一侧。举个例子一个 Fiori 应用底层调用了 BAPI 去更新采购订单这个 BAPI 的调用权限Catalog 的默认值可能不会覆盖。这时候业务角色里需要补充 BAPI 相关的授权对象。同一段时间里用户也通过 GUI 的 ME22N 维护采购订单技术角色里也有对应的 S_TCODE。两边各配各的互不干扰审计时也能说清楚每个权限是为哪个入口配的。5. 上线之后如何让角色体系扛得住业务变化5.1 目录更新与角色再生成不做这一步等于白配上线之后角色体系真正的考验才刚开始。SAP 标准目录会跟着 Support Package 升级而变化可能新增一个应用可能给现有应用增加一个新 OData 服务。目录变了不代表你的业务角色自动跟进。我踩过一次很深的坑S/4HANA 版本升级后财务团队的新应用已经发布到生产环境用户却集体无法访问。查了一圈发现标准目录虽然更新了但业务角色没有重新生成授权 profile新应用的 OData 服务授权根本没有进入用户的生效 profile。这种问题在测试环境往往发现不了因为测试用的角色是升级后新创建的生产环境里跑的却是升级前创建的角色profile 还是旧的。所以我把目录变更 - 角色再生成 - 传输到生产写进了权限变更 SOP并且在每次系统升级后安排一次全量核对把生产环境里所有业务角色的 profile 生成日期和目录版本对照一遍有出入立即补生成。这个检查不难但漏掉一次就可能出一次事故。5.2 传输顺序与多系统一致性Business Catalog 和业务角色是通过 CTS 传输的在开发系统维护、测试验证、然后传到生产。传输顺序有个容易被忽略的细节先传目录定义再传角色最后传空间和页面。如果角色先传到了目标系统而目录还没到角色里的目录引用就会出现断链用户在 Launchpad 上看不到任何应用或者角色保存报错。空间和页面又依赖于角色里的目录信息所以放在最后传。跨系统的顺序错了轻则重复传一次重则把生产环境的角色状态搞乱。另外多系统一致性不能只靠传输顺序。我建议在 QAS 和 PRD 之间做一个月度角色对比报告重点检查相同业务角色在三系统的目录挂接是否一致、profile 生成时间是否一致、关键用户分配的角色清单是否漂移。这些对比用 SUIM 导出来就能做并不复杂但能避免测试没问题生产有问题的经典尴尬。5.3 定期巡检清单与常见治理手段角色体系越庞大越需要制度化巡检。我在项目里定的巡检清单是这样的大家可以参考巡检项频率工具/方法用户角色分配与岗位职责是否匹配月度SUIM 用户角色分析是否存在长期未用角色僵尸角色月度登录日志 SUIM 对比业务角色的 profile 是否最新系统升级后比对生成日期与目录版本目录挂接是否有重复或冲突季度角色 vs 目录导出 diff高权限用户SAP_ALL、超级用户名单季度SUIM 用户信息报表自定义目录权限是否过度开放季度审核自定义目录的 OData 服务清单巡检不是目的治理才是。我个人的经验是权限变更必须走传输禁止在生产环境直接改角色和目录。这条规则看起来死板却能挡掉 90% 的权限事故。生产环境直接改权限改完没有测试、没有留痕、没有回退路径一旦出问题就是线上故障而且你连改了什么可能都想不起来。最后分享一个我坚持了很多年的小习惯每次给新应用、新目录做完权限配置都用全新测试用户 仅分配目标角色 开启 SU53/网关日志的方式来验收而不是拿自己的账号随便点两下就认为没问题。很多看似是 Catalog 配错的问题根因其实是残留旧 profile、空间没分配、或者缓存没刷新。用干净的测试用户跑一遍主流程这些问题都会原形毕露。这套方法不算高深但它帮我避过的雷比任何一篇官方文档都多。