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.