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 field>Details> change_id>Identifier for an individual change. In this case, it is a UUID>. key_field>Key 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_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.