SAP Cloud Application Programming Model (CAP)

A CAP application starts from declarations and adds code only where the framework's defaults are not enough:

1. Domain model: entities, types and associations are written in CDS files, for example suppliers and delivery slots for an Alder Manufacturing logistics app.
2. Services: service definitions expose projections of those entities, shaped for a UI or an API.
3. Runtime: the Node.js runtime or the CAP Java SDK serves the services and handles standard operations generically: reading, writing, paging, sorting and SAP Fiori draft.
4. Custom logic: event handlers in JavaScript, TypeScript or Java, registered for the before, on and after phases of a request, add validations, calculations and calls to other systems.
5. Persistence: the same model runs on SQLite or H2 during development and on SAP HANA Cloud or PostgreSQL in production.
6. Deployment: the application is deployed to SAP BTP, on the Cloud Foundry or Kyma runtime.

SAP Fiori elements apps consume CAP services through UI annotations written in the same CDS files. A CAP application is therefore mostly model, with code concentrated where the business logic is specific.

No. Both come from SAP's Core Data Services idea, both use a similar declarative syntax and both carry annotations, but they are separate implementations:

• ABAP CDS is part of the ABAP platform. Its views are repository objects activated as database views inside an ABAP system and transported with ABAP transports.
• CAP CDS is CAP's modeling language. Its compiler turns models into a JSON-based representation called Core Schema Notation (CSN), from which CAP generates database artifacts and service metadata.

Annotations show the difference in practice. In CAP, UI annotations use the OData term names directly, such as UI.LineItem; in ABAP CDS, element-level notations such as @UI.lineItem are translated into those terms when the service is exposed. A model cannot be moved from one to the other unchanged. CAP CDS and ABAP CDS share a name and a philosophy, not a runtime.

Choose CAP when:

• the application belongs beside SAP S/4HANA, not inside it, as a side-by-side extension on SAP BTP;
• the application owns its own data or combines data from several systems, SAP and non-SAP;
• the team works in JavaScript, TypeScript or Java rather than ABAP;
• the application must serve several customers as a multitenant SaaS offering, which CAP supports with tenant isolation and its MTX services.

Prefer RAP when the logic must run in the same transaction as SAP S/4HANA data, when the extension changes a standard business object, or when the team and the operations model are ABAP-based.

Many landscapes use both: RAP for logic close to the core, CAP for applications around it. The deciding question for CAP is where the data and the transaction belong.

A CAP application does not run inside SAP S/4HANA, so it reaches SAP data through APIs:

1. The API definition of an SAP S/4HANA OData service, for example from the SAP Business Accelerator Hub, is imported into the CAP project with cds import, which reads OData EDMX, OpenAPI and AsyncAPI files.
2. During development, CAP can mock the imported service locally, so teams can work before the connection exists.
3. In production, calls go through SAP BTP connectivity: destinations for the target system and, for on-premise systems, the Cloud Connector.
4. Events from SAP S/4HANA can trigger CAP logic asynchronously where the scenario supports them, typically through an SAP event broker service.

The released API, not the database table, is the contract between CAP and SAP S/4HANA. This keeps the extension decoupled from the core, which is the purpose of the side-by-side approach CAP follows.

CAP's strengths are speed and consistency. Generic handlers remove boilerplate, local development works without a cloud connection thanks to mocks and SQLite, SAP Fiori and SAP HANA support are built in, and multitenancy is part of the framework instead of a project of its own.

The limits come from running outside the system of record:

• No direct access to SAP S/4HANA internals. Everything goes through released APIs; missing APIs become blockers or need an ABAP-side complement.
• No shared transaction. A CAP update and an SAP S/4HANA posting are separate transactions; failure handling must be designed explicitly.
• More to operate. A CAP application adds an SAP BTP runtime, a database and connectivity to the landscape, with their own monitoring, upgrades and costs.
• Opinionated framework. Working against CAP's conventions costs more than following them.

CAP is the stronger choice for applications beside the core; it does not replace logic that must live inside it.