Ansicht
Dokumentation

ABENDERIVED_TYPES_FAIL_ABEXA - DERIVED TYPES FAIL ABEXA

ABAP Short Reference   TXBHW - Original Tax Base Amount in Local Currency  
This documentation is copyright by SAP AG.

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:

Behavior definition

The CDS behavior definition DEMO_MANAGED_ROOT_FAILED 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_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.
  
  

Source Code

Execute

Description

Access with ABAP using EML

The program includes multiple requests:

1. 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.
2. 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 requests is also shown in an internal table.
3. 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.

ROGBILLS - Synchronize billing plans   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
This documentation is copyright by SAP AG.

Length: 5002 Date: 20240512 Time: 081426     sap01-206 ( 77 ms )