CDS & OData for Developers: A Learning Path

If you are an ABAP developer, CDS and OData are no longer optional vocabulary — they are the baseline. CDS is where you model data in modern ABAP, and OData is how that model reaches a Fiori app or an external system. Together with RAP, they are the core of ABAP Cloud and the clean-core way of building. This guide is a concept-first orientation with a learning path, not a code tutorial: enough to understand what each piece is, how they fit, and the order to learn them in.

The one-sentence version

You model business data as a CDS view, you expose it as an OData service, and a Fiori app or API consumes it. Everything else is detail on top of that spine.

What CDS actually is

Core Data Services is a way to define data models using a SQL-like DDL syntax, written in the ABAP Development Tools (ADT) in Eclipse rather than in SE80. The reason it matters is not the syntax but two properties classic reports never had. First, pushdown: CDS moves data-intensive work down to the HANA database layer instead of pulling rows up into the application server and looping, which is often the single biggest performance win available. Second, reusability with meaning: a CDS view is a standalone, named object that any program, OData service or other view can reference, and it carries annotations that Fiori, analytics and API frameworks understand automatically. A classic report encapsulates logic that cannot be reused; a CDS view is a building block that can.

This is why CDS is now described as a baseline competency: the entire virtual data model in S/4HANA — thousands of SAP-delivered views — is built this way, and your own work sits alongside it.

What OData adds

A CDS view models the data; it does not, by itself, make it reachable from a browser or another system. OData is the protocol that does. When you expose a CDS view as an OData service, a Fiori app can read and (with RAP) write to it, and external systems can call it as an API. There are two versions in play — V2 and the newer V4 — and modern RAP-based development targets V4. The practical point for a learner: you rarely hand-build the plumbing anymore. You model the CDS view correctly, and the framework generates the service.

Where RAP fits

RAP — the ABAP RESTful Application Programming Model — is the framework that ties it together for transactional apps. Its own structure tells you what to learn: CDS views for the data model, a behavior definition for what create, update and delete are allowed to do, a behavior implementation where the actual ABAP logic lives, and a service definition and binding that expose the whole thing as OData. The framework handles the boilerplate — the OData protocol, buffering, transaction handling — so you write business logic, not plumbing. SAP calls business services the most future-proof option, and RAP is where SAP is investing.

A six-month learning path

This mirrors the path SAP practitioners actually recommend, and each phase ends with something that works.

Months 1–2 — foundations. Get ADT (Eclipse) working against a system or a BTP trial. Refresh modern ABAP syntax and object orientation; refactor one classic report into clean OO as a warm-up. The goal is to be comfortable in the modern toolchain, because none of the rest happens in SE80.

Month 3 — CDS proper. Build several CDS views of different types. Learn associations (how views relate), calculated fields, and the annotations that drive UI and OData exposure. Convert one loop-heavy classic report to a pushdown CDS approach and measure the before and after — that measurement is the moment it clicks.

Month 4 — OData exposure. Expose your CDS views as OData services and test them. Inspect the metadata and run create/read/update/delete against a tool like the SAP Gateway client or Postman. The skill here is confidence that the service does what you think it does.

Month 5 — RAP fundamentals. Build one managed business object end to end: CDS root and projection views, a behavior definition with validations, and a Fiori Elements UI on top. Even read-only, seeing the list report appear from your own model is the milestone. Then add draft support and full CRUD.

Month 6 — clean-core practice. Package it properly, add tests, and make sure everything uses released APIs rather than internal objects — run the ATC clean-core and ABAP Cloud readiness checks against your own code. Finish with a small mini-project that ties model, service and UI together.

The honest framing

The test SAP practitioners use to know you have arrived is simple: can you create a CDS consumption view and expose it as an OData service? If yes, you can build the modern equivalent of most of what you used to write. What changed is not that ABAP died — classic ABAP is still used, especially in maintenance — but that the value moved from writing procedural code to modeling data well and letting the framework generate the rest. The scarce skill is judgment: knowing what to model, what to reuse from the thousands of delivered views, and whether the generated result is correct and upgrade-safe. That is the same shift happening everywhere in SAP, expressed in code.

Sources & further reading

• SAP Community — ABAP RESTful Application Programming Model (RAP)SAP's own hub: RAP as the heart of ABAP Cloud, built on CDS and exposed as OData. Verified live.
• SAP Learning — OData services based on CDS viewsHow CDS views become OData services, and why business services (RAP) are the future-proof route. Verified live.
• SAP Help — ABAP CloudThe released-API model and ATC readiness checks referenced in the path. [Verify link.]

Syntax, app availability and released-object scope vary by release and edition. Verify against SAP Help and the Fiori apps reference library for yours. This article is independent commentary and is not affiliated with SAP.