What is SAP CAP?

SAP CAP — the Cloud Application Programming Model — is SAP's framework for building cloud-native enterprise applications on the SAP Business Technology Platform (BTP). When people ask what is SAP CAP, the one-line answer is: a set of languages, libraries, and conventions that let you model your data and services declaratively in CDS, get OData APIs and persistence for free, and then add custom logic only where you need it.

CAP is not a single product or runtime. It is a programming model backed by two runtimes — Node.js (@sap/cds) and Java (cds-services) — plus a growing set of reusable packages under the @cap-js/* namespace. The official documentation is called Capire, and it is comprehensive enough that the Capire-backed skill is one of the most-used in this catalog.

CAP vs RAP vs Classic ABAP

CAP is one of three main ways to build SAP applications today. Which one you pick depends on your language, your target system, and whether you are building cloud-native or on the ABAP stack:

CAP and RAP are not competitors so much as complements — both use CDS for data modeling and both produce OData services. CAP targets developers who prefer JavaScript or Java and want to deploy on BTP Cloud Foundry or Kyma. RAP targets ABAP developers who want to build cloud-ready services inside the ABAP Environment or S/4HANA. Classic ABAP remains the default for legacy ECC systems and on-premise extensions. If you are starting a new cloud project on BTP with a Node.js or Java team, CAP is almost always the right choice.

Core Concepts

A CAP application is built around a small number of concepts that work together:

• Data models — declared in CDS, your entities, types, and associations describe the structure of your domain. CDS is the single source of truth that drives database schemas, service definitions, and the OData API.
• Service definitions — also in CDS, services expose projections over your data model. CAP auto-generates CRUD operations and OData endpoints from these projections.
• Event handlers — plain Node.js or Java code that runs on service events (before, on, after READ/CREATE/UPDATE/DELETE). This is where you add validation, side effects, and business rules.
• Persistence — CAP abstracts the database. SQLite is used locally for fast dev, SAP HANA is the production target on BTP, and adapters add PostgreSQL support.
• Bootstrap and runtime — cds watch for development with live reload, cds build and cds deploy for production, plus service bindings to BTP destinations and user authentications via XSUAA.

CAP embraces convention over configuration. Files named db/schema.cds, srv/service.cds, and srv/service.js (or .java) are picked up automatically. Sticking to the conventions means less wiring and tools — including IDE extensions and AI assistants — understand your project structure out of the box.

CAP and CDS

Core Data Services (CDS) is the heart of CAP. CDS is a declarative, SQL-inspired language for defining data models and services, plus annotations that steer the UI, persistence, and API behavior. A minimal CAP service looks like this:

using { Currency, managed } from '@sap/cds/common';

namespace shop;

entity Books : managed {
  key ID : Integer;
  title  : String;
  stock  : Integer;
  price  : Decimal(9,2);
  currency : Currency;
}

service CatalogService {
  entity Books as projection on shop.Books;
}

Run cds watch and CAP will create a SQLite database, expose /odata/v4/catalog/Books as an OData V4 endpoint, and give you a generic service UI for browsing. You have written no SQL, no HTTP handler, and no ORM mapping — CAP generated it all from the CDS.

Key CDS building blocks you will use daily:

• Associations and compositions — foreign-key-style relationships (association) and contained-by relationships (composition, used for document-style entities with deep inserts).
• Aspects — reusable pieces of definition, like managed (adds createdAt, createdBy, modifiedAt, modifiedBy) or cuid (adds a UUID key).
• Annotations — @Analytics, @odata.draft.enabled, @mandatory, @UI.* annotations for Fiori Elements, and many more. Fiori Elements reads these directly off the OData metadata to render the UI.
• CSN and CDL — CAP compiles CDS into a Canonical Service Model (CSN, JSON) that tools consume, and a CDS Definition Language (CDL) for human-readable dumps.

Because CDS is the single source of truth, the same model drives database schema, API shape, and UI annotations. Change the model and all three stay in sync.

Full-Stack Development

CAP is rarely used in isolation. The standard SAP full-stack pattern is **CAP backend

• Fiori / SAPUI5 frontend**, talking over OData:

• Backend: CAP service definitions in CDS, event handlers in Node.js or Java, persistence in SQLite (dev) or SAP HANA (prod), deployed to BTP Cloud Foundry or Kyma (Kubernetes runtime).
• Frontend: SAPUI5 freestyle or Fiori Elements app generated from the CAP OData service, with @UI.* and @Consumption.* annotations in CDS steering what Fiori Elements renders.
• Cross-cutting: CAP handles authentication (XSUAA / IAS), authorization (@restrict, instance-based auth), multitenancy via cds.fiori.lean_draft and HMAC-based subscription, and messaging through SAP Event Mesh.

This CAP + Fiori combination is what SAP means when it talks about "clean-stack" or "cloud-native" S/4HANA extension development. CAP gives you a small, declarative backend; Fiori gives you a consistent UI; BTP gives you the runtime. CAP's built-in support for multitenancy and authorization is what makes SaaS-style apps feasible without reinventing security.

AI-Assisted CAP Development

CAP rewards convention and punishes drift. CDS has its own syntax, the annotation vocabulary is large (@UI.*, @Common.*, @Analytics.*, @odata.*, @cap-js/*), event handler signatures are specific, and the Node.js and Java runtimes have different idioms. A general-purpose AI assistant will routinely confuse CDS with plain SQL, invent annotations that do not exist, or generate Node.js handlers that use the wrong CAP APIs.

That is exactly what a CAP skill fixes. The sap-cap-capire skill injects the Capire documentation, current @sap/cds conventions, CDS/CSN/CDL syntax, event handler patterns, deployment recipes for Cloud Foundry and Kyma, and the CAP-specific MCP server — so the assistant produces CDS and handlers that actually compile and run.

npx skills add secondsky/sap-skills --skill sap-cap-capire

For a complete full-stack setup, pair sap-cap-capire with the sapui5 or sap-fiori-tools skill on the frontend, and with sap-hana-cli when you are tuning HANA persistence or running SQLScript procedures from CAP. The combination is the closest thing to a senior SAP full-stack pair-programmer you can install today.