Get Example source ABAP code based on a different SAP table
BDEF Derived Type Components in the Context of Requesting Permissions This example demonstrates the use of the various BDEF derived type components with a managed RAP BO in the context of requesting permissions using multiple GET PERMISSIONS statements with variants of the ONLY clause :
%action
%assoc
%create
%delete
%features
%field
%op
%perm Data model The CDS data model consists of the root entity DEMO_MANAGED_ROOT_PERM and its child entity DEMO_MANAGED_CHILD_PERM. The child entity is not used in the example. Root entity: DDLS DEMO_MANAGED_ROOT_REPORTED Behavior definition The RAP behavior definition DEMO_MANAGED_ROOT_PERM is defined in RAP BDL as follows: BDEF DEMO_MANAGED_ROOT_PERM Behavior implementation For the above RAP behavior definition, one ABP is created. The global class of the behavior pool is BP_DEMO_MANAGED_ROOT_PERM. The actual behavior implementation takes place in local classes that are defined and implemented in the BP_DEMO_MANAGED_ROOT_PERM=====CCIMP of the behavior pool. The following methods are relevant for this example:
get_instance_features The method returns information on whether certain fields are read-only or can be modified based on certain conditions. Additionally, information is returned if the creation of instances for an associated entity ( _child) is enabled or disabled. As a prerequisite in the BDEF, the two fields and the associated entity have the required notation ( features: instance ). In the context of this method, the component %features is used.
get_global_features The method returns information on whether update operations on entities and the execution of an action are allowed or not based on a certain condition, that is, updating and executing the action is only allowed within a certain time span. As a prerequisite in the BDEF, update and the action have the required notation ( features: global ) .
get_global_authorizations The method is implemented in a way that create and delete operations are only enabled for users with the appropriate authorizations. In the interest of having a simple demo, the example goes without an authorization object which is, for example, a way to handle the authorization granting in production applications. The variable auth_flag represents the authorization that is granted or not. In this case, the permission is not granted. As a prerequisite in the BDEF, the notation authorization master ( global ) exists. In this example, instance authorizations are also covered, hence, the notation is authorization master ( global, instance ) in the BDEF.
get_instance_authorizations The method returns information on whether delete operations and executions of an action are allowed on instances. In this example, deletion and action execution are not allowed if a field has a particular value. As a prerequisite in the BDEF, the notation authorization master ( instance ) exists. In this example, global authorizations are also covered, hence, the notation is authorization master ( global, instance ) in the BDEF . In the context of this method, the component %op is used.
ABAP_SOURCE_CODE DEMO CL_DEMO_RAP_DRVD_TYPES_PERM
ABAP_DESCRIPTION The above source code uses EML to access the RAP business object from an ABAP class: The example covers most variants of only_clause using the short form of the GET PERMISSIONS statement. As a first step, the database table that is used in the example is emptied and filled again with demo values as a basis for the example. Request parameters for an entity are then specified. In this case, all fields, standard and nonstandard operations, and an associated entity (the child entity) are enabled. These parameters are used in all GET PERMISSIONS statements. All statements use the same input keys (except those statements where specifying the keys is not allowed) and include response parameters that are not used in the example. The result of the individual GET PERMISSIONS statements is displayed in the output showing both instance table and global structure (see TYPE STRUCTURE FOR PERMISSIONS RESULT). Notes on the result, i. e. the entries in the output tables:
ONLY GLOBAL There are no entries in the instance table. The global structure includes the global authorization (the value 02, i. e. IF_ABAP_BEHV=>PERM-O-UNAUTHORIZED, for the create and delete operation), and global feature controls (the values of %update and %action-action either show 00 for enabled or 01 for disabled). Furthermore, static information is available, too: The fields %field-key_field and the field %field-field2 show the value 01 (i. e. mandatory), the field %field-field1 shows the value 02 (i. e. readonly ) as defined in the BDEF.
ONLY GLOBAL FEATURES There are no entries in the instance table. The global structure includes the global feature control and static information (see the details above for ONLY GLOBAL).
ONLY GLOBAL AUTHORIZATION There are no entries in the instance table. The global structure includes information on global authorization. The value 02 , i. e. IF_ABAP_BEHV=>PERM-O-UNAUTHORIZED, for the create and delete operation is displayed.
ONLY INSTANCE The instance table includes information on instance-based authorization and instance-based feature control plus static information. According to the method get_instance_features , the value of %assoc-_child is 01 for the instance with key 1 denoting that the create-by-association operation is disabled in the context of this instance. In contrast to that, the operation is allowed for the instance with key 2 (the value is 00). The read-only field field-field1 shows the value 02, i. e. IF_ABAP_BEHV=>PERM-F-READ_ONLY. %field-field3 and field-field4 show the values of the result after calling the get_instance_features method. The instance with the key 2 shows the value 02 for %delete as a result of calling the method get_instance_authorizations. The global structure includes the static information as outlined above for ONLY GLOBAL .
ONLY INSTANCE FEATURES The instance table includes information on instance-based feature control. It shows the same values for both instance table and global structure as above for ONLY INSTANCE except for the instance-based authorization part (i. e. the instance with the key 2 does not include the result of the delete operation here).
ONLY INSTANCE AUTHORIZATION The instance table includes information on instance-based authorization. The instance with the key 2 shows the value 02 for delete as a result of calling the method get_instance_authorizations. The instance with the key 1 is not included at all in the result. The global structure does not include any relevant values.
ONLY FEATURES The instance table includes information on instance-based feature control plus static information (see the details above for ONLY INSTANCE except for the instance-based authorization part). The global structure includes the global feature control and static information (see the details above for ONLY GLOBAL except for the global authorization part).
ONLY AUTHORIZATION The instance table includes information on instance-based authorization (see the details above for ONLY INSTANCE AUTHORIZATION ). The global structure includes the information on global authorization (see the details above for ONLY GLOBAL AUTHORIZATION ).
ONLY AUTHORIZATION (focus on %perm component group) The implementation in the class serves the purpose of visualizing the %perm component group that is contained in the permission result of GET PERMISSIONS statements and how subcomponents of the result might be referred to. The result is of type TYPE STRUCTURE FOR PERMISSIONS RESULT . In the example, a structure type is set up containing the instance key as well as the subcomponents of %perm. An internal table is declared that is filled with the permission result from the instance table. The output shows this internal table. The outcome of the permission result corresponds to the entries in the instance table from the previous example with ONLY AUTHORIZATION.
