Get Example source ABAP code based on a different SAP table
VX_EXA_ONLY
ABAP_EML - COMMIT ENTITIES IN SIMULATION MODE This example demonstrates the COMMIT ENTITIES IN SIMULATION MODE statement. Data model The CDS data model consists of the root entity DEMO_CDS_UPDATE. Behavior definition The RAP behavior definition DEMO_CDS_UPDATE is defined in RAP BDL as follows: BDEF DEMO_CDS_UPDATE Behavior implementation For the above RAP behavior definitions, there is an ABAP behavior pool (ABP) available: BP_DEMO_CDS_UPDATE. The actual implementation takes place in the BP_DEMO_CDS_UPDATE============CCIMP. The following method is relevant for the example:
validatecol1 The validation checks the consistency of RAP business object instances based on the condition that the field col1 should not have a value greater than 5000. If it is larger, the REPORTED structure is filled with an error message.
ABAP_DESCRIPTION The example shows a class divided into segments by switching the work process. It reuses elements of the example SAP LUW, UPDATE TASK. See more details and descriptions there. In this example here, the mixing of data modification via update function modules and ABAP_EML modify requests in SAP LUWs can be considered as a non-RAP application modifying data while including another RAP implementation. To ensure that the overall SAP LUW is consistent with regards to saving which is finally triggered by a COMMIT WORK statement, the ABAP_EML modify requests are followed by a COMMIT ENTITIES statement with the addition IN SIMULATION MODE that omits the actual saving but includes validating the data before it can be saved. The class shows the following aspects:
The database table is cleared and new data is created. First, the database table for which data is created and updated, is cleared using a function module. Then, data is created using another function module. Following a COMMIT WORK statement, the data is persisted to the database table.
ABAP_EML modify request is included in the SAP LUW, COMMIT WORK is not executed. Further data modification is done using function modules followed by an EML modify request. The ABAP_EML modify request includes an UPDATE operation with which a particular field (col1) is to be updated. The ABAP_EML MODIFY ENTITY statement is succeeded by COMMIT ENTITIES IN SIMULATION MODE that checks the consistency before actually finishing the LUW with a COMMIT WORK statement and, thus, a final saving. The validation ValidateCol1 that is implemented for the RAP BO fails and fills the REPORTED response parameter. As a consequence, the class is implemented in a way that the saving of all the data, i. e. the data modifications done via RAP and non-RAP implementations, is prevented.
ABAP_EML modify request is included in the SAP LUW, COMMIT WORK is executed. The same data manipulation is carried out as above using function modules and an ABAP_EML modify request. However, the request includes values for the field col1 so that the validation does not fail. Hence, all the data modifications done via RAP and non-RAP implementations is committed and persisted to the database. The output window shows tables that contain the database entries. In the case in which COMMIT WORK is not triggered, the REPORTED response from the RAP BO implementation is displayed.
