Ansicht
Dokumentation

ABENCOMMIT_ENTITIES_SH_LO_ABEXA - COMMIT ENTITIES SH LO ABEXA

ROGBILLS - Synchronize billing plans   General Data in Customer Master  
This documentation is copyright by SAP AG.

- COMMIT ENTITIES, Short and Long Form

This example demonstrates two variants of the COMMIT ENTITIES statement: the short version (without responses) and long form (with responses). It covers several MODIFY operations for creating instances for two root entities in a simplified managed scenario. The saving of these instances is triggered by COMMIT ENTITIES statements.

For the purpose of showing entries in the FAILED and REPORTED structures in the context of the long version, a validation is implemented in the behavior pool that causes the saving of certain entries to fail and fills the response structures.

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 CDS 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 CDS 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.

• Consequently, once the validation method is called and the save sequence is triggered upon committing, the saving of all instances to the database table fails including those instances for which the validation did not fail. See more information on validations in the CDS BDL Documentation.

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 and shows an example for both, short and long version of the COMMIT ENTITIES statement:

• COMMIT ENTITIES.

Two MODIFY operations for two different root entities are carried out within one RAP LUW to create several instances using the keyword CREATE. These newly created instances are saved to the database tables when triggering the save phase with the COMMIT ENTITIES. statement. It is just about saving the created entries, responses are not of interest. 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.

• 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. Due to the implemented validation, it is ensured that no instance from the transactional buffer is saved if the validation fails for one or more of the instances created within the RAP LUW. In case of a failed validation, the FAILED and REPORTED structures are filled with information on the failed instances.

First round: MODIFY operations are carried out on two root entities using the keyword CREATE to create new instances. The COMMIT ENTITIES RESPONSE OF ... statement includes the FAILED and REPORTED responses for both of the root entities. 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 RESPONSE OF ... statement includes the FAILED and REPORTED responses for both of the root entities. 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 the database as well as those instances with valid entries. All instances of the whole RAP LUW 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 the saving failed for all instances. Two internal tables are created and displayed per entity that show parts of the FAILED and REPORTED responses returned for those instances for which the validation failed.

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.

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   Vendor Master (General Section)  
This documentation is copyright by SAP AG.

Length: 8449 Date: 20240426 Time: 085530     sap01-206 ( 139 ms )