When to Use ABAP RAP: A Practical Guide for SAP Developers

Modern ABAP development offers multiple architectural approaches, and choosing the right one can significantly influence the long-term maintainability and extensibility of your applications.

The ABAP RESTful application programming model (ABAP RAP) represents SAP’s strategic direction for cloud-ready, service-oriented development. But not every project requires ABAP RAP. This guide helps you understand when ABAP RAP is the right choice and when a classic ABAP approach may be more appropriate.

TL;DR

• ABAP RAP is SAP’s modern programming model for SAP S/4HANA and SAP BTP.
• It’s ideal for cloud-ready, service-based, SAP Fiori-driven applications.
• Not every custom development needs ABAP RAP.
• Use ABAP RAP when building new, transactional, OData-based applications aligned with SAP’s clean core strategy.

What Is ABAP RAP?

The ABAP RESTful application programming model (also called “RAP”) is a new way to develop enterprise applications on the ABAP platform. It includes all steps of application development from the data model, CRUD operations (e.g., creating, reading, changing, or deleting business objects), business logic (e.g., calculations or checks), and transactional behavior (e.g., locking behavior, numbering, etc.) to the technical interface (typically OData).

ABAP RAP is designed to be a long-term sustainable solution for implementing business applications on the ABAP platform. For this reason, you can use this programming model to develop completely new business applications (greenfield development) as well as to integrate existing business applications, that is, to wrap them in ABAP RAP (integration of legacy code or brownfield development). Existing applications interconnected in this way benefit from the qualitative properties of the programming model just as much as newly developed applications .

The REST architectural style is directly reflected in the name of the programming model. When you implement enterprise applications using the ABAP RESTful application programming model, this automatically creates REST-based APIs and applications that follow the design principles of this architectural style. ABAP RAP is based on a stateless web server as part of the ABAP platform that provides REST-based APIs. In this context, the application state can be kept persistently on the client or on the server side on the database, but not in the context of an ABAP session, as is the case with classic applications on SAP NetWeaver Application Server (AS) for ABAP.

To keep the application state persistent on the database, you can use the draft handling feature in the ABAP RESTful application programming model. Application data can be stored persistently in the database as a draft, that is, in a draft mode, for a user. The maintenance of the data can then be continued at a later time or from another terminal device. In this way, scalability and load balancing can be leveraged within a cloud environment, as API requests to a RAP application can be processed independently of each other and therefore by different application servers.

Why SAP Introduced ABAP RAP

ABAP RAP is promoted for transactional applications built on and for the cloud, which are primarily used to collect, change, and display master and transaction data. It’s constantly being expanded and covers the requirements of both developers and users in various ways.

From a technical perspective, ABAP RAP initially implements code pushdown. This involves making optimal use of the SAP HANA database by performing calculations on the database wherever possible and reducing the number of queries. This is achieved by using ABAP core data services (ABAP CDS). In the standard SAP system on SAP S/4HANA, extensive CDS views are already available via the virtual data model (VDM), which you can reuse.

ABAP RAP takes a large part of the implementation work off your hands. In what is called the managed scenario, standard operations for creating, changing, deleting, or listing business object instances are implemented generically by the framework and don’t have to be implemented manually by you for each application. Deviations from the standard implementation and extensions can be easily integrated into the behavior definition via determinations, actions, and validations as well as via the declarative configuration of individual components.

If that isn’t sufficient, parts of the ABAP RAP application can be implemented unmanaged. In this case, you need to replace the standard logic with your separately implemented logic, for example, for number assignment or lock logic. In extreme cases, you can also implement the entire business object yourself, including the standard operations (unmanaged scenario). This is particularly useful if you want to encapsulate existing applications using ABAP RAP.

When You Should Use ABAP RAP

ABAP RAP is a standardized programming model for developing applications for SAP S/4HANA, SAP S/4HANA Cloud, and SAP Business Technology Platform (SAP BTP). It provides extensive functions and, associated with this, a wide variety of options for developing applications in different areas (e.g., analytical or transactional applications). Which of these functions and which development approach you should choose to implement your specific requirements depends (in addition to the requirements themselves) not least on the given framework conditions and, of course, on your requirements with regard to the contents.

Let’s dive into some specific use cases.

Building New SAP S/4HANA Applications

