Get Example source ABAP code based on a different SAP table
Example for RAP Saver Methods (Late Numbering Scenario) This example demonstrates RAP saver methods within a RAP saver class using a simple unmanaged RAP BO with late numbering to also cover the adjust_numbers saver method. Data model The CDS data model consists of the root entity DEMO_UMANAGED_ROOT_LATE_NUM2 and its child entity DEMO_UMANAGED_CHILD_LATE_NUM2. Root entity: DDLS DEMO_UMANAGED_ROOT_LATE_NUM2 Child entity: DDLS DEMO_UMANAGED_CHILD_LATE_NUM2 Behavior definition The RAP behavior definition DEMO_UMANAGED_ROOT_LATE_NUM2 is defined in RAP BDL as follows: BDEF DEMO_UMANAGED_ROOT_LATE_NUM2 Behavior implementation For the above RAP behavior definition, one ABP is created. The global class of the behavior pool is BP_DEMO_UMANAGED_ROOT_LATE_NU2. The actual behavior implementation takes place in local classes that are defined and implemented in the BP_DEMO_UMANAGED_ROOT_LATE_NU2CCIMP of the behavior pool. ABAP_NOTE The ABP purposely includes only few handler method implementations since the focus is on the saver methods. The class lsc_demo_umanaged_root_late_nu is the RAP saver class that includes the following RAP saver methods: MethodDetails finalize Triggers any final calculations involving all BOs in the current LUW before the data gets saved to the database. In this example, the method is implemented in a way to do a calculation on a data field. field3 should be divided by 2. Since the field is of type i, a division by 2 with uneven numbers results in an error. In case of an error, the FAILED and reported parameters get filled. If the division is successful, field3 receives the result and a success message is included in the reported parameter for the particular instance. A log table ( DEMO_TAB_LOG_LN) is then filled with content of the failed (if available) and reported structures. The purpose of this log table is to show the returned messages of the finalize, check_before_save and save methods in the output. check_before_save Contains a consistency check. An instance should only get saved if the value of data field field4 does not exceed 100. Furthermore, the failed and reported parameters as well as the log table DEMO_TAB_LOG_LN are filled. adjust_numbersAssigns the final primary keys of the RAP BO instances. In the given example, a random integer gets assigned. Once the method is called, a point of no return has been reached. The method must ensure that there are no issues with the key assignment. Therefore, a check is implemented to guarantee a random number does not yet exist for instances, neither in the transactional buffer nor in the database table. Furthermore, the failed and reported parameters as well as the log table DEMO_TAB_LOG_LN are filled. save Saves the data from the transactional buffer to the database. The method is only called if the finalize, check_before_save and adjust_numbers methods have been processed successfully. Once the data has been saved, a success message is included in the reported parameter and the log table DEMO_TAB_LOG_LN. cleanup Clears the transactional buffer. The method is called if the save method has been processed. cleanup_finalize Clears the transactional buffer. The method is called if issues arise in the finalize and check_before_save methods.
ABAP_DESCRIPTION Access with ABAP using EML The above source code uses EML to access the RAP business object from an ABAP class. The example demonstrates three different ABAP_EML MODIFY requests. Each of the MODIFY requests includes CREATE operations to create three instances. COMMIT ENTITIES statements trigger the save sequence. First MODIFY request: The finalize method is not fully processed successfully which prevents the data from being saved. Second MODIFY request: The finalize method is processed successfully while the check_before_save method is not. The data is not saved. Third MODIFY request: Both finalize and check_before_save methods are fully processed successfully. As a consequence, the adjust_numbers and save methods are called and the data is saved to the database table. The output shows three sections for each MODIFY request:
A log table including the saver methods that have been called.
A log table including information that has been returned for FAILED and REPORTED. In all cases, the preliminary ID %pid for the instances is included. In case of the final request, the newly assigned keys are included, too.
A table including the database table entries after the CREATE operations. However, the first two MODIFY do not show the table since the CREATE operations cannot be processed successfully on purpose.
