Ansicht
Dokumentation

ABENGET_PERM_FORMS_ABEXA - GET PERM FORMS ABEXA

ABENGET_PERM_FORMS_ABEXA - GET PERM FORMS ABEXA

BAL Application Log Documentation   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
This documentation is copyright by SAP AG.
SAP E-Book

- GET PERMISSIONS, Variants

This example demonstrates the variants of the GET PERMISSIONS statement using the addition ONLY INSTANCE FEATURES:

  • GET PERMISSIONS ENTITY bdef (short form)
  • GET PERMISSIONS OF bdef (long form)
  • GET PERMISSIONS OPERATIONS (dynamic form)

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:

Child entity:

Behavior definition

The CDS behavior definition DEMO_MANAGED_ROOT_3 is defined in CDS BDL as follows:

Behavior implementation

For the above CDS 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
All variants of GET PERMISSIONS used in the example request 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;

Source Code

Execute

Description

Access with ABAP using EML

The above source code uses EML to access the RAP business object from an ABAP program:

Using the short, long and dynamic form of the GET PERMISSIONS statement, permissions are requested for specific instances of an entity. The addition ONLY INSTANCE FEATURES is used in each of the statements 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 all GET PERMISSIONS statements.

Short 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.
  • To display the result of the permission request on the output screen, internal tables are created, one containing the entries of the instance table, the other containing the entries of the global structure. When executing the program and when the compiler reaches the GET PERMISSIONS statements, the method get_instance_features is called that fills the result accordingly.
  • Notes on the result, 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 (in the output table it is named _key_field referring to the value in %fields to avoid having the same name as the actual instance key key_field contained in the instance table) and the field data_field2_root show the value 01 (i. e. mandatory), the field data_field1_root shows the value 02 (i. e. readonly) as defined in the BDEF.

Long form

  • The GET PERMISSIONS statement includes requests for the root entity and the child entity individually.
  • Result for the root entity:
It is the same request as in the short form on the root entity, yet using different keys. Consequently, the output is similar to the one of the short form. Since the values of the instances are different, the values of data_field3_root and data_field4_root are arranged differently in the result after calling the implemented method.
  • 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. Additionally, internal tables for the child entity are set up to display the results in the output screen, too.
Notes on the result, i. e. the content in the output tables for the child entity:
  • Entries in the instance table: The key field of the child entity (in the table, it is _key_field) 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).

Dynamic Form

The GET PERMISSIONS statement is basically set up similar to the long form example. The request is done with different keys but due to the individual values of the instances' fields, the results and, thus, the output tables show the same values for the root and child entity as in the long form example.






CL_GUI_FRONTEND_SERVICES - Frontend Services   General Material Data  
This documentation is copyright by SAP AG.

Length: 8887 Date: 20240329 Time: 005540     sap01-206 ( 149 ms )