SAP BDL AUTHORIZATION ABEXA



Get Example source ABAP code based on a different SAP table
  



ABAP_RAP - Global Authorization
This example demonstrates how a global authorization check is defined, implemented, and consumed in an unmanaged RAP BO.
Data model
The CDS data model consists of the root entity DEMO_RAP_UNMANAGED_AUTH and its child entity DEMO_RAP_UNMANAGED_AUTH_CHILD.
Root entity:
DDLS DEMO_RAP_UNMANAGED_AUTH
Child entity:
DDLS DEMO_RAP_UNMANAGED_AUTH_CHILD
Behavior definition
The RAP behavior definition DEMO_RAP_UNMANAGED_AUTH is defined in RAP BDL as shown below. It defines the root view entity as authorization master entity and the child entity as authorization dependent entity.
BDEF DEMO_RAP_UNMANAGED_AUTH
Behavior implementation
For the above RAP behavior definition, one ABAP behavior pool (ABP) is created. The global class of the behavior pool is BP_DEMO_RAP_UNMANAGED_AUTH. This global class implements the method get_global_auth for global authorization control (see BP_DEMO_RAP_UNMANAGED_AUTH====CCIMP). It works as follows:
For incoming update requests, authorization is always granted.
For incoming delete requests, authorization is always rejected and an error message is written into the REPORTED structure. ABAP_NOTE This example is intentionally kept short and simple and serves demonstration purposes only. A realistic implementation requires an instance-independent authorization check, for example, based on authorization objects.

ABAP_SOURCE_CODE
DEMO CL_DEMO_RAP_UNMANAGED_AUTH

ABAP_DESCRIPTION
Access with ABAP using EML
The above source code uses EML to access the RAP business object from an ABAP class:
Three instances of the parent entity and two instances of the child entity are created with the statement MODIFY ENTITY.
Two instances of the parent entity are updated. This update is authorized.
The EML consumer tries to delete an instance of the parent entity and an instance of the child entity. The delete operation on the parent entity is not authorized and the operation fails. The delete operation on the child entity is directed to the authorization master entity (in this example the same as the parent entity). It is interpreted as update request of the authorization master entity. Update operations are authorized, so the delete operation of the child entity instance is successful.
Using the AB_SQL SELECT statement, the content of the parent and child tables after the create, update, and delete operations are displayed. For the failed delete operation of the parent entity, an error message is returned.