Those who have been coding via the ABAP Editor and with ABAP prototype design patterns for years might have heard about the ABAP RESTful application programming model (sometimes named RAP). But what is it? Let’s take a look.
The three central pillars haven’t changed when programming with the ABAP RESTful application programming model: there’s still clear separation between the database layer, the business logic layer, and the UI layer. However, in each case how you go about programming has changed to a lesser or greater extent, so let’s talk about the changes to each layer in turn.
Changes to RAP Database Layer
The main change here is that you can no longer use SELECT statements to access database tables in the core ERP system like KNA1. For your own Z tables, you can keep using SELECT or UPDATE because they live in the same database as your cloud ABAP code.
Because you will always want access both to reading data from the ERP system and indeed updating it (like doing a goods issue), there has to be some mechanism to do this.
In this case, the communication mechanism is via whitelisted APIs. What are they, I hear you ask? Well, you know how 95% of standard SAP function modules are marked as “not released” but we use them anyway? Imagine if you couldn’t. Imagine if suddenly one day every unreleased function module in your Z programs started causing a syntax error. I imagine you would be stuffed; I know I would.
The whitelist in the ABAP cloud is like that horror scenario. Instead of being able to call any standard SAP function module or class you feel like, you have to choose from a list of approved ones. In return, SAP 100% guarantees those calls will keep working after an upgrade to the core system.
If you want to send and/or receive data from the ERP system, you have to use a whitelisted API. The definition of a RESTful API according to this site is thus: “A RESTful API is an application program interface (API) that uses HTTP requests to GET, PUT, POST, and DELETE data.”
To be even more precise, SAP has said that if it wants to whitelist a table, it will create a CDS view for it (read access) and for write access will offer a typed class-based API. At some point in the future, SAP also will support RFC calls, which might make you a bit less nervous.
This situation—communication with APIs—isn’t the end of the world, though it might seem like it at first glance. The question you have to ask yourself is whether the stability you get as a result of this approach outweighs the initial pain of doing everything in a different way. The point about stability is that it lets you make changes faster, and these days being able to adapt faster stops you going the way of the dinosaur or Blockbuster Video in a hurry.
With your Z tables, you can do code pushdown any way you fancy. Nothing has changed—except, as you’ll see, when it comes to business objects, which have to revolve around a CDS view.
Changes to the RAP Business Logic Layer
The changes in this area are a bit more radical. The BOPF you know and love is no more. It’s been replaced by something that—though conceptually identical—is implemented in a totally different way technically. In case you have a heart attack when you read that BOPF is now in “maintenance mode” when you’ve just spent the last three years writing all your new applications using BOPF—as SAP recommended—fear not: SAP says that your investment is safe and that from 2020 there will be native integration between RAP and BOPF, although it does say that once RAP is available to you, don’t use BOPF for any new developments.
At the time of writing, the new business object concept is not very old and thus will no doubt get radical changes in future releases. There are two strands to this: the use of a Business Definition Language and the idea that business objects are first-class citizens.
RAP Transaction Model and Draft Handling
The RAP transaction model distinguishes between two phases in the processing of operations on business objects:
- During the interaction phase, operations are performed on a business object instance (e.g., a position is created or changed). As a result of these operations, instances of the respective CDS entities are stored in the transaction buffer.
- The subsequent save sequence is triggered by a commit. The state of the transaction buffer is persistently written to the database. The state of the transaction buffer isn’t kept across multiple requests, as this would violate a key REST principle. The CDS entity instances that are stored in the transaction buffer, which have been created, modified, or deleted (modify), can be considered a logical unit of work (LUW) within the SAP system. As part of the save sequence, the LUW is persistently written to the database within a database LUW.
The draft handling in the ABAP RESTful application programming model allows to temporarily store the state of the transaction buffer with inconsistent application data persistently on the database. This enables you to distribute the interaction phase across multiple standalone requests or user sessions without violating the REST principles of stateless communication. Users can continue their work at a later point in time, regardless of the terminal device. The draft handling functionality is fully implemented by the RAP runtime.
Basically, the ABAP RESTful application programming model doesn’t preclude the implementation of a stateful application. The RAP transaction model technically includes an area (the transaction buffer) where the application state can be stored on the server side.
RAP Business Definition Language (BDL)
One of the primary benefits of a CDS view over a 100% identical SQL query is that a CDS view expresses the same information “semantically.” For example, an INNER JOIN on VBAK/VBAP is how a database (machine) thinks about linking two tables, whereas an “association” between two concepts (order header and order items) is how a human thinks about the relationship between two tables.
So the CDS definition reads like plain English but gets compiled into the exact same SQL statement in the background as the one generated by the more technical Open-SQL query.
When ABAP in the cloud came out in September 2018, SAP revealed the concept of a business definition, which is all about defining a business object in a text-based way, just like the DDL which defines a CDS view. You could now describe the nature of the business object (as in, what behavior it’s capable of) in a BDL definition (which is itself a specialized type of CDS view).
In the initial release of RAP, you only have the concept of a so-called unmanaged business definition, whereby you describe the business object behavior in the BDL but actually implement the logic using what appears at first glance to be traditional ABAP code, albeit with some new quirks.
In the future, the concept of managed business definitions will be introduced, via which, presumably, the BDL itself generates the code to control the behavior. A lot of ABAP programmers (including me) find that idea quite scary, but we’ll have to wait until SAP actually tells us what it means before going into a mad panic.
It’s worth noting that since the 1950s software companies have been promising that “next week” they’ll introduce an option to write a specification in plain English and have a program generate itself, needing not one line of code. Up until now, this has never happened in a meaningful way, so rather like nuclear fission, the actual realization of this promise always seems to be ten years away.
RAP Implementation Types (Managed vs Unmanaged)
The ABAP RESTful application programming model includes the concept of the implementation type, which you use to specify who provides the implementation of reading functionality (query) and transactional or writing functionality (behavior). There are two implementation types: managed and unmanaged. In the managed case, the programming model provides the desired functionality; in the unmanaged case, the application must do this by itself.
The technical implementation of read and write access or the behavior of a business object is handled by the business object provider. When implementing the business object, we distinguish between the use of the managed scenario and the unmanaged scenario:
Managed Scenario in RAP
In the managed scenario, you use a ready-made implementation of the business object provided by the ABAP RESTful application programming model, the managed business object provider. It implements the standard CRUD operations for creating (create), reading (read), updating (update), and deleting (delete) instances of the respective CDS entity during the interaction phase and the save sequence. This is also accompanied by the handling of the transaction buffer.
When using the managed scenario, an already executable business object that supports CRUD operations is available to you without any programming effort on your part. Optionally, you can add more logic to the save sequence (additional save) or implement it yourself (unmanaged save).
Unmanaged Scenario in RAP
In the unmanaged scenario, you can implement the standard functionality of a business object by yourself. This involves the interaction phase with the transaction buffer and the save sequence. This gives you the option of integrating the API of an existing application and wrapping it with RAP resources. This scenario is therefore often used for brownfield development.
In addition to the use cases that can be implemented by these implementation types, there are always very specific business requirements (e.g., the validation of a certain data constellation or the calculation of certain values of a business object instance). In these cases, the business object provider can’t provide an implementation. However, in both the managed and unmanaged scenarios, you can implement the respective business logic yourself.
RAP Business Objects as First-Class Citizens
SAP has also come up with the rather nebulous concept that a business object should be a first-class citizen. What that term means (in the non-SAP world) is that it (the business object) can be passed as a parameter, be the result of a functional method, and be assigned to a variable.
In essence, in RAP the business object definition is done via ABAP language constructs, and you have typed interfaces. This is in contrast to BOPF, in which you define metadata that generates classes with generic interfaces— so you can’t have a BOPF object instance as a RETURNING parameter, for example.
It could be argued that makes a standalone monster model class a first-class citizen as well: it has a typed interface and represents a business object. Moreover, how the ABAP interfaces used by RAP work out what their correct type should be is very strange indeed and happens under the hood seemingly by black magic.
RAP Entity Manipulation Language (EML)
The entity manipulation language (EML) is a standardized, type-safe API used to access the data and functionality of a business object. It’s an integral part of the ABAP language scope. Using EML, you can access instances of a business object in write mode (via the ABAP statement MODIFY ENTITIES), but you can also read individual instances from the transaction buffer (via READ ENTITIES).
EML plays a major role within the ABAP RESTful application programming model in the following use cases:
- Implementing the behavior of a business object: You can use EML statements to implement the behavior of a business object in ABAP. In this case, your application assumes the role of a business object provider.
- Performing operations on a business object: You need EML statements if you program an ABAP application that accesses the functionality of a business object as a consumer (i.e., assumes the role of the business object consumer). It’s also possible to use EML in the context of unit tests to check the functionality of a business object in your application.
When you use EML within the business object provider, for example, to read data for validation, you also use the EML in the business object consumer role. You use it to read data about the business object from the transaction buffer to validate it, bypassing authorization checks, for example, because the access is IN LOCAL MODE. You thus consume the read or write functionality of your own business object. In addition to read and write operations, you can also use EML to define transaction boundaries (COMMIT and ROLLBACK behavior) and trigger the save sequence.
Changes to the RAP User Interface Layer
This area has changed hardly at all. The idea was always that UI technology changes so fast that you need to totally decouple the backend from the frontend by having the UI layer consume OData services provided by the backend. For the moment, SAP has SAPUI5 as its preferred UI technology, but in this day and age something bigger and better could come along at any second.
The traditional model declares information that in the past could have been considered the job of the UI, such as which order the fields go in, alternate names, and basically all of the ALV field catalogue type information.
In RAP, such behavior in the UI is controlled totally by annotations in the CDS views. The UI layer is dumb and is solely concerned with making the application look as nice as possible. The idea is that if there are no smarts at all in the frontend, then you can switch technology at the flick of a switch and not have to change the backend at all.
That said, some people are deeply uncomfortable about controlling the UI by coding in what appears to be the database layer (the CDS view). It could be argued that a data model has no business knowing how its data is going to be interacted with in the frontend, especially if the model is designed to be consumed by many different applications.
A counterargument is that a CDS view is one level up from the database layer because one day (possibly) a CDS view will be able to consume sources other than database tables/views, such as OData services.
Whether you like the concept of UI annotations in a CDS view or not, one thing that’s quite impressive in RAP is that you get a sort of WYSIWYG preview of what your application will look like, generated on the fly as you add UI-specific annotations to your CDS view.
How this works is that you define your CDS view using ABAP in Eclipse. While in the CDS definition screen, at any point you can click Open Fiori Elements App Preview to see what the application would look like based on the current annotations in the CDS view.
This is very similar to the test tool in BOPF via which you could get a list of monsters on the fly and perform actions upon them, such as creating a new one, and have the result saved in the database. The big difference is the user interface, which is SAPUI5 as opposed to SAP GUI.
Going forward yet again, at some point in the future the UI annotations won’t need to be coded manually in the CDS view definition at all. You’ll have a WYSIWYG visual editor instead in which you drag fields around and change their properties and an application-specific file of annotations will be generated.
Technical Context of RAP Applications and Runtime
In the figure below you can see the technical context in which an application created with the ABAP RESTful application programming model is embedded. Here, you will gain an idea of the technical paths and protocols that can be used to access the data and services of a RAP application. A RAP application uses the SAP HANA database to persist application data. CDS custom entities allow you to connect an external system or other data source through synchronous communication using a query programmed, specifically in ABAP.
Although you don’t need to understand the specific technical components of the ABAP RESTful application programming model in detail for the RAP runtime to process RAP requests, it does help to know the essential building blocks involved in this process. It not only improves the general understanding of the programming model, but can also be very useful with regard to troubleshooting.
This type of request can be, for example, the creation of a purchase order via the CRUD operation create. A request can originate from an external application (e.g., a SAP Fiori interface or a web API consumer) using the OData protocol, or it can be made as a local call (that is, internal to the system) via the EML.
In the following bullet points we’ll describe the individual components:
- SAP Gateway: SAP Gateway implements the OData protocol and serves external applications as an entry point into the respective application. To do this, SAP Gateway receives the OData request and forwards it to the orchestration framework for generic processing.
- Orchestration framework: The orchestration framework maps the OData request to a RAP request and evaluates it generically. The orchestration framework is also known as the service adaptation and description language (SADL) framework. A read access is forwarded to the appropriate query implementation, a write and, thus, transactional access is processed via the business object framework. The orchestration framework thus forms the transactional bracket around the RAP request and is responsible, for example, for requesting locks, ETag handling, and commit and rollback behavior. For read and write accesses, the orchestration framework determines whether the methods of a managed or unmanaged implementation need to be invoked.
- Business Object Framework: The business object framework controls the processing of operations on a business object. It ensures that during the interaction phase and save sequence, the intended methods of the business object provider API are called in the managed or unmanaged behavior implementation. While in an OData request, the orchestration framework takes over the control of the interaction phase and the save sequence, you have the possibility via your ABAP and the EML code to control which operations run within the interaction phase and when the save sequence will be triggered.
Using SAP Gateway in RAP Applications
The ABAP RESTful application programming model uses OData by default to expose access to the application's functionality, using SAP Gateway as the framework and runtime environment. For you, however, SAP Gateway doesn’t appear during the development of RAP applications. The programming model generates the gateway artifacts in the background so that they can accept an OData request for the programming model at runtime.
This also means that you can’t use the ABAP RESTful application programming model to access the gateway development capabilities (that is, Transaction SEGW, and the data and model provider implementation), even if they are technically available on the respective ABAP application server. Such direct access would make the programming model dependent on a particular technology, which is contrary to the architectural goals of the programming model.
Quality Attributes of RAP
ABAP RAP has selected quality attributes:
- Evolution capability
- Development efficiency
- Testability
- Separation between business and technology
Evolution Capability in RAP
Software development has always strived to create software that is capable of evolution, that is, software that is (and remains) changeable in the long term and can also take into account new technical trends and developments. Technical trends usually concern the infrastructure of a business application, for example, a new UI technology or a way of storing data, rather than the business logic of the application.
Software is well adaptable to trends if its technical core hasn’t been mixed with technical coding for the infrastructure. It’s also useful to have the software provide a business-motivated API as an access point for consumers, making it usable in a variety of technical contexts. Similarly, the business core of an application should also be readily adaptable to additional business requirements. This is the case when there’s no technical coding in it.
How RAP Enables Long-Term Adaptability
The ABAP RESTful application programming model supports the quality attribute of evolution capability through its end-to-end declarative approach. Thanks to CDS, applications are generally independent of the underlying data source. The data model is declared exclusively at the logical level. UI annotations are also located on the logical level because with such annotations, you specify the desired functionality without having to know the concrete implementation in the UI. This makes it possible to leave annotations basically unchanged in the application, even if you later interpret them using a different UI technology.
You also declare transactional properties and business logic in the behavior definition without having to know the concrete technical implementation. Business services again abstract from the underlying runtime environment—the SAP Gateway system.
Prior to the service definition, you don’t yet reference a specific technical protocol that will be used to expose the defined entities. This reference must be established only in the service binding. From SAP’s point of view, service binding can therefore serve as an anchor point for adapting new interface technologies and protocols.
This evolutionary capability benefits not only the applications developed from scratch with the ABAP RESTful application programming model (RAP) but also the existing applications that have been encapsulated with the ABAP RESTful application programming model. Such encapsulated legacy applications can also be exposed to various interfaces and protocols using RAP means without having defined this in the legacy application itself. This also means that existing RAP applications can continue to benefit from newly supported technical functionality or interfaces (e.g., data retrieval for forms) in the future.
RAP Development Efficiency
The quality requirements for a programming model also include efficiently supporting application developers in building applications. Thus, it’s been a long-standing endeavor of software development to relieve the burden on development teams by offering technologies and crosscutting services (e.g., UI technologies, application servers, etc.) so that they can focus on implementing the business application layer.
The ABAP RESTful application programming model supports development efficiency with the following approaches:
Model-Based Development Approach
A model-based approach provides a formal language tailored to the specific application purpose. For example, BDL is a formal language tailored to the purpose of behavior modeling. Development objects (of the standard SAP) are generated from the source code created on the basis of the language (the model, which can also be a graphical model), or the model is evaluated generically at runtime. So, you declare the desired functionality (the “what”) and don’t have to bother about the concrete technical implementation (the “how”).
Tight Integration with ABAP
Based on the CDS data model, the ABAP RESTful application programming model is tightly integrated into the ABAP language, thereby ensuring strict typing of RAP-based interfaces (through derived data types). This allows static syntax checking and better tool support (e.g., through the code assist and element info in ADT). This in turn reduces the susceptibility to errors and the amount of research required, which benefits development efficiency.
Built-In Standard Implementations
The programming model provides standard implementations for certain application development tasks such as implementing standard operations (create, update, delete), transactional buffer management, persistence, and draft handling. You can use these standard implementations by specifying appropriate keywords in the behavior definition for the business object. This way, you can very quickly develop the first versions of a new application.
The standard implementation of OData is provided in the background by SAP Gateway, whose functionality you can access via service binding. You don’t even need to know that SAP Gateway is the technology used to do this. SAP Gateway knowledge is therefore not necessary, which has a positive effect on the number of prerequisites you need to bring along.
Consistent Business Vocabulary
The programming model defines a standard vocabulary for business applications and business logic. Validations (validation), determinations (determination), and actions (action) can be used as explicit keywords in the behavior definition and are thus also included in the ABAP language scope. These concepts facilitate the communication within the development team and with subject matter experts when discussing requirements and their implementation.
Testability in RAP
Changeability has been ensured since the early days of agile development, primarily via automated testing at various levels of granularity (from individual modules to complete end-to-end applications). However, software usually can’t be tested easily. The testability quality attribute determines how easily the functionality of an application can be tested automatically by a test suite. Program code is much easier and safer to change if it has been backed up with reliable test cases using test automation tools.
The ABAP RESTful application programming model introduces the interaction phase (separate from the save sequence) and the transactional buffer. By using the ABAP RESTful application programming model, it’s difficult to “bypass” this concept during programming. The presence of the (transient) transactional buffer makes it easier to store different test data depending on the test case and to execute test cases automatically one after the other without overlapping the data areas. Tests are typically enabled by implementing test cases using the ABAP Unit testing framework, which allows you to develop and execute unit tests for your applications.
Separation of Business and Technology in RAP
The principle of separating business and technology is an application of the separation of concerns principle. It’s necessary to develop a business logic that can be changed independently of technology, and that can be reused as permanently as possible. This principle is an important means of implementing certain quality attributes.
Business logic refers to the implementation of the application purpose of business software, that is, the program logic with which, for instance, purchasing and ordering processes are handled. The technical environment of such a domain-oriented core includes the UI and the persistence layer (e.g., the database technology used), for example.
Technological changes occur more frequently or for different reasons than changes in the application domain. Thus, the calculation of the best purchase price is independent of the logic of the technical environment, for example, the code artifacts needed to display this price on the UI or the interface and message formats needed to transmit the price to a third-party system. Software is easier to customize if the business logic is separated from the technical program logic.
With the business object’s behavior definition and implementation, the ABAP RESTful application programming model creates an explicit space for the business logic. It becomes difficult to incorporate technically motivated coding into this behavior logic, which will impact further application development steps. The programming model also defines a flow for processing standard operations or actions. This process specifies explicit points in time and interfaces, for example, to implement authorization checks, numbering, or saving business data.
Conclusion
There you have it—the ABAP RESTful application programming model! What do you think? Not as scary as you thought or something you’ll stay away from at all costs? What about the changes discussed above: do they sound like a good direction? Let us know in the comments!
Editor’s note: This post has been adapted from sections of the books ABAP to the Future by Paul Hardy and ABAP RESTful Application Programming Model: The Comprehensive Guide by Lutz Baumbusch, Matthias Jäger, and Michael Lensch. Paul is a senior ABAP developer at Hanson and has worked on SAP rollouts at multiple companies all over the world. Lutz has worked as an SAP developer since 2000 and has been responsible for international SAP projects in various roles and areas. Matthias is a freelance full-stack ABAP developer, architect, and trainer. Michael leads a team of SAP developers at All for One Group SE.
This post was originally published 9/2020 and updated 8/2025.
Comments