ABAP Keyword Documentation → ABAP − Reference → ABAP RESTful Programming Model → Behavior Implementations
Saver Class
Other versions:
7.31 | 7.40 | 7.54
Syntax
CLASS lcl_saver_name DEFINITION
INHERITING FROM cl_abap_behavior_saver
[ABSTRACT] [FINAL].
PROTECTED SECTION.
METHODS finalize REDEFINITION.
METHODS check_before_save REDEFINITION.
METHODS adjust_numbers REDEFINITION.
METHODS save REDEFINITION.
METHODS cleanup REDEFINITION.
ENDCLASS.
CLASS lcl_saver_name IMPLEMENTATION.
METHOD finalize.
...
ENDMETHOD.
METHOD check_before_save.
...
ENDMETHOD.
METHOD adjust_numbers.
...
ENDMETHOD.
METHOD save.
...
ENDMETHOD.
METHOD cleanup.
...
ENDMETHOD.
ENDCLASS.
Effect
Within the behavior pool, a local saver class is defined to implement the save phase of the business object behavior. The save phase consists of a sequence of calls used to synchronize the business objects in question. Only the final call in this sequence is the actual save method, in which changes can and must be written to the database.
The saver class lcl_saver is defined implicitly as ABSTRACT and FINAL and derived from the class CL_ABAP_BEHAVIOR_SAVER. There are no special rules for the name of the saver class.
The transactional methods finalize, check_before_save, adjust_numbers, save, and cleanup can be implemented in a saver class:
- finalize
Finalizes any changes to data before it can be saved to the database.
- check_before_save
Checks the consistency of the application buffer.
- adjust_numbers
Implements late numbering.
- save
Saves the data from the transactional buffer to the database.
- cleanup
Discards all data changes and cleans up the transactional buffer.
The methods that correspond to the saver protocol (finalize, check_before_save, adjust_numbers, save, and cleanup) are all defined already in the basis class CL_ABAP_BEHAVIOR_SAVER and do not have individual signatures. The derived concrete saver class must implement these methods using REDEFINITION. In the redefinition, the types of the parameters defined in the basis class (failed, mapped, and reported are replaced by concrete derived types. In the basis class, these parameters are defined generically as CHANGING parameters.
The implementation of the methods finalize, check_before_save, and cleanup is not mandatory. The only mandatory redefinition is the method save. If the behavior definition specifies late numbering, the method adjust_numbers must also be implemented. The structure mapped is filled here.
Unlike in the interaction phase, no instance phase is passed in the saver phase. The saver itself must know where the data is to which it needs to apply the method finalize (by cooperating with the handler or the underlying legacy functions), namely in the transactional buffer administered by the application.
The saver sequence finalize, check_before_save, adjust_numbers, save, and cleanup is called in this order for every business object, after at least one successful change is made in the current LUW using the business object provider. A successful saver sequence is as follows:
- The saver sequence starts with the method finalize, which finalizes the calculations and data changes before data can be saved to the database.
- If the method finalize does not report any errors, the follow-on method check_before_save is called.
- If the method check_before_save does not return an error, the point has been reached from which a successful save is guaranteed for all business objects in question. After this point, the method adjust_numbers is called to respect late numbering.
- Finally, the method save is called to save all data of the business object instance from the transactional buffer to the database.
- At the end, the method cleanup is called to delete the transaction buffer.
If the method finalize or check_before_save reports an error, the method cleanup is called to discard all changes made to the data in the current LUW and to clean up the transactional buffer.
The methods finalize and check_before_save can still fail, but this is not possible in the following methods. This means that, from the method adjust_numbers, the parameters failed and reported no longer exist.
Example
In the following example, the data from the ABAP flight data reference scenario (or flight data scenario for short) is used. It represents a legacy business logic that can be used to create and edit flight bookings. The root entity Travel represents the business object for managing flight trips. The underlying data model and the behavior of the root entity Travel are described in ABAP BDL - Example.
INHERITING FROM cl_abap_behavior_saver.
PROTECTED SECTION.
METHODS finalize REDEFINITION.
METHODS check_before_save REDEFINITION.
METHODS save REDEFINITION.
METHODS cleanup REDEFINITION.
ENDCLASS.
METHOD finalize.
...
ENDMETHOD.
METHOD check_before_save.
...
ENDMETHOD.
METHOD adjust_numbers.
...
ENDMETHOD.
METHOD save.
...
ENDMETHOD.
METHOD cleanup.
...
ENDMETHOD.
ENDCLASS.