Step 2 of 4 Intermediate 10 min

RAP in One Picture: The Layer Stack That Replaced BOPF

Lesson 2 — BOPF took a small army of artefacts to build one business object. RAP does the same job with a fraction of the boilerplate. Here's the whole stack, top to bottom, in one diagram instead of a week of documentation.

S
s4ready.ai Team

Prerequisites

  • Lesson 1: Why your IDE choice is a Clean Core decision

If you’ve written a classical ABAP Objects business object with manual locking and a hand-rolled BAPI surface, you already know the tax: a small army of artefacts for even a modest piece of transactional logic. RAP replaces that entire pattern, and the fastest way to actually understand it is one picture, not a week of scattered documentation.

The stack, top to bottom

The RAP layer stack, Fiori UI to databaseFrom top to bottom: Fiori Elements UI, auto-generated from annotations. OData V4 service binding. Service definition. Behavior definition, a dot-bdef file. Behavior implementation class, where you write ABAP. CDS projection view, with aliases and annotations. CDS interface view, the data model and joins. Database tables or released CDS views at the bottom. The developer writes ABAP only in the behavior implementation class — everything else is generated or declared.Fiori Elements UI — auto-generatedOData V4 Service Binding (SRVB)Service Definition (SRVD)Behavior Definition (.bdef)Behavior Implementation Class — YOU WRITE ABAP HERECDS Projection View — alias, annotationsCDS Interface View — data model, joins
One layer — the behavior implementation class — is where you write ABAP. Every other layer is generated or declared.

Why “less boilerplate” isn’t the whole story

The real shift isn’t just less code — it’s where the remaining code lives. In BOPF, business logic could end up scattered across the framework’s own extension points, hard to trace. In RAP, all of your custom logic concentrates in exactly one place: the behavior implementation class. Everything else — the OData exposure, the Fiori UI, the CDS data model — is generated or declared, not hand-written and not somewhere you’d go hunting for a bug.

Try it yourself

Pick one classical ABAP Objects business object you know, even roughly. Map its actual logic onto this stack: which part would become a CDS projection, which part the behavior definition, and which part is genuinely custom enough that it belongs in the behavior implementation class? If most of it maps cleanly onto the generated layers, that’s a strong signal the object is a good RAP migration candidate.

Go deeper

For managed versus unmanaged scenarios, draft handling, and when CAP is the better choice instead of RAP, read SAP RAP: The ABAP RESTful Application Programming Model in Practice.

Key takeaways

  • RAP’s stack runs Fiori UI → OData service → CDS projection → behavior definition → behavior implementation → CDS interface → database — and you write ABAP in exactly one of those layers.
  • The win isn’t just less code — it’s that custom logic concentrates in one traceable place instead of scattering across framework extension points.
  • A good RAP candidate is an object where most of the logic maps cleanly onto the generated layers, leaving only genuine business rules for the implementation class.

Next: your transports track what moved where. They were never actually version control — here’s what abapGit adds that transports structurally can’t.

← Why Your IDE Choice Is a Clean Core Decision abapGit: Why Your Transports Aren't Version Control →