Get Example source ABAP code based on a different SAP table
ABAP_EML - COMMIT ENTITIES, Dynamic Form This example demonstrates the dynamic form of the COMMIT ENTITIES statement. Data model The CDS data model consists of two simple root entities:
DEMO_MANAGED_ROOT_2
DEMO_MANAGED_ASSOC_CUSTOM They are not related to each other and are only used to have responses for more than one root entity in the example. Associations and child entities are of no relevance in this example. Behavior definition The RAP behavior definition of entity DEMO_MANAGED_ROOT_2 contains the following notation for the validation validate_field in the body: validation validate_field on save { field data_field4_root; } Likewise, the entity DEMO_MANAGED_ASSOC_CUSTOM contains the following notation for the validation validate_field in the body: validation validate_field on save { field data_field4_assoc; } Behavior implementation For both of the above RAP behavior definitions, there are ABAP behavior pools (ABP) available. The actual implementation takes place in the BP_DEMO_MANAGED_ROOT_2========CCIMP of ABP BP_DEMO_MANAGED_ROOT_2 and BP_DEMO_MANAGED_ASSOC_CUSTOM==CCIMP of ABP BP_DEMO_MANAGED_ASSOC_CUSTOM respectively. The method validate_field has the following logic:
First, all instances of the entities with the provided keys are read into an internal table using the keyword READ ENTITIES.
It is then checked whether the number of a certain data field is higher than the value that is allowed. In case of entity DEMO_MANAGED_ROOT_2, the data field data_field4_root should not be higher than 50. In case of entity DEMO_MANAGED_ASSOC_CUSTOM, the data field data_field4_assoc should not be higher than 10000. If the values are higher, the FAILED and REPORTED structures are filled with information for the respective failed entry.
ABAP_SOURCE_CODE DEMO CL_DEMO_RAP_EML_COMMIT_2
ABAP_DESCRIPTION Access with ABAP using EML The above source code uses EML to access the RAP business object from an ABAP class:
Two MODIFY operations for two different root entities are carried out within one RAP transaction to create several instances using the keyword CREATE.
For these newly created instances, the validations are successful and they are saved to the database using COMMIT ENTITIES. The saved data sets are then read from the database tables into internal tables to display the outcome of the MODIFY operations and the successful saving to the database. Afterwards, the database tables are emptied using the method initialize_dbtabs( ).
COMMIT ENTITIES RESPONSE OF ... Two rounds of MODIFY operations are carried out on two different entities, one round with valid entries, the other containing invalid entries. Validations always accept or reject data changes per RAP transaction. Therefore, if the validation fails only for one instance, the complete content of the transactional buffer is rejected. In case of a failed validation, the FAILED and REPORTED structures are filled with information on the failed instances.
The internal table dyn_tab is set up to hold those root entities for which responses should be retrieved.
First round: MODIFY operations are carried out on two root entities using the keyword CREATE to create new instances. The COMMIT ENTITIES RESPONSES OF ... statement includes the FAILED and REPORTED responses for both of the root entities since dyn_tab was specified accordingly. Upon committing, the validation method in the ABP is called. Since all instances are valid, all of them are saved to the database table. There are no FAILED and REPORTED responses. The saved data sets are then read from the database tables into internal tables to display the outcome of the MODIFY operations and the successful saving to the database. Afterwards, the database is emptied.
Second round: Same as before, MODIFY operations are carried out on the two root entities using the keyword CREATE to create new instances, yet with entries for which the validation will fail (the number of the fourth data field is higher than the allowed value in the validation method). For each entity, there is one valid entry and two invalid entries. Also here, the COMMIT ENTITIES RESPONSES OF ... statement includes the FAILED and REPORTED responses for both of the root entities as the internal table dyn_tab was specified accordingly. Upon committing, the validation method in the respective ABP is called. The methods ensure that the response structures are filled with information on those instances for which the validation failed. Due to the fact that invalid entries exist, these instances are not saved to database as well as those instances with valid entries. All instances of the whole RAP transaction are not saved. All data sets are then read from the database tables into internal tables to display the outcome of the MODIFY operations. Consequently, there are no data sets to be displayed because of the failed saving. Two internal tables are created to display parts of the accumulated FAILED responses for all root entities specified in dyn_tab and parts of the accumulated REPORTED responses. ABAP_NOTE No further data changes are possible as long as the invalid instances are not corrected. An invalid entity instance must either be corrected using an UPDATE operation, or it must be deleted using the ROLLBACK ENTITIES statement. Otherwise, no further data changes are possible.
