Development with the ABAP RESTful Application Programming Model
The ABAP RESTful Application Programming Model (RAP) provides developers with a powerful environment for creating efficient, SAP HANA-optimized OData services. In this blog post we will take a closer look at the various development options and scenarios with RAP.
Managed scenario
In the so-called managed scenariocompletely new business objects (greenfield) can be developed. The RAP framework takes over the procurement and management of the business object’s data from the database tables. This includes standard CRUD (Create, Read, Update, Delete) operations. Developers don’t need to worry about implementing these basic features because the framework already provides them. Another advantage of the managed scenario is that the framework also takes care of locking the objects to be changed. This greatly simplifies the development process and allows developers to focus on business-specific logic.
Unmanaged scenario
In contrast to this is the unmanaged scenario (brownfield), which can be used to connect existing business objects. In this case, data handling for the business object must be ensured using your own coding. However, this procedure makes it possible to use existing legacy coding (e.g. SAP BAPIs) to access the business objects. The unmanaged scenario is particularly useful when companies want to integrate their existing systems and applications into the new RAP environment. Instead of developing everything from scratch, developers can leverage their existing resources and skills and seamlessly integrate them into the RAP model.
More functions
In addition to the managed and unmanaged scenarios, the ABAP RESTful Application Programming Model offers other powerful functions: Draft handling: This function can be activated for the managed scenario and enables the temporary storage of created or changed objects. This is particularly useful for Fiori apps, as object changes are not lost when the app is aborted and it is possible to change the device while editing. ABAP Environment Enhancements: The RAP model extends the ABAP environment with new keywords, annotations, and an Entity Manipulation Language (EML) for accessing business object data. Developers can customize the behavior of business objects through Behavior Definitions and Implementations. With these powerful features, the ABAP RESTful Application Programming Model provides developers with a modern and efficient environment for building scalable, cloud-ready applications. Whether you want to develop new business objects or integrate existing systems, RAP offers the right tools for your needs.
How does the ABAP RESTful Application Programming Model differ from the previous ABAP Programming Model for SAP Fiori?
The ABAP RESTful Application Programming Model (RAP) completely replaces the older ABAP Programming Model for SAP Fiori. In contrast to the old model, the RAP model no longer uses some frameworks such as the Business Object Processing Framework (BOPF) directly. Instead, OData services are generated automatically and can no longer be managed manually via transaction SEGW. RAP also offers new concepts such as the managed/unmanaged scenario, draft handling and extensions to the ABAP environment with new keywords, annotations and the Entity Manipulation Language (EML).
What will development with the ABAP RESTful Application Programming Model look like compared to before?
Development with RAP is mainly done using the ABAP Development Tools (ADT) in Eclipse. The classic Development Workbench (SE80) can only be used to edit individual sub-objects such as classes or database tables. The core concepts such as CDS Views, Behavior Definitions, Service Definitions and Service Bindings are all created and edited in ADT. Overall, development should become more efficient and standardized through integration in a development environment and the new language extensions.
What advantages does draft handling offer in the ABAP RESTful Application Programming Model?
Draft handling allows newly created or changed objects to be temporarily stored in separate draft tables. This has several advantages: First, changes to the object are not lost if the application is aborted. Secondly, the user can switch devices while editing without losing data. Thirdly, a different locking concept is used with exclusive locks via the lock server that are not tied to the dialog session. This increases flexibility and stability when editing objects.