Introduction to RAP and ABAP Cloud
The ABAP RESTful Application Programming Model (RAP) is SAP's strategic development model for building modern transactional applications, APIs and extensions in SAP landscapes.
RAP is a core pillar of ABAP Cloud and represents SAP's long-term direction for enterprise application development. Whether you are developing on SAP BTP ABAP Environment (Steampunk), SAP S/4HANA Cloud Public Edition, SAP S/4HANA Cloud Private Edition or SAP S/4HANA On-Premise 2022+, RAP is the recommended programming model for new development projects.
Unlike classical ABAP development where developers manually create database tables, business logic, OData services, authorization checks and UI integrations, RAP provides a model-driven architecture that standardizes the entire application lifecycle.
RAP applications are built around Business Objects and use a collection of development artifacts such as CDS View Entities, Behavior Definitions, Behavior Implementations, Projection Views, Service Definitions and Service Bindings.
The result is a development model that is cloud-ready, upgrade-stable, API-first and aligned with SAP's Clean Core strategy.
Important Concept
RAP is not a programming language.
ABAP remains the programming language. RAP is a development model and architectural framework that defines how enterprise-grade business applications should be designed, implemented and exposed in modern SAP systems.
Think of RAP as SAP's successor to traditional ABAP application development rather than a replacement for ABAP itself.
Why Did SAP Create RAP?
To understand RAP, we first need to understand the challenges of classical ABAP development.
Traditional SAP applications were built using Dynpro screens, function modules, custom reports, direct database access and SAP Gateway services. While extremely powerful, these applications were often tightly coupled to SAP internals and difficult to adapt during upgrades.
As SAP moved toward cloud-native software, new architectural requirements emerged:
- Upgrade Stability
- Cloud Readiness
- API-First Architecture
- Clean Core Compliance
- Standardized Service Exposure
- Business Object Orientation
- Fiori-First User Experience
- Lifecycle Consistency
- Reduced Custom Framework Development
RAP was introduced to address these requirements and provide a single strategic programming model across all SAP cloud and on-premise environments.
RAP in Real SAP Applications
A common misconception is that RAP is only used for custom developments.
SAP itself increasingly develops new business applications using RAP. Many SAP S/4HANA Cloud Public Edition applications use RAP Business Objects as their transactional foundation.
Examples include:
- Procurement Applications
- Supplier Management Apps
- Business Configuration Applications
- Workflow Configuration Apps
- Extensibility Applications
- Custom Business Object Applications
As architects, this is important because adopting RAP means aligning custom development with the same architecture SAP uses internally.
Architect Perspective
Many developers think RAP is simply a framework for generating OData services.
Architects view RAP differently.
RAP represents SAP's transition from Table-Centric Development to Business Object-Centric Development.
This shift is one of the most important architectural changes introduced since SAP HANA and is a foundational pillar of SAP's Clean Core strategy.
Interaction Phase and Save Sequence
One of the most important architectural concepts in RAP is the separation between the Interaction Phase and the Save Sequence. Understanding this separation explains why RAP applications are scalable, transactional and cloud-ready.
During the Interaction Phase, RAP processes user interactions in memory using a transactional buffer. Whenever a user changes a field, triggers an action or performs a business operation, RAP executes business logic without immediately updating the database.
This allows RAP to validate data, derive values, execute actions and maintain transactional consistency while minimizing unnecessary database operations.
The Save Sequence begins only when the user explicitly clicks Save. RAP then executes a controlled persistence process, performs final consistency checks and writes the accumulated changes to SAP HANA as a single transaction.
Real Project Example: Real-World Example: Sales Order Processing
Consider a Sales Order application built using RAP.
A user changes the Customer, Quantity and Delivery Date multiple times before saving the document. During this process RAP continuously validates business rules, recalculates totals, derives values and updates the transactional buffer.
Despite multiple user interactions, no database update occurs.
Only when the user clicks Save does RAP execute the Save Sequence and persist the final version of the Sales Order to SAP HANA.
This approach improves performance, reduces database load and guarantees transactional consistency.
| Aspect | Interaction Phase | Save Sequence |
|---|---|---|
| When it runs | Every user action | Only when Save is clicked |
| Data location | Transactional Buffer | Database |
| Execution frequency | Can execute many times | Runs once per save |
| Database updates | Not allowed | Performed during persistence |
| Rollback capability | Yes | Only before final commit |
| Purpose | Business processing and validations | Persistence and transaction completion |
Architect Perspective
A common misconception is that RAP updates the database every time a field changes.
In reality, RAP uses an in-memory transactional buffer during the Interaction Phase. Database writes occur only during the Save Sequence, allowing RAP to provide Draft Handling, EML processing, Feature Control and transactional consistency.
The Evolution of SAP Technology
RAP did not appear overnight.
It is the result of more than five decades of SAP technology evolution and lessons learned from multiple generations of ERP architecture.
Understanding this evolution helps explain why SAP introduced ABAP Cloud, released APIs and RAP as the future development model.
From SAP R/1 to RAP
SAP R/1 introduced centralized enterprise processing using a single-tier architecture.
SAP R/2 expanded this model to large-scale mainframe environments and supported enterprise-grade transaction processing.
SAP R/3 introduced the famous three-tier architecture consisting of Presentation, Application and Database layers, which dominated enterprise software development for nearly two decades.
SAP NetWeaver added integration capabilities and service-oriented architecture concepts that enabled systems to communicate through standardized interfaces.
SAP HANA transformed application development through in-memory computing, code pushdown and real-time analytics.
SAP S/4HANA simplified the ERP data model and introduced CDS Views, OData services and SAP Fiori as strategic technologies.
ABAP Cloud introduced released APIs, strict development rules and upgrade-safe extensibility.
RAP represents the culmination of this journey by providing a unified Business Object-centric programming model for transactional applications, APIs and cloud-ready extensions.
ABAP Cloud Building Blocks
- Core Data Services (CDS) for semantic data modeling
- RAP for transactional processing and business objects
- ABAP for Cloud Development language version
- Released APIs for stable SAP integration
- Released Extension Points for upgrade-safe enhancements
- ABAP Development Tools (ADT) in Eclipse
RAP serves as the transactional engine of ABAP Cloud and provides the architecture, runtime and development framework used to implement modern SAP business applications.
Advanced RAP Concepts
RAP extends far beyond CRUD applications.
Throughout this learning path you will gradually move from basic Business Objects to advanced enterprise-grade capabilities.
- Managed and Unmanaged RAP
- Draft Handling
- Actions and Determinations
- Validations
- Late Numbering
- Custom Entities
- Side Effects
- Feature Control
- EML (Entity Manipulation Language)
- BDL (Behavior Definition Language)
- Business Events
- Authorization Framework
- Performance Optimization
EML and BDL at a Glance
Two RAP concepts that frequently appear in architect interviews are EML and BDL.
BDL (Behavior Definition Language) is used to define the behavior of a Business Object. It specifies operations such as Create, Update, Delete, Actions, Determinations, Validations and Authorizations.
EML (Entity Manipulation Language) is the API used by ABAP developers to interact with RAP Business Objects programmatically.
MODIFY ENTITIES OF zi_purchaseorder
ENTITY PurchaseOrder
CREATE FROM lt_po_data
FAILED DATA(lt_failed)
REPORTED DATA(lt_reported).Think of EML as the RAP equivalent of calling a BAPI, except that it operates directly on Business Objects and automatically respects RAP transactional behavior.
Where RAP Fits in ABAP Cloud
RAP is the transactional pillar of ABAP Cloud. It provides a model-driven architecture for implementing business objects, transactional behavior and service exposure.
ABAP Cloud Use Cases
| Use Case | Technology | Purpose |
|---|---|---|
| Transactional | RAP | Business transactions and CRUD operations |
| Analytical | CDS + Embedded Analytics | KPIs, reports and dashboards |
| Integration | OData, HTTP, Events | System integration |
RAP Architecture Layers
- Data Model - CDS View Entities
- Behavior - Business Logic
- Projection - Consumption Layer
- Service Definition - Business Service
- Service Binding - OData Exposure
- Consumption - Fiori, APIs, Mobile
Core RAP Artifacts
A RAP application is built using a series of development artifacts that work together to model business data, implement business behavior and expose services for consumption.
Understanding these artifacts is critical because every RAP application follows the same development pattern:
End-to-End RAP Development Flow
- Database Table (TABL)
- CDS View Entity (DDLS)
- Behavior Definition (BDEF)
- Behavior Implementation (CLAS)
- Projection View (DDLS)
- Projection Behavior (BDEF)
- Service Definition (SRVD)
- Service Binding (SRVB)
- Fiori Elements / SAPUI5 Application
define table zemployee {
key client : abap.clnt not null;
key employee_id : abap.numc(10) not null;
employee_name : abap.char(80);
department : abap.char(40);
}Purpose of Database Table
define root view entity ZI_EMPLOYEE
as select from zemployee
{
key employee_id,
employee_name,
department
}Purpose of CDS View Entity
managed implementation in class zbp_i_employee unique;
define behavior for ZI_EMPLOYEE
persistent table zemployee
lock master
authorization master ( instance )
{
create;
update;
delete;
}Purpose of Behavior Definition
CLASS lhc_employee DEFINITION
INHERITING FROM cl_abap_behavior_handler.
PRIVATE SECTION.
METHODS validateDepartment
FOR VALIDATE ON SAVE
IMPORTING keys.
ENDCLASS.Purpose of Behavior Implementation
define root view entity ZC_EMPLOYEE
provider contract transactional_query
as projection on ZI_EMPLOYEE
{
key employee_id,
employee_name,
department
}Purpose of Projection View
projection;
define behavior for ZC_EMPLOYEE
{
use create;
use update;
use delete;
}Purpose of Projection Behavior
define service ZUI_EMPLOYEE {
expose ZC_EMPLOYEE
as Employee;
}Purpose of Service Definition
Name : ZUI_EMPLOYEE_O4
Binding Type : OData V4 - UI
Service : ZUI_EMPLOYEEPurpose of Service Binding
RAP Artifact Summary
| Artifact | Repository Type | Purpose |
|---|---|---|
| Database Table | TABL | Persistence Layer |
| CDS View Entity | DDLS | Data Model |
| Behavior Definition | BDEF | Business Behavior |
| Behavior Implementation | CLAS | Custom Logic |
| Projection View | DDLS | Consumer Model |
| Projection Behavior | BDEF | Expose Operations |
| Service Definition | SRVD | Expose Service |
| Service Binding | SRVB | Publish OData Service |
Read-Only vs Transactional Applications
One of the most important architectural decisions in RAP is determining whether the application is Read-Only or Transactional. This decision impacts the number of RAP artifacts required, the complexity of the solution, performance, maintainability and long-term extensibility.
According to SAP's ABAP Cloud development model, RAP supports both analytical and transactional use cases. Not every application requires create, update or delete capabilities. In many enterprise scenarios, users only need to consume and analyze business data.
A common mistake among beginners is assuming that every RAP application requires a Behavior Definition and Behavior Implementation. In reality, many successful RAP applications are implemented as read-only solutions using only CDS views, projections and service exposure.
Architect Perspective
- Will users create new business records?
- Will users modify existing data?
- Will users execute business actions such as Approve or Reject?
- Are validations and determinations required?
- Is there a business transaction lifecycle?
If the answer to all these questions is No, a Read-Only RAP application is often sufficient.
Real Project Example: Example 1: Purchase Order Analytics Dashboard (Read-Only RAP)
Consider a dashboard displaying Purchase Orders by Purchasing Organization, Supplier and Net Order Value.
Users only need to analyze information. They do not create or modify Purchase Orders from this application.
In this scenario, SAP recommends using CDS View Entities, Projection Views, Service Definitions and Service Bindings without any Behavior Definition.
Real Project Example: Example 2: CAPA Management Application (Transactional RAP)
Consider a CAPA (Corrective and Preventive Action) application where users create CAPA records, assign root causes, perform corrective actions, approve investigations and finally close the CAPA.
This application contains business transactions, lifecycle management, validations, approvals and status changes.
Such a solution requires a complete RAP Business Object with Behavior Definitions, Actions, Determinations, Validations and Service Exposure.
SAP ABAP Cloud Perspective
- Analytical Use Cases (OLAP) – Reporting, dashboards, KPIs and embedded analytics.
- Transactional Use Cases (OLTP) – Business applications that create, update and process business data.
RAP is the strategic programming model for implementing transactional business applications in ABAP Cloud.
Architect Perspective
From an architecture standpoint, every Transactional RAP application is built on top of a Read-Only foundation.
The CDS data model remains the same. Transactional RAP simply adds behavior, validations, determinations, actions, draft handling, authorization control and transactional consistency.
This is why SAP often describes Transactional RAP as an extension of the Read-Only model rather than a completely separate architecture.
Business Objects, Associations and Compositions
The most important concept in RAP is the Business Object (BO). RAP is not table-centric like traditional ABAP development. Instead, RAP is designed around business concepts such as Purchase Orders, Sales Orders, Employees, Suppliers, CAPA Records and Service Requests.
A Business Object represents a complete business entity together with its data, relationships, lifecycle, business rules and transactional behavior. In RAP, everything revolves around the Business Object.
From an architectural perspective, a Business Object acts as a consistency boundary. All business validations, authorizations, determinations, actions and transactional processing are executed through the Business Object.
Common SAP Business Objects
- Purchase Order
- Sales Order
- Business Partner
- Supplier
- Employee
- Material
- CAPA Record
- Service Request
Real Project Example: Purchase Order Business Object
Consider a Purchase Order in SAP S/4HANA.
A Purchase Order is not just a single database table. It consists of a Purchase Order Header, Purchase Order Items, Schedule Lines, Account Assignments and Supplier information.
RAP groups these related entities into a single Business Object so that the framework can guarantee transactional consistency and business integrity.
Root Entity and Child Entities
Every RAP Business Object starts with a Root Entity. The root entity acts as the entry point into the Business Object and controls lifecycle management, locking, authorization and transactional consistency.
Additional entities are typically modeled as child entities that are connected to the root using compositions.
Architect Perspective
Association vs Composition
One of the most frequently asked RAP interview topics is the difference between Associations and Compositions.
Although both represent relationships between entities, they model very different business semantics.
Association
Associations represent a loose relationship between two independent business objects.
- Objects can exist independently.
- Lifecycle is not shared.
- Deleting one object does not delete the other.
- Used mainly for navigation and lookups.
Example: Purchase Order → Business Partner
Composition
Composition represents strong ownership between entities.
- Child lifecycle depends on the parent.
- Parent owns the child data.
- Deletion of parent removes child records.
- Forms a single transactional unit.
Example: Purchase Order → Purchase Order Items
Real Project Example: Association vs Composition in SAP Projects
A Purchase Order Item cannot exist without a Purchase Order Header. Therefore the relationship is modeled using a Composition.
However, the Supplier associated with the Purchase Order is an independent Business Object that exists regardless of whether the Purchase Order exists. Therefore this relationship is modeled using an Association.
Architect Perspective
A good RAP data model is primarily about identifying Business Object boundaries correctly.
Most design mistakes in RAP originate from incorrectly identifying ownership relationships and choosing Associations where Compositions should be used, or vice versa.
Before writing any CDS code, architects should first identify:
- Root Entity
- Child Entities
- Ownership Boundaries
- Transaction Boundaries
- Business Lifecycle
Managed vs Unmanaged RAP
One of the most important implementation decisions in RAP is whether a Business Object should use the Managed or Unmanaged programming model.
This decision affects development effort, maintainability, cloud readiness, upgrade stability and long-term ownership of the solution.
SAP strongly recommends Managed RAP for new developments because the RAP framework automatically handles persistence, transactional consistency, locking, authorization and save processing.
Managed RAP - SAP Recommended Approach
Managed RAP is designed for greenfield application development and is the preferred approach in ABAP Cloud and SAP S/4HANA Public Cloud.
- Framework automatically handles CRUD operations.
- No manual database persistence coding required.
- Supports Clean Core principles.
- Reduced development effort.
- Better maintainability and upgrade stability.
- Ideal for new custom applications.
Real Project Example: Managed RAP Example - Employee Management
Consider a new Employee Management application being developed in SAP S/4HANA Public Cloud.
The application stores employee master data in custom persistence tables and follows standard create, update and delete operations.
In this scenario, Managed RAP is the ideal choice because the framework automatically handles persistence and transactional processing.
Unmanaged RAP - Legacy Integration Approach
Unmanaged RAP is primarily intended for brownfield scenarios where existing business logic already exists and cannot be replaced easily.
- Developer controls persistence logic.
- Existing BAPIs can be reused.
- Legacy function modules can be integrated.
- Custom save logic can be preserved.
- Higher implementation complexity.
- More code ownership for the development team.
Real Project Example: Unmanaged RAP Example - Sales Order Processing
Consider a customer with an existing Sales Order solution built over many years using custom classes, BAPIs and enhancement frameworks.
Rewriting all existing business logic into Managed RAP may be expensive and risky.
In such situations, Unmanaged RAP can expose the existing logic through a modern RAP service layer while preserving proven business processes.
How SAP Views Managed and Unmanaged RAP
SAP does not position Managed and Unmanaged RAP as competing approaches. Instead, they solve different business problems.
Managed RAP is intended for new development scenarios, while Unmanaged RAP provides a migration path for existing investments and legacy applications.
Architect Perspective
The most common architecture mistake is choosing Unmanaged RAP simply because developers are familiar with traditional ABAP coding.
For new ABAP Cloud developments, Managed RAP should always be the default choice unless a clear business requirement forces reuse of existing persistence logic.
Every unnecessary Unmanaged implementation increases development effort, testing effort and long-term maintenance costs.
Decision Framework for Architects
- Building a completely new application? Choose Managed RAP.
- Working in SAP S/4HANA Public Cloud? Choose Managed RAP.
- Need to reuse existing BAPIs? Consider Unmanaged RAP.
- Existing legacy persistence logic must remain unchanged? Consider Unmanaged RAP.
- Want lowest maintenance effort? Choose Managed RAP.
How RAP Runtime Works
Many developers learn how to create CDS Views, Behavior Definitions and Service Bindings, but very few understand what actually happens when a user clicks the Save button in a RAP application.
Understanding the RAP Runtime is important because it explains how SAP transforms a simple user action into a fully managed business transaction while ensuring consistency, authorization, validation and performance.
From a technical perspective, RAP Runtime acts as the orchestration layer between the UI, OData services, Business Objects and the SAP HANA database.
What Happens When a User Clicks Save?
- User submits data from a Fiori application.
- OData request is sent to SAP Gateway.
- SAP Gateway routes the request.
- SADL interprets the CDS model.
- RAP Runtime executes business behavior.
- Validations and determinations run.
- Transaction Manager coordinates persistence.
- Changes are committed to SAP HANA.
Step 1 - Fiori Application
Every RAP request normally starts from a SAP Fiori Elements or SAPUI5 application.
The UI never directly accesses database tables. Instead, it consumes an OData service exposed through RAP.
This separation between UI and backend is one of the foundations of SAP's Clean Core strategy.
Step 2 - OData Service and SAP Gateway
The request reaches SAP Gateway through an OData endpoint generated from the Service Binding.
SAP Gateway acts as the communication layer between external consumers and RAP Business Objects.
Think Like an Architect
Step 3 - SADL Processing
SADL (Service Adaptation Definition Language) is one of the most important runtime components in RAP.
SADL automatically translates OData requests into CDS-based operations and generates optimized database access logic.
Responsibilities of SADL
- Process OData requests
- Resolve CDS associations
- Handle filtering and sorting
- Optimize database access
- Generate SQL for SAP HANA
- Reduce custom coding requirements
Real Project Example: Example: Supplier Search
Suppose a user searches for suppliers beginning with "ABC".
The filter is sent through OData, interpreted by SADL and pushed down to SAP HANA. Only the required records are returned.
This is one of the reasons RAP applications scale better than traditional report-based developments.
Step 4 - RAP Business Object Runtime
After SADL resolves the request, the RAP Runtime takes over.
The RAP Runtime is responsible for executing Business Object behavior defined in Behavior Definitions and Behavior Implementations.
Responsibilities of RAP Runtime
- Execute Create, Update and Delete operations
- Run Validations
- Run Determinations
- Execute Actions
- Handle Draft Processing
- Perform Authorization Checks
- Coordinate Save Processing
Step 5 - RAP Transaction Manager
The RAP Transaction Manager ensures consistency across the entire Business Object.
Multiple entities may participate in the same transaction. Either all changes are saved successfully or all changes are rolled back.
Real Project Example: Purchase Order Example
Consider a Purchase Order containing one Header and ten Items.
If saving Item 7 fails due to a validation error, the entire Purchase Order transaction is rolled back.
This guarantees data consistency across the Business Object.
The RAP Save Sequence
One of the most important architect-level concepts in RAP is the Save Sequence.
During save processing, RAP executes a predefined sequence of steps to ensure business consistency.
Typical RAP Save Sequence
- Authorization Checks
- Prechecks
- Validations
- Determinations
- Action Processing
- Persistence Processing
- Database Commit
Read Requests vs Modify Requests
Not every request travels through the complete runtime.
Read operations are relatively lightweight and usually stop after SADL generates the required database query.
Modify operations are more complex because they involve business behavior, validations, determinations and transactional consistency.
Architect Perspective
Understanding RAP Runtime is often the difference between a RAP developer and a RAP architect.
Architects must understand how Gateway, OData, SADL, RAP Runtime, Transaction Manager and SAP HANA interact because performance, scalability and troubleshooting depend on this knowledge.
When analyzing performance issues, authorization failures, unexpected validations or save sequence behavior, the answer is usually found somewhere within the RAP Runtime flow.
Clean Core, Released APIs and the Future of ABAP Development
One of the biggest shifts from Classical ABAP development to ABAP Cloud development is SAP's move toward the Clean Core strategy.
In the past, developers could directly access SAP database tables, call unreleased function modules, use implicit enhancements and even modify SAP standard code. While this provided flexibility, it created significant challenges during upgrades because custom code became tightly coupled to SAP internals.
ABAP Cloud introduces a clear contract between SAP standard software and customer extensions. This contract is enforced through Released APIs, Released Extension Points and the ABAP Language Version ABAP for Cloud Development.
What is Clean Core?
Clean Core means keeping SAP standard software untouched while extending it only through officially released APIs and extension points.
The goal is to make custom developments upgrade-safe, cloud-ready, scalable and compatible with future SAP innovations.
Clean Core is not just a recommendation. It is the foundation of SAP S/4HANA Public Cloud and ABAP Cloud development.
Real Project Example: Classical ABAP vs Clean Core
In traditional ECC systems developers frequently used:
- Direct SELECT from MARA
- Calls to unreleased Function Modules
- Implicit Enhancements
- Modifications of SAP Standard Programs
- Direct Updates to SAP Tables
In ABAP Cloud these approaches are forbidden because SAP cannot guarantee upgrade stability when custom code depends on SAP internals.
Released APIs - The New Contract with SAP
SAP now exposes business data and functionality through Released APIs.
Released APIs form the official public interface between SAP standard software and customer developments.
SAP guarantees lifecycle stability for released APIs while retaining the freedom to change internal implementation details.
Examples of Released APIs
- Released CDS Views (I_* views)
- Released ABAP Classes
- Released Interfaces
- Released RAP Business Objects
- Released OData APIs
- Released BAdIs and Extension Points
SELECT *
FROM I_Product
INTO TABLE @DATA(lt_product).SELECT *
FROM MARA
INTO TABLE @DATA(lt_mara).Architect Perspective
Notice that both statements may technically return Material data.
However, I_Product is a released public API whereas MARA is an internal SAP implementation table. SAP may change MARA at any time without impacting customers using the released CDS View.
ABAP Language Version and Enforcement
The Clean Core strategy is enforced technically through the ABAP Language Version ABAP for Cloud Development.
This language version performs syntax checks and release checks during development and activation.
If a developer attempts to use a non-released SAP object, activation fails immediately.
Typical Syntax Errors in ABAP Cloud
- Direct SELECT from SAP tables such as MARA
- CALL SCREEN
- Classic Dynpro Programming
- Web Dynpro ABAP Development
- EXEC SQL
- OPEN DATASET
- SYSTEM-CALL
- SELECT CLIENT SPECIFIED
- Calls to unreleased SAP Function Modules
What is Allowed in ABAP Cloud?
- RAP Applications
- CDS View Entities
- Released CDS Views
- Released ABAP Classes
- Released APIs from SAP
- Custom Database Tables
- ABAP OO Development
- Background Jobs through released APIs
- Application Logging APIs
- Business Events
- OData Service Consumption
What is NOT Allowed in ABAP Cloud?
- Modifications of SAP Standard Objects
- Implicit Enhancements
- Direct Access to SAP Internal Tables
- Unreleased Function Modules
- Classic Dynpro Screens
- CALL SCREEN
- Direct Database Access Bypassing Released APIs
- EXEC SQL
- File System Access via OPEN DATASET
- Native Database Programming
Real Project Example: The Famous MARA Example
A classic ABAP developer might write:
SELECT * FROM mara INTO TABLE @DATA(lt_mara).In ABAP Cloud this causes a syntax error because MARA is not released.
The correct approach is:
SELECT *
FROM I_Product
INTO TABLE @DATA(lt_product).The Three-Tier Extensibility Model
SAP introduced the Three-Tier Model to help customers gradually move toward Clean Core.
Tier 1 - ABAP Cloud
Tier 2 - Wrapper Layer
Tier 3 - Classical ABAP
Architect Perspective
SAP's long-term strategy is to move custom developments from Tier 3 to Tier 1. Every new development should ideally start directly in Tier 1.
Architects should treat Tier 2 as a temporary migration layer rather than a permanent architecture.
RAP Fundamentals Interview Questions
RAP Fundamentals
Why did SAP introduce RAP when Gateway and BOPF already existed?
Answer: SAP required a unified cloud-ready programming model that combines data modeling, transactional behavior, service exposure and Clean Core principles within a single framework.
Why is RAP considered the future of ABAP development?
Answer: Because RAP combines CDS, business behavior, service exposure, draft handling, authorization, OData integration and cloud compliance into a single standardized framework aligned with SAP's Clean Core strategy.
Why should architects care about RAP?
Answer: RAP is not just a development framework. It is SAP's strategic architecture for cloud-ready applications and is foundational to ABAP Cloud, Clean Core and future S/4HANA extensibility.
What is the relationship between RAP and ABAP Cloud?
Answer: ABAP Cloud is the overall development model. RAP is the transactional application framework within ABAP Cloud used to implement Business Objects and services.
Why does RAP separate the Interaction Phase from the Save Sequence?
Answer: The separation allows RAP to execute business logic, validations and determinations in memory before performing a single controlled database transaction. This improves performance, supports Draft Handling and ensures transactional consistency.
Business Objects & Data Modeling
Why is RAP considered a Business Object-centric framework?
Answer: RAP models business processes around Business Objects instead of database tables, enabling lifecycle management, transactional consistency and reusable business behavior.
Can every Transactional RAP application be converted into a Read-Only application?
Answer: Yes. Transactional RAP is essentially a Read-Only RAP application with additional behavior and lifecycle management. Removing behavior artifacts leaves the underlying analytical model intact.
How do you decide whether to use an Association or a Composition?
Answer: If the child entity depends on the parent for its lifecycle and business existence, use Composition. If both entities can exist independently, use Association.
What is the difference between a BAPI call and EML?
Answer: BAPIs expose procedural operations while EML operates directly on RAP Business Objects and automatically respects RAP transactional behavior, validations, determinations and authorizations.
Managed vs Unmanaged RAP
Why does SAP recommend Managed RAP for new developments?
Answer: Managed RAP reduces custom code, automatically handles persistence and transactional processing, aligns with Clean Core principles and provides better upgrade stability in ABAP Cloud environments.
When would you intentionally choose Unmanaged RAP?
Answer: When significant business logic already exists in BAPIs, function modules or legacy frameworks and rewriting that logic would be expensive or risky.
RAP Runtime & Processing
What happens internally when a user clicks Save in a RAP application?
Answer: The request flows through OData, SAP Gateway, SADL and the RAP Runtime. Validations, determinations, actions and authorization checks are executed before the Transaction Manager commits changes to SAP HANA.
What is the role of SADL in RAP?
Answer: SADL translates service requests into CDS operations, optimizes database access and generates efficient SAP HANA queries.
Clean Core & ABAP Cloud
Why is direct access to MARA forbidden in ABAP Cloud?
Answer: Because MARA is an internal SAP implementation table and not a released API. SAP only guarantees lifecycle stability for released APIs such as I_Product.
What are the two main objectives of the ABAP Language Version?
Answer: Protect system integrity through restricted syntax and enforce Clean Core by allowing access only to released APIs.
What is the difference between Tier 1 and Tier 2 in SAP's Three-Tier Model?
Answer: Tier 1 uses only released APIs and is fully cloud compliant. Tier 2 encapsulates non-released APIs behind custom wrappers to support gradual modernization.