ABAP RAP — What It Is, What It Replaces, and Why It Matters

At some point in the last few years, someone told you to use RAP. Maybe it was a SAP note, a project architect, or a job posting that listed ‘RAP experience required’. And if you came up through SEGW-based OData development, your first reaction was probably: why is SAP replacing something that already works?

That question is fair. The SEGW gateway framework did work — for a long time, for a lot of projects. But it had a problem: it was not built for the cloud. As SAP moved toward S/4HANA Cloud, BTP, and the clean core principle, SEGW became the thing holding development back. RAP is SAP’s answer to that.

This post explains what RAP actually is, what it replaces, and what the managed versus unmanaged choice means in practice. No boilerplate syntax. Just the mental model.

🔗 Foundation posts

RAP builds on two concepts covered elsewhere on this site:
CDS Views and the VDM in SAP S/4HANA Explained The data layer that sits beneath every RAP business object. Worth reading first if CDS is new to you.
OData Protocol in SAP — V2, V4 and How It Works RAP is how you expose OData services the modern way. Both are worth reading first if you are new to either concept.

The problem RAP was built to solve

Building an OData service in the old world meant working through the SAP Gateway framework — transaction SEGW, manual Model Provider Class (MPC) and Data Provider Class (DPC) code, separate registration steps, and a layer of boilerplate that nobody genuinely enjoyed writing. Every service was a custom construction job.

That was manageable in an on-premise world where you controlled the release cycle. It became a liability in the cloud. SAP S/4HANA Cloud requires upgrade safety — code that survives automated updates without manual remediation. SEGW services, with their direct database access and undisciplined class hierarchies, could not make that guarantee.

There was also a capability gap. SEGW had no native draft handling, no standardised locking, no out-of-the-box support for deep entity structures. You built all of that yourself. Every project, every time.

📌 Key Takeaway

RAP was not built to be a better way to write code. It was built to make ABAP development upgrade-safe, cloud-ready, and standardised — with the framework handling what every developer was previously writing manually.

What RAP actually is

RAP — the ABAP RESTful Application Programming Model — is SAP’s strategic programming model for building transactional OData services and Fiori applications on S/4HANA and BTP. It has been available on-premise since S/4HANA release 1909 (September 2019) and on the BTP ABAP Environment (Steampunk) since its initial release in 2018.

Every RAP application is built from the same three-layer structure. The layers are distinct. Each one has a specific job.

Layer	What it does
CDS Data Model	Defines the business object structure using Core Data Services views — the entities, their relationships, and the semantic annotations that drive UI behaviour. This is the foundation everything else sits on.
Behaviour Definition (BDL)	Declares what operations are allowed on the business object — create, update, delete, custom actions — and specifies who handles them: the RAP framework (managed) or the developer (unmanaged). Written in Behaviour Definition Language, a dedicated syntax.
Service Definition + Service Binding	Exposes the CDS entities as an OData service and binds it to a protocol — OData V2 or V4 — and a use case (UI or Web API). This replaces the SEGW registration step.

The discipline RAP enforces is separation of concerns. The data model, the business logic, and the service exposure are three different artefacts. In SEGW, they were tangled together inside the DPC class. In RAP, each layer is explicit, testable, and independently maintainable.

💡 Practical Tip

ABAP Development Tools (ADT) in Eclipse is the required development environment for RAP. The ABAP Workbench (SE80) cannot create RAP objects. If your team has not moved to ADT yet, that is the first step — not the most exciting one, but a non-negotiable prerequisite.

Managed vs unmanaged — the choice that matters most

When you define a RAP business object, you make one foundational decision: who handles the CRUD operations and the transactional buffer? The RAP framework — or you?

That choice gives you two implementation types: managed and unmanaged. Getting this decision right saves significant development time. Getting it wrong is expensive to undo.

	Managed	Unmanaged
Who handles CRUD	The RAP framework — automatically	The developer — fully custom ABAP classes
Transactional buffer	Managed by the framework	Developer implements a singleton/static class
Draft handling	Built in — zero additional code	Must be implemented manually
Best for	Greenfield — new tables, new objects, no legacy dependencies	Brownfield — wrapping BAPIs, function modules, or existing persistence
Effort	Low — focus only on business logic	High — full control, full responsibility

The SAP community guidance is consistent: start with managed unless you have a concrete reason not to. Unmanaged RAP is powerful — but every mistake in the transaction handling becomes a production issue. It is not a last resort, but it should be a deliberate choice, not a default.

💡 Practical Tip

There is a third option worth knowing: Managed with Unmanaged Save. The framework handles all the interaction logic and transactional buffer, but you write the save sequence yourself — useful when you need to call existing BAPIs or function modules at the point of persistence. SAP Community consensus consistently points to this as the best of both worlds for brownfield scenarios.

⚠️ Warning

You cannot use a BAPI that issues a COMMIT WORK inside the RAP save sequence. The RAP LUW (Logical Unit of Work) controls commit and rollback. If your existing BAPI commits internally, you need to wrap it — and release the wrapper with C1 to maintain cloud compatibility.

What RAP replaces — and what it does not

RAP is SAP’s stated replacement for SEGW-based OData development going forward. That means: no more transaction SEGW, no more manual MPC and DPC classes, no more separate gateway registration. The entire artefact set is different.

Old approach (SEGW)	RAP equivalent
Transaction SEGW — service definition	CDS View + Service Definition + Service Binding
Model Provider Class (MPC)	CDS data model with annotations
Data Provider Class (DPC) — business logic	Behaviour Implementation class (ABAP for CLOUD)
Manual OData registration in /IWFND/MAINT_SERVICE	Service Binding activation — handled in ADT
BOPF (Business Object Processing Framework)	RAP managed provider — supersedes BOPF for new development

