SAP GET PERM DYN FORM ABEXA



Get Example source ABAP code based on a different SAP table
  



ABAP_EML - GET PERMISSIONS, Dynamic Form
This example demonstrates the dynamic form of the GET PERMISSIONS statement using the addition ONLY INSTANCE FEATURES.
Data model
The CDS data model consists of the root entity DEMO_MANAGED_ROOT_3 and its child entity DEMO_MANAGED_CHILD_3.
Root entity:
DDLS DEMO_MANAGED_ROOT_3
Child entity:
DDLS DEMO_MANAGED_CHILD_3
Behavior definition
The RAP behavior definition DEMO_MANAGED_ROOT_3 is defined in RAP BDL as follows:
BDEF DEMO_MANAGED_ROOT_3
Behavior implementation
For the above RAP behavior definition, one ABP is created. The global class of the behavior pool is BP_DEMO_MANAGED_ROOT_3. The actual behavior implementation takes place in local classes that are defined and implemented in the BP_DEMO_MANAGED_ROOT_3========CCIMP of the behavior pool.
The following method is relevant in this example:
get_instance_features The dynamic form of GET PERMISSIONS used in the example requests the permissions for instance features. The method is implemented in a way that returns information on whether certain fields ( data_field3_root and data_field4_root) 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 disabled or enabled. As a prerequisite in the BDEF, the two fields and the associated entity have the required notation: association _child { create( features : instance ); }
field ( features : instance ) data_field3_root, data_field4_root;

ABAP_SOURCE_CODE
DEMO CL_DEMO_RAP_EML_GET_PERM_DYN

ABAP_DESCRIPTION
Access with ABAP using EML
The above source code uses EML to access the RAP business object from an ABAP class:
Using the dynamic form of the GET PERMISSIONS statement, permissions are requested for specific instances of an entity. The addition ONLY INSTANCE FEATURES is used in the statement to get the permissions, as the name implies, for the instance feature controls only.
As a first step, the database tables that are used in the example are emptied and filled again with demo values as a basis for the example. Request parameters for the root and child entity are then specified. In this case, all fields, operations and one associated entity (the child entity) are enabled. These parameters are used in the GET PERMISSIONS statement.
Dynamic Form
The GET PERMISSIONS statement considers certain instances with keys that are specified after the keyword FROM. The request parameter has been specified before. The result parameter is of type TYPE STRUCTURE FOR PERMISSIONS RESULT and created inline. Response parameters are also specified, however, they are not used in the example.
The GET PERMISSIONS statement includes requests for the root entity and the child entity individually.
Notes on the result for the root entity, i. e. the content in the output tables:
Entries in the instance table: The entries for the instance with key 1 show that the field assoc has the value 01. According to the implementation, a create-by-association operation is disabled in this case. The entries for both instances with the keys 1 and 2 show the value 02 (that is, read-only) for the data field data_field1_root since it was defined as readonly in the BDEF. It is a static feature control also displayed in this context (see the Guidelines for the Permission Result). The entries for data_field3_root and data_field4_root are determined by the get_instance_features method. The value 00 is available if the permission is unrestricted, 02 if the permissions is read-only.
Entries in the global structure: The result also contains static information (see the Guidelines for the Permission Result). In this example, it is as follows: The key key_field shows the value 20 (that is, readonly:update ) and the field data_field2_root shows the value 01 (i. e. mandatory), the field data_field1_root shows the value 02 (i. e. readonly) as defined in the BDEF.
Notes on the result for the child entity:
Similar to above, request parameters have been specified before, certain instances with specified keys are considered (following the keyword FROM) and the result parameter is declared inline. Response parameters are declared, too, but not relevant in the example.
Entries in the instance table: The key field of the child entity has the value 02 (i. e. unauthorized) which means a create-by-association operations is disabled in the context of the particular instance.
Entries in the global structure: The result also contains static information. Hence, the field for the key of the child entity shows the value 02 (i. e. read-only) as defined in the BDEF (readonly ).