Explain SAP CAP (Cloud Application Programming Model) in SAP

58 / 65

BTPadvanced

SAP CAP (Cloud Application Programming Model)

SAP's opinionated, model-driven framework for building cloud applications with a unified data model spanning Node.js and Java.

CAP is SAP's framework for building cloud applications on BTP. Its premise is that you describe the model and the framework produces most of the application.

CAP is like an architect's parametric building-design software - you declare the building's structure and rooms (the CDS model) once, and the software automatically generates the wiring, plumbing, and staircases (the working OData service) for you, letting you focus your actual effort on the custom features (event handlers) that make this particular building different, while still being able to preview it cheaply on a small scale model (SQLite) before building the real, full-scale version (HANA Cloud) from the identical blueprint.

Key Concepts

You write CDS, and get a working service.

    entity Orders {
      key ID       : UUID;
          customer : Association to Customers;
          amount   : Decimal(15,2);
          status   : String(10);
    }

    service SalesService {
      entity Orders as projection on db.Orders;
    }

That is a complete, running OData V4 service: create, read, update, delete, plus $filter, $expand, $select, pagination and draft handling. No handler code.

$filter$expand$select

Custom logic hooks onto the generated service rather than replacing it:

    srv.before('CREATE', 'Orders', (req) => {
      if (req.data.amount <= 0) req.error(400, 'Amount must be positive');
    });

    srv.after('READ', 'Orders', (orders) => { /* enrich */ });

So you write the parts that are specific to your business and none of the boilerplate — which on a CRUD-heavy application is most of it.

One model, several targets. The same service definition runs against different databases:

    local development  SQLite, starts instantly, no cloud needed
    production         SAP HANA Cloud

CAP generates the database-specific SQL. That changes the development loop: you iterate locally in seconds instead of deploying to a HANA instance for every change.

It can also expose the same model as OData or plain REST, which is a smaller convenience but the same idea.

Multitenancy is built in, which matters if you are building software to sell. One deployment serves many customer subaccounts, and CAP handles provisioning a schema per tenant rather than each project inventing that.

It also supports letting those customers extend the model in a controlled way — the same idea as key user extensibility in S/4HANA, applied to your application.

Why SAP steers new work here rather than to plain Express or Spring Boot. BTP's services — destinations, connectivity, event mesh, authorisation — are first-class in CAP rather than integrations you assemble.

The honest counter-argument is that CAP is opinionated. An application that is mostly unusual logic and barely any CRUD gets less from it, and fights the framework more. For business applications over a data model, which is most of what gets built on BTP, the trade is clearly worth it.

What the interviewer is probing.1. "What does CAP give you over hand-built services?" Probing: the value. Stalls: "Less code." Moves up: CDS models generating persistence, OData services, validation and Fiori annotations, with the same model across Node and Java.

2. "What is the difference between the data model and the service model?" Probing: the layering. Stalls: "Nothing." Moves up: the data model defines entities and persistence; the service model projects and restricts them per consumer, which is where authorisation lives.

3. "How is authorisation expressed?" Probing: the mechanism. Stalls: "In code." Moves up: declaratively with @requires and @restrict on services and entities, mapped to scopes in the security descriptor.

4. "How do you handle custom logic?" Probing: the extension point. Stalls: "Override everything." Moves up: event handlers before, on and after the generated operations, so the generic implementation is kept and only the delta is written.