Kontakt

Ansicht
Dokumentation

ABENEML_MODIFY_OP_U_ABEXA - EML MODIFY OP U ABEXA

ABENEML_MODIFY_OP_U_ABEXA - EML MODIFY OP U ABEXA

ABAP Short Reference   General Material Data  
This documentation is copyright by SAP AG.
SAP E-Book

- MODIFY, Standard Operations (Unmanaged)

This example demonstrates all standard operations to modify and read from a simple unmanaged RAP BO. The following operations are covered:

  • CREATE
  • CREATE BY (create-by-association operation)
  • UPDATE
  • DELETE
  • READ
  • READ BY (read-by-association operation)

In an unmanaged RAP scenario - as opposed to managed RAP scenarios - the developer is responsible for the implementation of the standard operations. This simplified example is not a real life scenario and rather focuses on the technical side by showing how the methods of an ABAP behavior pool (ABP) might be self-implemented taking the handling of the transactional buffer in a managed scenario as a role model in a simplified way. This implementation can, for example, be called using ABAP EML outside of the behavior pool.

The transactional buffer of the unmanaged RAP BO in the example is constituted by internal tables for the sake of having a self-contained example reducing the complexity. The tables act as a memory area into which data from the persistent database tables are read and from which data is saved back to the database tables after triggering the saving of modified instances (with a COMMIT ENTITIES statement).

Note

The code is meant to give an idea about the principles of an unmanaged RAP scenario, the fact that everything must be self-implemented and the significance of the transactional buffer that can be accessed by ABAP EML, and should therefore not be reused in a production scenario.

Data model

The CDS data model consists of the root entity DEMO_UNMANAGED_ROOT_2 and its child entity DEMO_UNMANAGED_CHILD_2.

Root entity:

Child entity:

Behavior definition

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

The behavior definition is the basis of the implementation. It defines what can be implemented in the behavior pool.

Behavior implementation

For the above CDS behavior definition, one ABP is created. The global class of the behavior pool is BP_DEMO_UNMANAGED_ROOT_2. The actual behavior implementation takes place in local classes that are defined and implemented in the BP_DEMO_UNMANAGED_ROOT_2======CCIMP of the behavior pool:

  • lcl_buffer constitutes the transactional buffer. It includes internal tables to handle the data.
  • lhc_demo_unmanaged_root_2 is the handler class of the behavior pool. The methods of this class implement all standard operations including an error handling.
  • lsc_demo_unmanaged_root_2 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, two internal tables are constructed that serve as transactional buffer: root_buffer as the transactional buffer for the root entity, and child_buffer for the child entity to also cover the create- and read-by-association operations. The underlying structured data types are built in a way that simplifies the handling of the buffers. gty_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 to hold the content ID that might be provided by an instance and, for a more comfortable processing of saving and deleting instances, it includes two fields (changed and deleted) acting as flags. These flags are set in the course of modify operations, i. e. if an instance is created or changed, the changed receives an X. If an instance gets deleted, deleted gets the flag X. If no operation takes place for an entity, both fields remain initial. Likewise, the structured data type for the child entity (gty_buffer_child) is constructed. It also contains all the key and data fields of the child entity's underlying CDS view with the same type (which is in this example very similar to the root entity). This structure contains the components cid_ref for by-association operations and cid_target for the content ID of child instances in the %target structure. The latter is not used in the example. Furthermore, the component created is included. Its purpose is the same as changed, however, in this case, it is only relevant to cover create-by-association operations. Only those instances whose created field is marked with an X should be saved to the database table of the child entity.
  • Methods prep_root_buffer and prep_child_buffer
These two methods are meant to prepare the transactional buffers for the root and child entity and fill them with data from the underlying database table, especially if the buffer tables are cleared once the save sequence gets triggered by a COMMIT ENTITIES statement in the ABAP program.
The principle of internal tables as transactional buffer is the following: Once an EML call requests data (to be read or modified) with a specific key, it is checked whether the transactional buffer already holds the requested data, otherwise it is checked if the data is available in the persistent database table. If it exists there, the line with the specified key is read from the database table into the transactional buffer using a SELECT statement. The following is done in the individual methods for the operations to avoid double entries: If the data does not exist at all (for example, it got deleted), the FAILED and REPORTED structures should be filled with information about which data sets could not be read or modified. The prep_child_buffer method is relevant for the by-association operations. Not only must the availability of the line with the specified key in the root buffer be checked but also the availability of the line in the child buffer. If the line exists in the underlying database table of the child entity, the data gets read into the child buffer using a SELECT statement as well.
  • Method create
After preparing the root buffer with the provided input parameters (entities), a LOOP AT statement further processes the transactional buffer with the individual instances that come in as input parameters. There are certain conditions to be met before an instance can actually be created. If the conditions are not met for a particular instance, the result is an entry in the FAILED and REPORTED structures for the failed instance. The gist is that those instances being present in the transactional buffer and meeting the conditions receive a flag in the changed field and can finally be created. Consequently, the instances are saved to the database table following a COMMIT ENTITIES statement in the ABAP program triggering the save sequence. The checks also take the significance of the flags in the %control structure into consideration, i. e. if a data field is unmarked using the constant mk-off of interface ABP_BEHV_FLAG, this particular field should not be created with the provided value.
  • Method update
