Ansicht
Dokumentation

ABENCOMMIT_ENTITIES_SIM_MOD_ABEXA - COMMIT ENTITIES SIM MOD ABEXA

ABAP Short Reference   Fill RESBD Structure from EBP Component Structure  
This documentation is copyright by SAP AG.

- 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 CDS behavior definition DEMO_CDS_UPDATE is defined in CDS BDL as follows:

Behavior implementation

For the above CDS 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.

Source Code

Execute

Description

The example shows a program 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 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 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 program 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.

• 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 modify request includes an UPDATE operation with which a particular field (col1) is to be updated. The 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 program 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.

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

rdisp/max_wprun_time - Maximum work process run time   BAL Application Log Documentation  
This documentation is copyright by SAP AG.

Length: 4571 Date: 20240425 Time: 150515     sap01-206 ( 77 ms )