If you want to create a completely new transactional application for SAP S/4HANA that is based on a new data model and for which no business logic is yet available, this is known as the greenfield approach. In this case, the managed scenario is the right choice. This implementation type provides you with the greatest possible support during the implementation.

ABAP RAP enables the creation of OData services that serve as the basis for the development of role-based SAP Fiori apps. You can use the draft concept to develop stateful applications using stateless communication via the OData protocol. You can create transactional SAP Fiori apps and read-only data staging apps. Another use case involves the development of analytical applications for SAP Analytics Cloud based on services exposed via the Information Access (InA) protocol.

Developing for SAP BTP ABAP Environment

SAP BTP ABAP environment supports and promotes ABAP RAP, with a special, restricted version of the ABAP programming language. These restrictions include features that are not applicable in cloud environments (file access, system calls, etc.) and unsupported features (dynpros, lists, etc.). To check the readiness of any specific on-premise ABAP code that might be migrated to SAP BTP, SAP provides the ABAP Test Cockpit (ATC) check variant SAP_CP_READINESS.

Creating OData-Based APIs

You can also publish an OData service as a web application programming interface (API) so that it can be used by any client, regardless of a particular user interface (UI). In this case, the OData service doesn’t contain any UI-specific metadata because the usage doesn’t take place in the UI context. The OData service remains the basis regardless of the type of use, whether UI or API. Only the binding type in the respective service binding differs.

Implementing Draft-Enabled Business Applications

Beyond the standard operations, additional specific operations can be declared for a CDS entity in ABAP RAP. These operations must then be implemented in the behavior pool. Both actions and functions are possible.

Whenever an ABAP RAP business object supports write operations, you need to worry about the data consistency of a persistent business object instance. In this case, you must ensure that concurrent write accesses don’t jeopardize the data consistency of a business object instance. You can use the following RAP procedures for this purpose:

• Pessimistic locking
• Optimistic locking

Both methods can be combined within one RAP business object. If you use the optimistic locking procedure, you must declare the pessimistic locking procedure as well. The pessimistic locking procedure is required in any case to prevent concurrent access.

In ABAP RAP, you have two options for declaring internal business logic: determinations and validations. Both behaviors are optional components of a RAP business object and require implementation in the behavior pool. Determinations and validations are available in the managed scenario (with and without draft handling) and in the unmanaged scenario (with only draft handling).

You can declare draft handling only for an entire RAP business object and not for individual CDS entities. You do this by using the “with draft” keyword in the behavior definition head.

managed;

strict ( 2 );

with draft;

define behavior for /DMO/R_Travel_D alias Travel

...

It’s also possible to introduce draft handling subsequently for a RAP business object, even if existing data is already located in the production database tables. The draft instances are kept separate from production data.

Following the Clean Core Strategy

The clean core concept simply describes the idea of not making any enhancements or even changes to the standard SAP system that could cause issues during the upgrade, in case the standard SAP system changes. Without this kind of adjustment, upgrade projects are significantly simplified. In SAP S/4HANA Cloud Public Edition and the SAP BTP ABAP environment, upgrades are carried out automatically, so clean core is not only desirable but also necessary in the cloud context. ABAP developments carried out there are always clean core by definition because ABAP Cloud and the ABAP for cloud development language version don’t allow any syntactical use or adaptation, and no calling of nonreleased objects.

Even though the “keep the core clean” principle applies to SAP S/4HANA, both on-premise and in SAP S/4HANA Cloud Private Edition, you have the option of using all SAP development objects for your own developments, even if they aren’t released and the API release isn’t enforced via a syntactical check. Likewise, it’s still technically possible to make modifications to the system. ADTs are available as a development environment for this purpose.

When RAP Might Not Be the Right Choice

Although ABAP RAP is the recommended programming model for modern, cloud-ready development, it isn’t required for every scenario. The decision depends on your system landscape, architectural requirements, and the type of application you’re building. In certain situations, classic ABAP development techniques remain fully appropriate and often simpler.

Maintaining Legacy ECC Systems

The ABAP platform is no longer provided individually as SAP NetWeaver AS for ABAP, but is part of an SAP S/4HANA installation. If you’re running an SAP ECC system, ABAP RAP will not work for you.

Small Utility Programs

ABAP RAP is designed for transactional business applications built around business objects and service exposure. For small, standalone utility programs or background jobs without service requirements, classic ABAP development may be more appropriate.

Simple Reports