What RAP does not replace: existing SEGW services in productive systems. Nobody is rewriting working OData services just because RAP exists. The practical picture in most S/4HANA landscapes in 2026 is a mix — legacy SEGW services running untouched, new development in RAP. That is expected and supported.

📝 Note

RAP is mandatory for SAP S/4HANA Cloud Public Edition. On-premise S/4HANA and Private Cloud Edition support both RAP and SEGW. If your organisation is moving to Public Cloud, RAP is not optional — it is the only supported development model.

The clean core connection is direct. SAP’s clean core strategy — formalised with the A–D maturity model in August 2025 — defines upgrade-safe extensibility as the target state. RAP, combined with released CDS APIs and ABAP Cloud restrictions, is how you build at Level A or B on that scale. SEGW-based extensions with direct table access sit at Level D.

🔗 Related reading

The clean core principle connects directly to the S/4HANA migration conversation.
Read: SAP S/4HANA vs ECC — The Real Difference Covers what actually changes in the development model when you move from ECC to S/4HANA.

RAP and the broader SAP stack

RAP does not exist in isolation. It is the transactional layer in a wider development model, and understanding where it connects to the rest of the stack saves a lot of confusion on projects.

CDS Views

RAP business objects are built on CDS views — specifically CDS entities defined as root views with composition associations for parent-child structures. The CDS views you define for RAP are not the same as the analytical CDS views used in reporting. They carry behaviour annotations and are exposed through the service binding, not consumed directly by SQL queries.

If CDS views are new to you, read the CDS post on this site first. RAP without CDS is not possible — the data model is the foundation, not an optional layer.

Fiori Elements

RAP is the backend model that Fiori Elements apps are built on. The annotations you add to your CDS views — @UI.lineItem, @UI.facet, @UI.selectionField — drive the Fiori Elements UI directly. No custom SAPUI5 code required for standard patterns. RAP and Fiori Elements were designed together, and that relationship is intentional.

SAP BTP ABAP Environment

On BTP, RAP is the only supported model for building transactional applications. The BTP ABAP Environment (Steampunk) enforces ABAP Cloud restrictions — no direct access to SAP standard database tables, no classic ABAP OO patterns that bypass the released API surface. RAP is built for exactly that environment.

✅ Best Practice

If you are building on SAP BTP ABAP Environment, use RAP managed implementation and released CDS APIs only. Direct SELECT on SAP-owned tables is blocked at runtime in that environment — not a guideline, a hard restriction.

At a glance — ABAP RAP essentials

Concept	One-line summary
ABAP RAP	SAP’s strategic programming model for building transactional OData services and Fiori apps on S/4HANA and BTP — available on-premise from release 1909
CDS Data Model	The foundation layer — defines business object structure, relationships and UI annotations using Core Data Services entities
Behaviour Definition (BDL)	Declares what operations are allowed and who handles them — the RAP framework or the developer
Service Binding	Exposes the business object as an OData V2 or V4 service — replaces SEGW registration
Managed RAP	Framework handles CRUD, transactional buffer and draft handling — use for greenfield development on new tables
Unmanaged RAP	Developer implements all CRUD and buffer logic — use when wrapping legacy BAPIs or requiring full custom control
Managed with Unmanaged Save	Framework handles the interaction phase; developer writes the save sequence — recommended hybrid for brownfield scenarios with BAPIs
SEGW replacement	RAP replaces transaction SEGW, MPC/DPC classes and manual gateway registration for all new development
Clean Core connection	RAP + released CDS APIs is how you build at Levels A and B in SAP’s clean core maturity model — SEGW with direct table access is Level D
ADT requirement	ABAP Development Tools in Eclipse is required for RAP development — the ABAP Workbench cannot create RAP objects

What to take away

RAP is not a stylistic preference. It is the direction SAP has staked the ABAP platform on — and the evidence is in the restrictions, not just the documentation. BTP ABAP Environment blocks non-RAP transactional patterns at runtime. S/4HANA Cloud Public Edition mandates it. The clean core maturity model scores SEGW extensions at the bottom of the scale.

The mental model shift is this: in the old world, you controlled the plumbing — MPC, DPC, transaction buffer, locking, everything. In RAP, you declare intent and the framework handles the plumbing. Your job is business logic, not infrastructure. For greenfield development, that is a significant reduction in both code volume and risk.

The honest caveat: most SAP landscapes in 2026 are not greenfield. They are full of existing SEGW services, BOPF objects, and Z-tables that nobody is rewriting. RAP is where new development goes. Existing investments stay where they are, maintained but not migrated for the sake of it. Know the model, know where it applies — and apply it deliberately.

🔗 Related posts on this site

CDS Views and the VDM in SAP S/4HANA Explained The data model layer that sits beneath every RAP business object. Essential prerequisite.
OData Protocol in SAP — V2, V4 and How It Works RAP exposes OData services; this post explains the protocol those services use.
SAP S/4HANA vs ECC — The Real Difference The broader picture of what changes in the development model when you move from ECC.
ABAP Fundamentals That Still Matter The ABAP foundation that RAP builds on — what still applies and what has changed.
SAP BTP — The Platform Explained The BTP ABAP Environment is where RAP is mandatory; this post explains the platform.

Published on rakeshnarayan.com — Articles

https://rakeshnarayan.com/articles/abap-rap-what-it-is-what-it-replaces-and-why-it-matters/