Get Example source ABAP code based on a different SAP table
Ensuring Data Consistency in a RAP Transaction The LUW concept, which deals with the transfer of data from one consistent state to another, applies to applications using RAP. RAP transactions are integrated with the SAP LUW, which is a prerequisite for transactional consistency. RAP provides a standardized approach and rules ( RAP BO contract) for the RAP business object (BO) runtime to ensure that the RAP transaction is correctly implemented, data inconsistencies are avoided, and the SAP LUW is successfully completed. ITOC
Phases of a RAP Transaction A RAP transaction is divided into two phases during the runtime of a RAP BO, while the second phase can be divided into two subphases that serve different purposes. IMAGE RAP_LUW.png 562 842 RAP interaction phase:
RAP handler methods are called in a RAP handler class that inherits from CL_ABAP_BEHAVIOR_HANDLER.
New data, i.e. RAP BO instances, are created in the RAP transactional buffer, or persisted data is retrieved and inserted into the transactional buffer for further processing.
The state of the data may become inconsistent in the transactional buffer during this phase. However, the data remains consistent in the database because changes are made only in the transactional buffer. RAP save sequence:
The RAP save sequence is triggered by a COMMIT ENTITIES statement. In natively supported RAP scenarios, such as an SAP Fiori application using OData, the COMMIT ENTITIES call is implicitly and automatically performed by the RAP runtime engine.
RAP saver methods are called in the RAP saver class, which inherits from the base class CL_ABAP_BEHAVIOR_SAVER .
The RAP save sequence is divided into the RAP early save phase and the RAP late save phase
The RAP early save phase ensures that the RAP BO instances in the transactional buffer - all RAP BOs in the current RAP transaction are involved - are in a consistent state so that they can be saved to the database.
In the RAP late save phase, data is finally saved from the transactional buffer to the database (Optional:) Saver methods called in the RAP early save phase: finalize: For final calculations and data changes before saving. In managed scenarios, determinations specified with ON SAVE are called when reaching this method. check_before_save: For data consistency checks in the transactional buffer. In managed scenarios, validations specified with ON SAVE are called when this method is reached. cleanup_finalize: If there are failures in at least one of the previous saver methods, further processing with the RAP late save phase is rejected and the transaction returns to the interaction phase. Before that, this saver method is called, allowing changes made in the finalize method to be rolled back. If there are errors in the early save phase, sy-subrc returns the value 4 after COMMIT ENTITIES statements. If the data in the transactional buffer is consistent after the early save phase, the late save phase is processed, which also means that a point of no return has been reached. Unlike the early save phase, you cannot return to the interaction phase when you reach the late save phase. Either the RAP transaction ends with a successful commit, or the changes are rolled back and a runtime error occurs. Saver methods called in the RAP late save phase: adjust_numbers: Provides RAP BO instances with their final numbers. This method is available only in late numbering scenarios. save (or save_modified in managed scenarios with an unmanaged or additional save): Used to save data from the transactional buffer to the database. If there are no issues, the final database commit is triggered and an implicit COMMIT WORK is executed. cleanup: Clears the transactional buffer. It completes the save sequence.
Commit and Rollback in a RAP Transaction The default ABAP statements for RAP are COMMIT ENTITIES (triggers the RAP save sequence and the final database commit; as mentioned above , in natively supported RAP scenarios, the commit is performed implicitly and automatically by the RAP runtime engine) and ROLLBACK ENTITIES (rolls back all changes of the current RAP transaction, i.e. the transactional buffer is cleared by calling the cleanup method). Both are RAP-specific and end the RAP transaction. Notes on COMMIT ... and ROLLBACK ... statements due to the integration of RAP transactions into the SAP LUW:
COMMIT ENTITIES implicitly triggers COMMIT WORK.
Using COMMIT WORK in RAP (instead of COMMIT ENTITIES ) also triggers the RAP save sequence. If there are no errors in the RAP save sequence, the final database commit is successful. Only in this best-case scenario does COMMIT WORK have the same effect as COMMIT ENTITIES. However, if there are errors in the save sequence, a runtime error occurs in any case, while a return to the interaction phase is still possible when using COMMIT ENTITIES .
COMMIT ENTITIES provides RAP-specific functionality with various additions that are not possible with COMMIT WORK, such as retrieval of RAP responses, key conversion in late numbering scenarios, and checking a RAP transaction in a simulation mode.
There are short, long, and dynamic forms of COMMIT ENTITIES statements.
COMMIT ENTITIES statements implicitly enforce local updates with COMMIT WORK, or COMMIT WORK AND WAIT if the local update fails. Therefore, the update is either a local update or a synchronous update, but never an asynchronous update. When COMMIT WORK is used, the RAP BO consumer can choose between synchronous and asynchronous update for RAP BO entities .
ROLLBACK ENTITIES implicitly triggers ROLLBACK WORK. Both have the same effect when used in RAP. Therefore, they are interchangeable. BEGIN_SECTION VERSION 5 OUT
Special Case: Failures in the Late Save Phase
In exceptional cases, for example, when BAPIs are called to save RAP BO instances in the late save phase, it may happen that the basic rule that failures must not occur in the RAP late save phase and be detected in the RAP early save phase is violated.
In such cases, the base class CL_ABAP_BEHAVIOR_SAVER_FAILED can be used for the RAP saver class.
RAP BO consumers can be informed by filling the RAP response parameters (some of which are not available when using CL_ABAP_BEHAVIOR_SAVER as the base class) in the saver method implementation so that they can react accordingly.
After a COMMIT ENTITIES statement and a failure in the late save phase, sy-subrc is set to 8.
A subsequent RAP operation may result in a runtime error. If the RAP BO consumer is to continue after an error in the late phase of the RAP save sequence, an explicit ROLLBACK ENTITIES is required. END_SECTION VERSION 5 OUT
Allowed/Forbidden Operations in a Behavior Implementation in a RAPTransaction The following restrictions apply to operations and/or statements in the individual phases of a RAP transaction in ABAP behavior implementations . Note that, depending on the strict mode setting in the BDEF, runtime errors may occur due to the use of forbidden statements, or static code checks may be applied. X means it is allowed. Operations/StatementsInteraction phaseEarly save phase Late save phaseNotes BEGIN_SECTION VERSION 5 OUT Database commits using secondary connectionsXX XSecondary connections are allowed for infrastructure purposes, for example. They can be used to store data that is not part of the main transaction, such as application logs, traces, or number ranges. Database commits using the standard connectionXX- Database commits can be made in phases other than the late phase, for example, by calling external services or using a WAIT statement. sRFC (CALL FUNCTION ... DESTINATION), aRFC (CALL FUNCTION ... STARTING NEW TASK )XX- Allowed in phases other than the late save phase, e.g. for the purpose of parallelization within the application. It is up to the application to ensure consistency, e.g. to ensure read-only access, to handle a potential two-phase commit, or to provide a proper error handling. END_SECTION VERSION 5 OUT Database modifications--X Only allowed in the late save phase because the data being processed is always potentially inconsistent. Database changes in other phases would result in multiple database transactions instead of one transaction, which would disrupt the SAP LUW. BEGIN_SECTION VERSION 5 OUT Update function module lbr lbr CALL FUNCTION ... IN UPDATE TASK -- XCan be used to ensure that there is only one database transaction. In addition, registering function modules for update tasks at stages other than the late save phase would interfere with RAP draft scenarios, for example, where data is stored in draft tables. There is no way to unregister function modules once they have been registered. bgRFC lbr lbr CALL FUNCTION ... IN BACKGROUND UNIT--X tRFC, qRFC lbr lbr CALL FUNCTION ... IN BACKGROUND TASK---Obsolete technologies. PERFORM ON COMMIT, PERFORM ON ROLLBACK(X)(X)X Basically possible in all phases, but should be reserved for the late save. lbr lbr ABAP_NOTE The use of these statements indicates improper integration with RAP. It is especially important to check draft scenarios when calling legacy code and using these statements. Instead, ABAP_EML or procedure calls that do not include a COMMIT WORK should be used. END_SECTION VERSION 5 OUT Transaction control lbr lbr COMMIT WORK, ROLLBACK WORK --- Not allowed in ABAP behavior implementations. The use of these statements is always up to the RAP BO consumer, i.e. outside the ABAP behavior implementation. BEGIN_SECTION VERSION 5 OUT Dynpro processing lbr lbr For example, SET SCREEN, CALL SCREEN, LEAVE SCREEN, CALL DIALOG, SUPPRESS DIALOG, MESSAGE without INTO, WRITE , STOP--- Not allowed in ABAP behavior implementations. Results in a runtime error. Transaction processing lbr lbr CALL TRANSACTION, LEAVE TRANSACTION --- Not allowed, so that the (unwanted) integration of other LUWs is prevented. END_SECTION VERSION 5 OUT Raising an exception using RAISE EXCEPTION---It is not allowed to leave a RAP transaction this way. BEGIN_SECTION VERSION 5 OUT Report processing using SUBMIT ...---Not allowed in ABAP behavior implementations. Results in a runtime error. lbr lbr SUBMIT ... AND RETURN does not currently return an error, but it leads to potentially unwanted screen processing, and because of the missing return channel, there is no proper error handling. END_SECTION VERSION 5 OUT BEGIN_SECTION SAP_INTERNAL_HINT SYSTEM-CALL is not allowed in ABAP behavior implementations. END_SECTION SAP_INTERNAL_HINT
ABAP_FURTHER_INFO
An integral part of RAP transactions is database locking. Each RAP BO instance that is processed during a RAP transaction must be locked to avoid conflicts. See more information in the Development Guide for the ABAP RESTful Application Programming Model, section Pessimistic Concurrency Control (Locking).
RAP Save Sequence in the Development Guide for the ABAP RESTful Application Programming Model.
For general information about data consistency and the SAP LUW, see here.
ABAP_EXAMPLE_ABEXA The example Phases in RAP Transactions demonstrates the RAP interaction phase and the RAP early and late save phase using an unmanaged RAP business object with late numbering . ABAP_EXAMPLE_END
