RAP - Unmanaged Scenario
In this article we will go into the theory of the unmanaged approach and how it is implemented in the ABAP RESTful Programming Model.
Table of contents
In this article we will take a look at the theory of the unmanaged scenario and in the two following articles we will go into examples of how it can work with local APIs and in a remote approach. But first some theory on how the scenario works.
Introduction
Everything you have learned so far on our blog mainly describes the implementation in the managed approach. The RAP Framework takes over the entire work of data management. The provision of data, updating, deleting, number assignment, draft handling and saving is taken over by the framework and does not have to be developed. If you want to develop an object "Unmanaged", then you decide to develop everything yourself.
This is also very useful for certain processes, especially when it comes to migrating existing coding and functions. Everything that was already cleanly developed in ABAP after the MVC (Model View Control) can be largely reused and reused in an unmanaged RAP object, saving time and money.
Functionality
Let's take a look at the different steps before the data from the frontend even ends up in the database. There is an overview from SAP, which we will explain to you in detail here. RAP is a "stateless" application, every access to the backend takes place without an open session, the user is logged in, carries out his action, receives the result and the session is ended again in the backend. The browser takes over the communication, which always opens a session towards the backend when there are actions or data queries.
A distinction is made between two phases:
- Interaction phase - In this phase, the user operates the Fiori application, reads the data, filters them and starts to change them. These changes are kept in the transactional buffer, a kind of temporary storage in the SAP system. However, the changes are not yet in the database.
- Save sequence - The user clicks on the Save Button in the application, the save sequence is run through and the data from the transactional buffer is transferred to the database. Keys are assigned, the data checked and finally persisted.
Differences
In the managed RAP object, the RAP framework takes care of both phases and we as developers do not have to develop anything. This saves a lot of time, effort and source code. With the unmanaged approach, we take over everything that can be seen on the chart. We take care of the individual actions, the transactional buffer and the save sequence in order to finally persist the data in the database.
For the sake of completeness, however, it must be said that the Managed RAP object also has the option of implementing the save sequence itself, which is then called "Unmanaged Save". We would look at this methodology in a later article.
Example
So what are the differences in implementation? The creation of the model and the CDS views does not have to differ at first, the first major change occurs when the behavior definition is created:
The implementation type is set to unmanaged, the definition looks accordingly, on line 1 you can see the type of definition:
The corresponding behavior implementation is also created, but this is empty and must first be developed by us:
CLASS lhc_Unmanaged DEFINITION INHERITING FROM cl_abap_behavior_handler.
PRIVATE SECTION.
METHODS get_instance_authorizations FOR INSTANCE AUTHORIZATION
IMPORTING keys REQUEST requested_authorizations FOR Unmanaged RESULT result.
METHODS create FOR MODIFY
IMPORTING entities FOR CREATE Unmanaged.
METHODS update FOR MODIFY
IMPORTING entities FOR UPDATE Unmanaged.
METHODS delete FOR MODIFY
IMPORTING keys FOR DELETE Unmanaged.
METHODS read FOR READ
IMPORTING keys FOR READ Unmanaged RESULT result.
METHODS lock FOR LOCK
IMPORTING keys FOR LOCK Unmanaged.
ENDCLASS.
CLASS lhc_Unmanaged IMPLEMENTATION.
METHOD get_instance_authorizations.
ENDMETHOD.
METHOD create.
ENDMETHOD.
METHOD update.
ENDMETHOD.
METHOD delete.
ENDMETHOD.
METHOD read.
ENDMETHOD.
METHOD lock.
ENDMETHOD.
ENDCLASS.
CLASS lsc_ZBS_R_DMOUNMANAGED DEFINITION INHERITING FROM cl_abap_behavior_saver.
PROTECTED SECTION.
METHODS
finalize REDEFINITION.
METHODS
check_before_save REDEFINITION.
METHODS
save REDEFINITION.
METHODS
cleanup REDEFINITION.
METHODS
cleanup_finalize REDEFINITION.
ENDCLASS.
CLASS lsc_ZBS_R_DMOUNMANAGED IMPLEMENTATION.
METHOD finalize.
ENDMETHOD.
METHOD check_before_save.
ENDMETHOD.
METHOD save.
ENDMETHOD.
METHOD cleanup.
ENDMETHOD.
METHOD cleanup_finalize.
ENDMETHOD.
ENDCLASS.
Two local classes are implemented that inherit from corresponding standard classes:
- CL_ABAP_BEHAVIOR_HANDLER - Corresponds to the implementation for the interaction phase.
- CL_ABAP_BEHAVIOR_SAVER - Defines the implementation of the save sequence, the appropriate methods are available.
Conclusion
Based on today's theory, next week's implementation should be fairly easy for you. Ultimately, unmanaged means more implementation effort for you, but also more freedom in designing the object and building the API. Basically, the scenarios for brownfield (existing application) and remote scenarios are mapped.
