Ansicht
Dokumentation

ABENRAP_ADDITIONAL_SAVE_ABEXA - RAP ADDITIONAL SAVE ABEXA

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

- TYPE REQUEST FOR in a Managed RAP BO with Additional Save

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:

Behavior definition

The CDS behavior definition DEMO_MANAGED_ADDITIONAL_SAVE is defined in CDS BDL as follows:

Behavior implementation

For the above CDS 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 is handling the deleted instances does not take the fields changed_field_name and changed_value into consideration. They are not relevant.

Source Code

Execute

Description

Access with ABAP using EML

The above source code uses EML to access the RAP business object from an ABAP program:

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

TXBHW - Original Tax Base Amount in Local Currency   Addresses (Business Address Services)  
This documentation is copyright by SAP AG.

Length: 7818 Date: 20240426 Time: 160958     sap01-206 ( 130 ms )