Same as the method above, after preparing the root buffer with the provided input parameters (entities), a LOOP AT statement further processes the transactional buffer with the individual instances that come in as input parameters. Also here, there are certain conditions to be met before an instance can be updated. If the conditions are not met for a particular instance, an entry gets created in the FAILED and REPORTED structures for the failed instance. The checks are implemented in the way that existing values of a data field should not be overwritten if it is explicitly unmarked in the %control structure. Same as above, a changed instance receives a flag. Furthermore, the IF statements are implemented for two scenarios. It might so happen that an EML request includes only the keys or only %cid_ref. In the latter case, a potentially provided key is ignored since the reference to a particular %cid is the principal reference.
  • Method delete
This method is implemented similarly to the update method, for example, it considers the two scenarios when only key or only %cid_ref are provided. If an instance is to be deleted, it receives a flag for the deleted field. The changed field gets initialized. %control is not applicable here.
  • Method read
After preparing the root buffer with the provided input parameters (keys), a LOOP AT statement is used for a detailed preparation and filling of the read result table according to the keys that come in as input parameters and considering the flags for the fields in the %control structure. If a data field is unmarked, this particular field should not be read and included in the read result. The key must always be read and returned.
  • Method rba_child
As an initial step in the method for read-by association operations, both root and child buffers must be prepared. Same as in the read method, the LOOP AT statement is used for a detailed preparation and filling of the read result table according to the keys that come in as input parameters and considering the flags for the fields in the %control structure. If a data field is unmarked, this particular field should not be read and included in the read result. The key must always be read and returned.
  • Method cba_child
As an initial step in the method for create-by association operations, both root and child buffers must be prepared. The conditions for filling the child buffer within the LOOP AT statement include checks for two scenarios. It might so happen that an EML request includes only the keys or only %cid_ref. In the latter case, a potentially provided key is ignored since the reference to a particular %cid is the principal reference. The flags in the %control structure for the data fields are considered, too. If the conditions are met for an instance to be created in the child entity, the instance receives a flag for the created field.
  • Class lsc_demo_unmanaged_root
The finalize method takes deletes all the content IDs from the transactional buffer since they must not be used during the save phase. However, it is not relevant for the example.
The save method includes statements that save the instances from the transactional buffer, i. e. from the internal tables root_buffer and child_buffer, to the database tables (demo_tab_root_3 and demo_tab_child_3). Among the statements, there is one code block dealing with create and update operations. 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 MODIFY statement that finally changes the database tables with only those instances a change is intended for. Another block is there for the deletion. Similarly, an internal helper table comprises those instances having a flag for deleted. The saving of instances via create-by-association operations is handled separately in the example since the instances from the child buffer must be considered (those instances with a flag for created) and not the ones from the root buffer as it is the case in the two preceding code blocks.
The cleanup method clears the buffer tables.

Source Code

Execute

Description

Access with ABAP using EML

The above source code uses EML to access the unmanaged RAP business object from an ABAP program. The main focus of the program is to demonstrate simple EML calls that access the transactional buffer and modify RAP BO instances of root and child entity or read and return them respectively. All standard operations are covered: CREATE, CREATE BY, UPDATE, DELETE, READ and READ BY. Using COMMIT ENTITIES statements, the saving of the changed instances is triggered. To demonstrate the successful saving of the particular instances, an internal table is displayed which is filled with the current data sets contained in the persistent database table (using a SELECT statement). Furthermore, the modify and read operations include the FAILED and REPORTED structures. The example covers cases where instances cannot be changed or read on purpose. To display the responses of failed instances in the output window, the display_responses method comprises the construction and filling of internal tables to hold the returned information for failed instances. The information displayed for the failed instances is based on the individual ABP method calls that are responsible for filling the response structures. The information provided is intentionally kept simple and limited.

The FAILED tables that are displayed comprise the fail cause (there is no particular logic implemented to diversify the fail cause), content ID and key of the affected instance as well as the affected operation or association (which is indicated by the entry 01). The REPORTED tables that are displayed comprise information about the severity of the incident, content ID and key as well as a custom message.

  • Some fields are intentionally not filled to emphasize the significance of the %control structure, i. e. if a field is unmarked, it is not considered for the operation. That is why the keyword FROM is used following the keyword for the operation throughout the example since %control must be filled explicitly in that case.
  • The modify operations focusing on UPDATE and DELETE include additional CREATE operations for instances holding a content ID. In doing so, the UPDATE and DELETE operations can also demonstrate the use of %cid and %cid_ref.





BAL_S_LOG - Application Log: Log header data   General Material Data  
This documentation is copyright by SAP AG.

Length: 17182 Date: 20240418 Time: 060728     sap01-206 ( 323 ms )