Get Example source ABAP code based on a different SAP table
Using %fail This example demonstrates the use of %fail with a managed RAP BO. Data model The CDS data model consists of the root entity DEMO_MANAGED_ROOT_FAILED and its child entity DEMO_MANAGED_CHILD_FAILED. The child entity is not used in the example. Root entity: DDLS DEMO_MANAGED_ROOT_FAILED Behavior definition The RAP behavior definition DEMO_MANAGED_ROOT_FAILED is defined in RAP BDL as follows: BDEF DEMO_MANAGED_ROOT_FAILED Behavior implementation For the above RAP behavior definition, one ABP is created. The global class of the behavior pool is BP_DEMO_MANAGED_ROOT_FAILED. The actual behavior implementation takes place in local classes that are defined and implemented in the BP_DEMO_MANAGED_ROOT_FAILED===CCIMP of the behavior pool. The following methods are relevant for the example:
get_instance_authorizations: If an instance has a specific value in a field, the update and delete operations should be denied, i. e. the operations are marked as unauthorized. %fail-cause is assigned accordingly. %fail-cause and the key of the RAP BO instance is stored in the failed response structure.
get_instance_features: If an instance has a specific value in a field, update operations should be denied, i. e. the operations are marked as readonly. %fail-cause is assigned accordingly. %fail-cause and the key of the RAP BO instance is stored in the failed response structure.
ABAP_SOURCE_CODE DEMO CL_DEMO_RAP_DRVD_TYPES_FAIL
ABAP_DESCRIPTION Access with ABAP using EML The class includes multiple ABAP_EML requests: ABAP_EML modify request: Multiple RAP BO instances are created. A COMMIT ENTITIES statement triggers the saving of the instances to the database. The output shows for all requests the content of the failed response. In this case, none of the instances show any failures. Furthermore, an internal table is filled with the database table entries. In the output, all newly created RAP BO instances have been saved to the database and are displayed in the internal table. ABAP_EML update and delete requests: Specific RAP BO instances are updated and deleted. The outcome of calling the get_instance_authorizations and get_instance_features is that several instances cannot be updated and deleted because of the conditions implemented in the methods. Since these methods fill the failed responses, an internal table that contains the entries of the failed response consequently shows the different failure causes for those RAP BO instances that could not be saved to or deleted from the database table. %fail-cause is in this case READONLY and UNAUTHORIZED. As above, a COMMIT ENTITIES statement saves those instances that did not show any failures. The outcome of these ABAP_EML requests is also shown in an internal table. ABAP_EML read request: Multiple RAP BO instances are read from the database table. The read result is stored in an internal table which is displayed in the output. Since not all instances that are requested exist on the database table, an internal table containing the failed response consequently shows entries. %fail-cause is in this case NOT_FOUND.
