Ansicht
Dokumentation

ABENRAP_MANAGED_UNM_SAVE_ABEXA - RAP MANAGED UNM SAVE ABEXA

BAL Application Log Documentation   ABAP Short Reference  
This documentation is copyright by SAP AG.

- TYPE REQUEST FOR in a Managed RAP BO with Unmanaged 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 unmanaged save. The saving of created, changed or deleted RAP BO instances is self-implemented in the save_modified method of the ABP.

Data model

The CDS data model consists of the root entity DEMO_MANAGED_UNMANAGED_SAVE.

Root entity:

Behavior definition

The CDS behavior definition DEMO_MANAGED_UNMANAGED_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_UNMANAGED_SAVE. The actual behavior implementation takes place in local classes that are defined and implemented in the BP_DEMO_MANAGED_UNMANAGED_SAVECCIMP 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 contexts of a managed RAP BO with additional save and a managed RAP BO with unmanaged save. Basically, the structures create and update (that are of type TYPE REQUEST FOR CHANGE) as well as delete (that is of TYPE REQUEST FOR DELETE) - they contain those instances that are to be created, changed or deleted - are available here by default and can actually be referred to directly instead of extra variable and type declarations as it is the case in this example. The declarations are followed by a further declaration of an internal table (lt_tab) that acts as a helper table to temporarily store the instances that are to be created, changed or deleted.

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 for the created instances is implemented as follows: The internal table lt_tab is filled with the instance data created by the CREATE operation. A LOOP statement processes the individual instances. The data field values only get written to the internal table lt_tab if the data fields are not disabled for the operation in the %control structure. At the end of the IF statement, all the entries in the table lt_tab are saved to the database table demo_tab_root_3 using an MODIFY statement.

The IF statement processing those instances that have been updated is implemented similarly to above. However, to make sure that the update operation does not write blanks to the internal table lt_tab, an SELECT statement gets all existing entries of the database table demo_tab_root_3 at first. Hence, if a value for a particular data field is not provided or the field is marked as disabled in the %control structure, the already existing field value is taken over and not overwritten with an initial value.

The IF statement for the deleted instances deletes the entries from the database table using an DELETE statement.

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 the instances to the database table demo_tab_root_3 as described in section Behavior implementation.

• The CREATE operation is followed by an UPDATE operation that modifies the two previously created instances. The changes get committed as well. Some of the fields are disabled in the %control structure (using if_abap_behv=>mk-off). Hence, the existing field values are not changed.

• Finally, one of the existing instances is deleted via a DELETE operation. Another commit triggers the deletion of 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.

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   PERFORM Short Reference  
This documentation is copyright by SAP AG.

Length: 6651 Date: 20240419 Time: 225806     sap01-206 ( 98 ms )