For straightforward read-only reports that retrieve data and display it without requiring draft handling, transactional buffering, or OData service exposure, classic ABAP techniques such as SELECT statements combined with ALV output are typically sufficient.

Existing Dynpro-Based Applications

As mentioned earlier, SAP BTP ABAP environment uses a restricted version of ABAP that does not include unsupported features like dynpros.

ABAP RAP vs. Classic ABAP Programming: Key Differences

ABAP RAP and classic ABAP programming are not competing languages. They are different programming approaches within the same ABAP platform. Classic ABAP development focuses on procedural logic and object-oriented techniques that run within the traditional application server session model. ABAP RAP, by contrast, introduces a behavior-driven, service-oriented architecture designed for cloud-ready, REST-based applications. Understanding these structural differences helps clarify when each approach is most appropriate.

How RAP Fits into the SAP Development Landscape

The ABAP RESTful application programming model is available with the following products.

SAP BTP ABAP Environment

ABAP RAP Is available for efficient application development on SAP BTP. New releases of SAP BTP ABAP environment (also known as Steampunk) are published quarterly. This means that the latest features of the programming model are also always provided. You can use SAP BTP ABAP environment as a platform to implement standalone applications. This enables you as an SAP partner to develop and operate cloud applications. In addition, you can use the side-by-side extension option of the application software such as SAP S/4HANA, SAP S/4HANA Cloud, or SAP ERP. This isn’t necessarily limited to application software from SAP, but can ultimately integrate any application, as long as it provides suitable interfaces.

SAP S/4HANA Cloud ABAP Environment

The ABAP Cloud development model used in SAP BTP ABAP environment has also been made available with SAP S/4HANA Cloud. In the ABAP environment of SAP S/4HANA Cloud, you therefore use the same development model (ABAP RAP) as you would in the SAP BTP ABAP environment. Because it’s available integrated in the SAP S/4HANA Cloud application, SAP S/4HANA Cloud ABAP environment is also sometimes called Embedded Steampunk. This means that ABAP RAP is also available with SAP S/4HANA Cloud.

ABAP Platform for On-Premise SAP S/4HANA

ABAP RAP for on-premise SAP S/4HANA first became available with the ABAP platform for SAP S/4HANA 1909 FPS00 (equivalent to SAP NetWeaver 7.54). ABAP RAP replaced the ABAP programming model for SAP Fiori, which has already been supported from SAP NetWeaver 7.50 onward. However, the ABAP programming model for SAP Fiori will continue to be fully supported.

Skills You Need to Get Started with ABAP RAP

In order to become an ABAP RAP-qualified developer, you’ll need to become familiar with the following technologies.

OData

The Open Data Protocol (OData) is a specification of a REST-compliant API based on HTTP. As an open standard, it’s managed by the Organization for the Advancement of Structured Information Standards (OASIS) consortium. An OData service exposes application data for read and/or write access by a consumer. The OData protocol defines the communication between the consumer and the OData service.

Behavior Definitions

The CDS behavior definition is the central development object for declaring the behavior of a business object via the behavior definition language (BDL). When you add a behavior definition to a CDS root entity, you’re defining an ABAP RAP business object.

Managed vs Unmanaged Scenarios

The implementation type is your first specification in the behavior definition. You use it to specify the source of the RAP business object implementation. There are two sources:

• Managed: SAP provides the implementation through the RAP framework. The implementation can be done by a business object provider, the draft handling provider, or both in combination.
• Unmanaged: The RAP business object itself provides the implementation via the behavior pool (unmanaged business object provider).

EML (Entity Manipulation Language)

The entity manipulation language (EML) is a component of the ABAP language and enables access to RAP business objects. Because business objects are typically used via the OData protocol from outside (e.g., via an SAP Fiori interface or a web application programming interface [API]), EML must enable type-safe access to business objects directly via ABAP. EML interacts with business objects by triggering the operations defined for the business object’s specific entities. An operation can only be triggered by EML if it has been previously defined for the corresponding entity in the behavior definition and implemented in the behavior implementation.

Recommended Resources for Learning ABAP RAP

If you want to build real confidence with ABAP RAP, it helps to combine a dedicated guide with resources that strengthen the surrounding skills ABAP RAP depends on.

We recommend starting with a focused guide to the ABAP RESTful application programming model to understand behavior definitions, managed and unmanaged scenarios, draft handling, and service exposure end-to-end.

