一套典型的DEV → QAS → PRDSAP 系统链路搭起来以后，权限团队很快就会碰到一个看起来简单、真正操作起来却相当容易踩坑的问题。开发系统里的PFCG角色已经调好了，OData 服务已经加入角色菜单，授权对象的组织级别也维护好了，测试用户跑 SAP Fiori 应用完全正常。到了质量系统甚至生产系统，我们当然不希望再手工把几十个角色、几百项授权值重新敲一遍，于是很自然地会想到 Export 和 Import。问题就在这里。SAP 权限体系里的 Role、Authorization、Authorization Profile、User Master Record 看起来都与权限有关，却不是同一种生命周期对象，也不能按照完全相同的方式迁移。SAP Gateway 官方文档对这个场景给出的出发点很明确，我们有可能需要把某一个 SAP System Client 中的 Authorization、Profile、User Master Record、Role 等对象取得出来，再带入承载 SAP Gateway 的目标系统。不过到了真正实施时，不能把这句话理解成把整个权限环境打成一个包，再原样导进另一套系统。不同对象采用的机制并不一样，尤其 User Master Record 与PFCGRole 之间存在非常重要的边界。先把几个概念摆在同一张脑图里会清楚很多。在经典 ABAP Authorization Model 中，Role 是我们日常最常维护的对象。进入事务码PFCG，一个 Single Role 里面可以包含菜单、事务、Web Dynpro 应用、OData Service SAP Gateway 权限迁移实战，搞清角色、用户主记录与授权对象到底该怎么搬
一套典型的DEV → QAS → PRDSAP 系统链路搭起来以后，权限团队很快就会碰到一个看起来简单、真正操作起来却相当容易踩坑的问题。开发系统里的PFCG角色已经调好了，OData 服务已经加入角色菜单，授权对象的组织级别也维护好了，测试用户跑 SAP Fiori 应用完全正常。到了质量系统甚至生产系统，我们当然不希望再手工把几十个角色、几百项授权值重新敲一遍，于是很自然地会想到 Export 和 Import。问题就在这里。SAP 权限体系里的 Role、Authorization、Authorization Profile、User Master Record 看起来都与权限有关，却不是同一种生命周期对象，也不能按照完全相同的方式迁移。SAP Gateway 官方文档对这个场景给出的出发点很明确，我们有可能需要把某一个 SAP System Client 中的 Authorization、Profile、User Master Record、Role 等对象取得出来，再带入承载 SAP Gateway 的目标系统。不过到了真正实施时，不能把这句话理解成把整个权限环境打成一个包，再原样导进另一套系统。不同对象采用的机制并不一样，尤其 User Master Record 与PFCGRole 之间存在非常重要的边界。先把几个概念摆在同一张脑图里会清楚很多。在经典 ABAP Authorization Model 中，Role 是我们日常最常维护的对象。进入事务码PFCG，一个 Single Role 里面可以包含菜单、事务、Web Dynpro 应用、OData Service RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
代码包深度解析与实践指南)
