Preface – This post is part of the SAP ABAP RAP series.

Introduction

In the previous article, we have learnt RAP runtime consists of two phases: Interaction phase and Save phase. Now we will understand what are the steps involved in these phases and how they are segregated.

INTERACTION phase can be segregated in Lock, Read, Modify methods whereas, the SAVE phase involves some predefined methods finalise(), check_before_save(), adjust_numbers(), save(), cleanup(), cleanup_finalise() which are called sequentially.

Business Object Runtime

SAP ABAP RAP supports three types of implementations UNMANAGED, MANAGED and MANAGED with save. Currently, only Unmanaged and managed scenarios are supported. Managed with save will come in future release.

Figure 1: Business object Runtime

Figure 2: Unmanaged, Managed and Managed with save

In the interaction phase, modify method consists of create, create_by_association, update, delete and action methods which are used to change the data in the database. The reads methods consist of read entities, read_by_association, and execute_functions. The read methods are used to retrieve data, they do not change the behaviour of data. The lock method is used for lock properties. Once the interaction phase is completed and changes are stored in the transactional buffer, the save phase comes into the picture.

The save phase consists of predefined methods that are executed sequentially.

• finalise() : The first method executed in save phase is finalise(). It finalises the final calculations with business objects determinations before the data is persisted on the database.

• check_before_save(): The next method executed after finalise is check_before_save(). Before saving the data to the database, the validations are called within this method. For successful save, the BO runtime must provide the feedbacks in checks. This is the point of no-return i.e. once the control reaches this method and there is no failure detected, the execution will go to the next step and data will be saved successfully in the database.

In case, there is failure detected in this method, the further execution will be terminated and the control will go to the cleanup_finalise() method. And the data will not be saved.

• adjust_numbers(): This method is required when we have modelled late numbering in our business object behaviour definition.

Late numbering: The final number or the key number is generated just before the instance of data is stored in the database. It is a concept to generate gap-free numbers. For example, if you are creating an Info record, the info record number is generated just before data is stored in the database. (Not supported for managed implementation).

Early numbering: In case we are using early numbering in a business object, the key number is generated beforehand i.e. after the modify method is called. The key values are available in the transactional buffer.

• save(): This method saves the data from the transactional buffer to the database.

• cleanup(): The cleanup method is called when the save() method is executed successfully. This clears the transactional buffer or variables to prevent form any inconsistencies.

• cleanup_finalise(): This method is called when finalise() and check_before_save() returned any failed key and the data is not persisted in the database. The cleanup_finalise() clears the transactional buffers or variables if execution fails in finalise or check_before_save.