Get Example source ABAP code based on a different SAP table
ABAP_RAP - Validation This example demonstrates how a validation is defined, implemented, and consumed in a managed RAP BO. Data model> The CDS data model consists of the root view entity DEMO_SALES_CDS_SO_1 >, which represents a sales order. DDLS DEMO_SALES_CDS_SO_1 Behavior definition> The RAP behavior definition> DEMO_SALES_CDS_SO_1>> is defined in RAP BDL> as follows: BDEF DEMO_SALES_CDS_SO_1 Definition of validation> The validation ValidateBuyerId> checks if the value entered in field BuyerId> is valid by checking whether this buyer ID exists in the database table DEMO_SALES_BUPA> >, which lists all business partners. It is triggered as soon as the field BuyerId> is changed. If the buyer ID is not valid, the data changes are rejected and an error message is returned. validation ValidateBuyerId on save { field BuyerId; }> Behavior implementation> For the above RAP behavior definition, one ABAP behavior pool (ABP)> is created. The global class of the behavior pool is BP_DEMO_SALES_CDS_SO_1>>. The actual implementation takes place in the BP_DEMO_SALES_CDS_SO_1========CCIMP>>.
ABAP_SOURCE_CODE DEMO CL_DEMO_CDS_VALIDATION
ABAP_DESCRIPTION Access with ABAP using EML> The above source code uses EML> to access the RAP business object from an ABAP class:
A BO entity instance with the buyer ID a> is created. This is a valid buyer ID, so the instance is committed to the database.
Two further BO entity instances are created with invalid buyer IDs. These entity instances are rejected by the validation and they are inserted into an error table instead.
The valid and the invalid entity instances are created in separate RAP transactions>. If all three entity instances were created in one RAP transaction, all three of them would be rejected. All data changes in one RAP transaction must be consistent, otherwise, the complete content of the transactional buffer is rejected.