SAP RAP ADDITIONAL SAVE ABEXA



Get Example source ABAP code based on a different SAP table
  



ABAP_EML - TYPE REQUEST FOR in a Managed RAP BO with AdditionalSave
This example demonstrates the use of the BDEF-derived types TYPE REQUEST FOR CHANGE and TYPE REQUEST FOR DELETE in the context of a managed RAP BO whose BDEF is specified with with additional save.
In this simplified example, all changes to the root instance of the demo BO are recorded (i. e. they are additionally saved) in the log table DEMO_TAB_LOG. This log table contains the following fields: Log table fieldDetails
change_idIdentifier for an individual change. In this case, it is a UUID.
key_fieldKey field of the RAP BO instance.
changing_operation Standard operation that has been carried out ( CREATE, UPDATE or DELETE).
changed_field_name Name of the RAP BO instance's field that has been created or changed.
changed_value Value of a created or changed field of the RAP BO instance.
created_at Date and time of the instance data creation, update or deletion.
Data model
The CDS data model consists of the root entity DEMO_MANAGED_ADDITIONAL_SAVE.
Root entity:
DDLS DEMO_MANAGED_ADDITIONAL_SAVE
Behavior definition
The RAP behavior definition DEMO_MANAGED_ADDITIONAL_SAVE is defined in RAP BDL as follows:
BDEF DEMO_MANAGED_ADDITIONAL_SAVE
Behavior implementation
For the above RAP behavior definition, one ABP is created. The global class of the behavior pool is BP_DEMO_MANAGED_ADDITIONAL_SAV. The actual behavior implementation takes place in local classes that are defined and implemented in the BP_DEMO_MANAGED_ADDITIONAL_SAVCCIMP of the behavior pool.
The following method is relevant in this example:
save_modified At first, several type and variable declarations are available just for demonstration purposes. Among them, there are the BDEF-derived types TYPE REQUEST FOR CHANGE, TYPE REQUEST FOR DELETE, TYPE TABLE FOR CHANGE and TYPE STRUCTURE FOR CHANGE. These BDEF-derived types are only relevant in the context of a managed RAP BO with additional save and unmanaged save. Basically, the structures create and update (that are of type TYPE REQUEST FOR CHANGE) as well as delete (that is of type TYPE REQUEST FOR DELETE) - they contain those instances that are to be created, changed or deleted - are available here by default and can be referred to directly instead of extra variable and type declarations as it is the case in this example. The declarations are followed by further declarations of internal tables that store the input for the log table in the database. IF statements then check whether instances have been created, updated or deleted by a RAP BO consumer In doing so, the %control structure is used to get information on which fields have been set when creating, updating or deleting the instance. The IF statement processing those instances that have been created is implemented as follows: The internal table lt_log is filled with the instance data created by the CREATE operation. A LOOP statement processes the individual instances: The changing_operation receives the value CREATE. The creation time is logged ( created_at field). Then the instance data is read into an internal table to handle the %control information for certain fields. In this case, it is checked if field1 is marked as enabled. If so, a UUID is created and assigned to the change_id field. Since field1 is affected, the field changed_field_name gets the value field1. The field changed_value receives the value that is provided by the RAP BO consumer. Finally, the entries are added to the internal table lt_log_c. The same procedure is done for field2. At the end of the IF statement, all the entries in the internal table are inserted in the log table on the database (demo_tab_log). The IF statement processing those instances that have been updated are implemented similarly to above (here, field3 and field4 of the entity are used). The IF statement that handles the deleted instances ignores the fields changed_field_name and changed_value. They are not relevant.

ABAP_SOURCE_CODE
DEMO CL_DEMO_RAP_MANAGED_ADD_SAVE

ABAP_DESCRIPTION
Access with ABAP using EML
The above source code uses EML to access the RAP business object from an ABAP class:
An ABAP_EML CREATE operation is carried out. Two instances are created. The save sequence is triggered by the COMMIT ENTITIES statement. The underlying BDEF includes the syntax with unmanaged save. Thus, the ABP method save_modified is called in this example that saves certain entries to a log table in the database as described above.
The CREATE operation is followed by an UPDATE operation that modifies the two previously created instances. The changes get committed as well.
Finally, one of the existing instances is deleted via a DELETE operation. Another commit takes deletes the instance.
The output window shows the result of all three operations. For each operation, an internal table is displayed showing the entries of the database table. Another internal table shows the entries of the log table as a result of the implementations in the save_modified method.