Get Example source ABAP code based on a different SAP table
ABAP_EML - COMMIT ENTITIES BEGIN, END with CONVERTKEY OF This example demonstrates the COMMIT ENTITIES variant COMMIT ENTITIES ... END including CONVERT KEY OF with a simple unmanaged RAP BO. Data model The CDS data model consists of the root entity DEMO_UMANAGED_ROOT_LATE_NUM. Root entity: DDLS DEMO_UMANAGED_ROOT_LATE_NUM Behavior definition The RAP behavior definition DEMO_UMANAGED_ROOT_LATE_NUM is defined in RAP BDL as follows: BDEF DEMO_UMANAGED_ROOT_LATE_NUM 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_NUM. The actual behavior implementation takes place in local classes that are defined and implemented in the BP_DEMO_UMANAGED_ROOT_LATE_NUMCCIMP of the behavior pool:
lcl_buffer constitutes the transactional buffer. It includes an internal table to handle the data.
lhc_demo_unmanaged_root_late_nu is the handler class of the behavior pool. The only relevant methods in this example are create and update.
lsc_demo_unmanaged_root_late_nu is the saver class of the behavior pool. The methods of this class implement the actual modification of the persistent data. Details of the ABP
lcl_buffer In this local class, an internal table is constructed that serves as transactional buffer. root_late_num_buffer is the transactional buffer for the root entity. The underlying structured data type is built in a way that simplifies the handling of the buffer. gty_late_num_buffer, as the structured data type for root_buffer , contains all the key and data fields of the root entity's underlying CDS view with the same type. Plus, the structure includes the components cid and pid to hold the content and preliminary ID. The preliminary ID is necessary for late numbering. Plus, for a more comfortable processing of saving and deleting instances, it includes two fields ( changed and deleted) acting as flags (while deleting is not relevant in this example). These flags are set in the course of modify operations, i. e. if an instance is created or changed, the changed field is given an X.
Method create Note that the method implementation is intentionally kept simple. For example, a filling of the REPORTED parameter or checking if an instance already exists are not included so as not to overload the code. The method only covers the creation of %pid and the filling of the transactional buffer as well as the MAPPED response parameter. A LOOP statement is responsible for processing the transactional buffer with the individual instances that come in as input parameters ( entities). In this case, the following steps are implemented: At first, a preliminary ID (%pid) is created for the instance that is processed. Here, it is a UUID. The transactional buffer is then filled with all the provided input including %cid, the new %pid, the data fields and a flag in the changed field so that the instance can be created. The keys do actually not play a role here since the final keys are not drawn until the save phase. Finally, the MAPPED response structure is filled with %cid and the new %pid. At this stage, the MAPPED response structure is of type MAPPED EARLY.
Method update Note that the method implementation is intentionally kept simple. For example, a filling of the FAILED and REPORTED parameters or checking whether an instance exists are not included so as not to overload the code. The method only covers the update of fields if they are provided. This is done within a LOOP statement that processes the transactional buffer with the individual instances that come in as input parameters ( entities). The implementation is done in a way that the instances to be updated are identified by the preliminary ID %pid. Only data fields, not the keys, are relevant. A flag is set for the changed field so that the instance can be updated.
Class lsc_demo_unmanaged_root The finalize method deletes all the content IDs from the transactional buffer since they must not be used during the save phase. The adjust_numbers method assigns the real and final key value to the instance. The lines of the transactional buffer table are processed using a LOOP statement. In this oversimplified example, the key field is given a (dummy) value and the MAPPED response structure is filled. Here, the structure is typed with MAPPED LATE. The save method includes statements that are responsible for saving the instances from the transactional buffer, i. e. from the internal table root_late_num_buffer, to the database table ( demo_tab_root_3). Here, an internal helper table is created to store those instances that have a flag for the changed field. This helper table is then used for an AB_SQL MODIFY statement that finally changes the database tables with only those instances a change is intended for. The cleanup method clears the buffer table.
ABAP_SOURCE_CODE DEMO CL_DEMO_RAP_EML_COMMIT_3
ABAP_DESCRIPTION Access with ABAP using EML The above source code uses EML to access the unmanaged RAP business object from an ABAP class. An ABAP_EML MODIFY statement that includes a CREATE operation for creating new RAP BO instances is followed by an UPDATE operation updating these new created instances. The MODIFY statement with CREATE also includes the filling of the MAPPED response parameter ( mapped_early). When the create method is called, this parameter is given the provided %cid and also %pid, which is created by the method. This information is used to identify the instances for the UPDATE operation. The save sequence is initiated by COMMIT ENTITIES BEGIN and ends with COMMIT ENTITIES END. A CONVERT KEY OF statement is available, which is not necessary in this non-business related example. Yet, for showcasing purposes, the assumption is that getting the keys is indeed of interest here. Hence, the final keys that are drawn in the adjust_numbers method are retrieved. Since the preliminary IDs ( %pid) are available until the RAP transaction is terminated, the conversion of the keys can be done on those %pid components. In the example, a LOOP statement processes the lines of the MAPPED table for the RAP BO entity. The CONVERT KEY statement is given the final keys of the individual instances based on the preliminary ID identifying these instances. The individual key is written to a local variable. For demonstration purposes, %pid and the key values are then stored in an internal table. The output window shows the result of the CONVERT KEY OF statement, i. e. a table that includes %pid and the corresponding key values, and the instances, that are successfully saved to the database, as a result of the ABAP_EML MODIFY operations.
