If you’re exploring SAP RAP and unsure where to begin, this blog is for you. Before jumping into development, it’s important to understand the fundamentals, what RAP is, what tools you need, and what you actually build using it.
Prerequisites
To get the most out of the RAP blog series, you should have basic working knowledge of:
-
ABAP – especially object-oriented ABAP
-
CDS Views – Core Data Services are the foundation of RAP’s data model
-
OData – the protocol used to expose data and services from SAP systems
Let’s quickly recap CDS and OData in the RAP context.
➤ What are CDS Views?
CDS views are semantically rich data models used for code pushdown in SAP. Built on top of SQL, they support:
-
Complex field selections
-
Built-in functions
-
Element annotations and UI metadata
-
Associations between entities
-
Extensibility and reusability
In RAP, CDS views are used to define both the interface view (raw data structure) and projection view (UI-facing structure).
➤ What is OData?
OData (Open Data Protocol) is a REST-based service protocol that allows standardized access to SAP data. It supports HTTP verbs like GET, POST, PUT, DELETE and is used in:
-
SAP Fiori / Fiori Elements
-
SAPUI5
-
SAP S/4HANA
-
SAP BTP
-
Mobile apps and Web APIs
In RAP, OData V2 & V4 is used to expose the application’s service – either as a UI service or a Web API.
What is SAP RAP?
The ABAP RESTful Application Programming Model (RAP) is SAP’s modern framework for building enterprise-grade applications.
RAP is a combination of:
-
Concepts – like Business Object, Data Model, Query
-
Tools – such as ADT, ABAP Profiler, ATC, ABAP Debugger
-
Frameworks – the RAP runtime engine
-
Languages – SQL, ABAP, and EML (Entity Manipulation Language)
- Best Practices – RAP BO Contract, Strict Mode
Confused with the terms? No worries. We will cover most of them in the next blogs.
It enables the development of both:
-
SAP Fiori apps using Fiori Elements (based on List Report + Object Page)
-
Web APIs using OData V2 & V4
RAP Architecture (Briefly Explained)
RAP architecture is layered into:
-
Data Modeling
-
Define CDS interface and projection views
-
-
Business Provisioning
-
Add behavior definition and implementation
-
-
Service Consumption
-
Expose the app as UI or API using OData V2 & V4
-
These layers allow separation of concerns, enabling clean extensibility and better testing.
What Tool Do We Use to Build RAP Apps?
We use ADT (ABAP Development Tools) in Eclipse, the primary IDE for RAP development. It supports modern ABAP syntax, developer-friendly features, and seamless RAP object creation.
What Objects Do We Create in a RAP App?
To build a complete RAP-based application, we work with a set of artifacts that define the data model, behavior, and exposure layer. Here's a breakdown of the key objects, categorized as Mandatory (M) or Optional (O) depending on your use case.
Data Model Layer
-
Database Table (M)
The underlying custom table that holds your transactional or master data. -
CDS View Entity – Interface View (Basic) (O)
A view on top of your table to reuse basic fields and structure across applications. -
CDS View Entity – Interface Root View (Transactional) (M)
The root CDS entity that forms the backbone of your RAP BO. It supports transactional behavior and is used for behavior definition. -
CDS Projection View (Consumption View) (O)
Projects the root CDS entity and adds annotations for UI or API exposure. -
Metadata Extension (O)
Adds UI annotations like labels, positions, and facets to CDS projection views. Used to define how data appears in Fiori Elements apps. -
Access Control (DCL) (O)
Defines instance-level or field-level authorizations on CDS views using ABAC (Attribute-Based Access Control). Basically, we create this artifact to put authorization at data model level.
Behavior Layer
-
Behavior Definition (M)
Declares allowed operations like create, update, delete, and defines associations, draft handling, validations, and actions. -
Behavior Projection (O)
Projects behavior definition onto the projection CDS view. Required if you created CDS Projection View. -
Implementation Class (M for unmanaged or custom logic)
Implements the logic behind actions, determinations, validations, or custom persistence in unmanaged or extended managed scenarios.
Service Layer
-
Service Definition (M)
Exposes one or more CDS projection views (If created) or Interface views. -
Service Binding (M)
Binds the service definition to a protocol (recommended OData V4) and specifies whether it is for a UI (Fiori Elements) or API.
Each of these artifacts contributes to the layered architecture of RAP.
Once all of this is in place, you have a fully functioning RAP app, ready to be previewed, extended, or consumed via UI or integration.
Ready to Build Your First RAP App?
If all of this sounds like a lot, no worries. You don’t need to master it all before getting started.
Let’s jump into our first hands-on exercise, where you’ll build a full RAP-managed application from scratch:
👉 Build a Simple RAP Managed App for Billing Document
Want to Learn RAP on BTP?
If you're not working on an on-premise system and want to practice RAP in SAP BTP ABAP Environment, follow these tutorials to get your system set up:
Once your setup is complete, you can follow all RAP exercises from the blog series on BTP as well.
Happy Learning. 🤟
