If there is one technology that embodies the Clean Core philosophy in ABAP development, it is the RESTful Application Programming Model — RAP. Designed from the ground up for cloud-ready, upgrade-safe extensibility, RAP is SAP’s strategic programming model for building modern business applications in ABAP. This guide walks you through what RAP is, why it matters for clean core, and how to get started building with it.
What Is RAP and Why Does It Matter?
The ABAP RESTful Application Programming Model (RAP) is a declarative, end-to-end programming framework for developing OData-based services and Fiori applications. It provides a structured way to define business objects, their behaviors (create, read, update, delete), transactional logic, and user interface projections — all using CDS (Core Data Services) views and ABAP classes.
From a clean core perspective, RAP is significant because it enforces several key principles by design:
- API-based access: RAP applications are built on released CDS entities and APIs — not direct table access.
- ABAP for Cloud Development: RAP behavior implementations use only cloud-ready ABAP language features.
- Upgrade safety: CDS extensions and behavior extensions are designed to survive SAP upgrades without manual rework.
- Fiori-ready by default: RAP services expose OData APIs that work seamlessly with SAP Fiori Elements, enabling standardized UI development.
Core Components of a RAP Application
1. Database Table and CDS Views
Every RAP business object starts with a database table (defined with @AbapCatalog annotations) and a CDS root view entity that reads from it. The root view forms the foundation of your business object — it defines the fields, associations to related entities, and key structures that drive the entire object model.
2. Behavior Definition (BDEF)
The Behavior Definition describes what a business object can do — its supported operations (create, update, delete), validations, determinations, and custom actions. This is a declarative artifact that separates the “what” from the “how,” making behavior logic explicit and maintainable.
3. Behavior Implementation Class
The Behavior Implementation (a global ABAP class inheriting from cl_abap_behavior_handler) contains the actual ABAP logic for each operation defined in the BDEF. Validations check data integrity before saving, determinations auto-calculate field values, and actions implement business-specific operations beyond standard CRUD.
4. Service Definition and Binding
A Service Definition selects which CDS views to expose as an OData service. The Service Binding binds this definition to a specific protocol (OData V2 or V4) and allows you to publish and test the service directly from ADT (ABAP Development Tools in Eclipse) using the built-in Fiori preview.
RAP in Practice: Building Clean Core Extensions
When extending standard SAP applications with RAP, you use CDS View Extensions and Behavior Extensions to add custom fields and logic to existing business objects — without modifying SAP’s standard code. This is the clean core way: extend through official extension points, not through modifications.
For example, adding a custom field to the SAP Sales Order business object involves creating a CDS extension that adds your field to the standard view, an Extension Include structure for the underlying table, and a behavior extension that handles the persistence and validation of your custom field. The entire extension lives in your custom namespace and survives upgrades cleanly.
Getting Started with RAP on SAP BTP
The easiest way to start learning RAP is through an SAP BTP trial account with the ABAP environment. SAP provides free trial access that includes a fully functional ABAP Cloud development system, pre-configured with ADT integration and access to released API objects.
RAP is not just a technology choice — it is a commitment to clean, maintainable, upgrade-safe ABAP development. For organizations on a clean core journey, it is the natural home for all new custom functionality.