在一个真正投入生产运行的 SAP S/4HANA 业务应用里，能不能把某个按钮显示出来只是表面问题，更关键的问题是，当某个业务用户通过 Fiori Elements、OData、ABAP EML，甚至其他集成接口调用业务对象时，后端到底依据什么判断这次操作是否允许执行。以采购申请为例，业务人员可能都能够进入同一个应用，也都能够读取采购申请，但权限边界往往并不相同。普通申请人可以创建采购申请，却不能删除已经进入审批流程的申请。采购部门管理员可以修改本公司代码下的采购申请，却不能修改另外一个公司代码的数据。某些财务用户拥有查看权限，却没有执行Approve或RejectAction 的权限。如果这些限制只写在 SAPUI5 页面里，安全性几乎不存在。调用方完全可以绕开 UI，直接向 OData Endpoint 发起请求。RAP 因此把 Authorization Control 放在 Business Object 行为层，而不是单纯依赖前端。SAP 官方对 RAP Authorization Control 的定位很明确，它用于控制某个消费者是否有资格执行标准操作、Action 或 Function。授权既可以只和当前用户有关，也可以进一步和当前 Business Object Instance 的状态或字段值有关。前者对应Global Authorization，后者对应Instance Authorization。这两个概念看起来只差了一个作用范围，实际开发时却直接决定权限检查应该放在哪里、需要读取哪些业务数据，以及哪些操作甚至不具备执行 Instance Au