Then, to deepen your expertise, consider complementary resources such as:

• ABAP in the Cloud: Essential if you’re building RAP applications in SAP BTP or working within the ABAP Cloud model.
• Core Data Services for ABAP: Since ABAP RAP business objects are built on CDS entities, strong data modeling skills are foundational.
• ABAP Development for SAP HANA: For understanding code pushdown, performance considerations, and HANA-optimized development.
• ABAP Programming Model for SAP Fiori: Helpful for understanding how RAP services power Fiori-based transactional applications.
• Complete ABAP: For strengthening modern ABAP fundamentals, language features, and clean coding practices that support RAP development.

If you prefer structured learning, Rheinwerk Courses covering ABAP, ABAP Cloud, and CDS provide hands-on guidance and guided exercises to reinforce the concepts.

Together, these resources help you move beyond simply “using ABAP RAP” to designing clean, scalable, cloud-ready applications that align with SAP’s modern development strategy.

Frequently Asked Questions

Here are some frequently asked questions about using ABAP RAP.

Is ABAP RAP mandatory in SAP S/4HANA?

No, ABAP RAP is not mandatory in SAP S/4HANA. Classic ABAP development techniques such as procedural ABAP, ABAP Objects, Dynpro-based applications, and traditional reports are still supported in SAP S/4HANA (especially in on-premise systems). However, ABAP RAP is the recommended programming model for building new transactional, service-based applications that align with SAP’s clean core and cloud strategy. If you’re developing new SAP Fiori-based business applications or exposing OData services, RAP is typically the preferred approach.

Can I still use classic ABAP?

Yes. Classic ABAP remains fully usable—particularly in SAP S/4HANA on-premise environments. Many existing custom developments, reports, batch jobs, and enhancements are built using classic ABAP or ABAP Objects. These approaches continue to function and are often appropriate for simple reports, background processing, utility programs, and enhancements in existing applications. However, for new, cloud-ready, transactional applications (especially those designed around OData and SAP Fiori) ABAP RAP provides architectural advantages and better alignment with SAP’s long-term direction.

Is ABAP RAP required for SAP BTP ABAP Environment?

For new development in SAP BTP ABAP environment (often referred to as “Steampunk”), ABAP RAP is effectively the standard and recommended programming model. Because the ABAP environment in SAP BTP follows the ABAP Cloud model, development is restricted to released APIs and cloud-compliant techniques. ABAP RAP fits naturally into this model and is designed to support side-by-side extensions and service-based architectures. ABAP RAP is the framework intended for building business objects and exposing services in this environment.

Is ABAP RAP only for cloud systems?

No. ABAP RAP is not limited to cloud systems. It can be used in SAP S/4HANA on-premise, SAP S/4HANA Cloud, and SAP BTP ABAP environment. That said, ABAP RAP was designed with cloud principles in mind, such as clean core, service orientation, and strict API usage. Even in on-premise systems, using ABAP RAP helps future-proof your development and align with SAP’s strategic direction.

How hard is it to learn RAP?

The difficulty depends on your background. If you already have experience with ABAP Objects, CDS views, OData, and SAP Fiori, then learning ABAP RAP is largely about understanding its structure: behavior definitions, service bindings, and the managed vs. unmanaged scenarios. If you’re coming from classic procedural ABAP without experience in CDS or service-based design, the learning curve can feel steeper because RAP introduces a more declarative and layered architecture. That said, once the conceptual model “clicks,” many developers find ABAP RAP reduces repetitive coding and enforces cleaner design patterns.

Conclusion: Choosing the Right Model for Your Project

ABAP RAP is not a replacement for ABAP but rather an evolution of how enterprise applications are designed on the ABAP platform. It is particularly well-suited for transactional, service-based, cloud-aligned applications that follow REST principles and clean core guidelines. However, classic ABAP development remains valid and appropriate for many scenarios, especially in stable on-premise environments and for simpler program types.

The key is to evaluate your requirements carefully. If your application requires business object behavior, draft handling, OData exposure, and long-term cloud alignment, RAP is the natural choice. If your needs are simpler or tied to legacy architectures, traditional ABAP development may still be the better fit.

Choosing the right programming model isn’t about following trends. It’s about selecting the architecture that best supports your system landscape and future roadmap.

This post was originally published 4/2026.