CAP in one picture

Contoso's fleet order status app lets the fleet desk and Great Lakes Fleet Services see where alternator orders stand, and lets the fleet desk record inquiries about late or changed orders. Course sap-btp-201 placed it side-by-side on SAP BTP. This course builds it with the SAP Cloud Application Programming Model (CAP), SAP's framework for business services and apps on SAP BTP. The aim is not to make you a CAP expert in an hour; it is to give you an accurate model of how a CAP app is put together, so you can build one, read one, and test one.

What CAP is

CAP is a framework that sits between the database and the user interface. Its core is CDS (Core Data Services): you describe your domain model and your services in CDS, and CAP's runtimes for Node.js and Java serve them. CAP's documentation calls CDS the backbone of everything: from the model, CAP generates database tables and OData APIs, and its generic providers answer most requests (create, read, update, delete, search, paging, input validation) without custom code. You write code only where your business logic differs. CAP's design is also agnostic: your models and logic do not depend on whether data comes from a local database or a remote API, or which protocol a client uses.

The inner loop

Developers work in SAP Business Application Studio or a local editor with the CAP development kit installed. cds init fleet-order-status creates the project. cds watch starts a local server that restarts on every change; with no further configuration it uses an in-memory SQLite database, loads .csv test data, and serves each service as OData V4 at a path such as /odata/v4/fleet. Production uses SAP HANA Cloud (CAP also supports PostgreSQL). SAP Build Code adds Joule to SAP Business Application Studio, so a developer can generate a first CDS model, sample data and handler code from a description; generated code is reviewed and tested like any other. CAP calls this fast local cycle the inner loop, and it is the main reason CAP teams can test so much without a cloud deployment: SAP's CAP guide compares turnaround times of minutes for cloud-only cycles with seconds locally.

Where CAP fits

CAP's documentation recommends use-case-oriented services: rather than one service exposing everything, define a service per user group and use case. The fleet app will have a FleetService for the fleet desk and an AdminService for maintaining reference data. That choice matters for testing and security later, because each service can be secured, tested and versioned separately.

For a tester, CAP's conventions are good news. Because so much behavior comes from the model, reading the .cds files tells you what the app exposes, which inputs it validates and who may call it, before you run anything. Because the same service runs locally and in the cloud, a defect found in cmc-ext-test can usually be reproduced on a developer's machine within minutes. And because CAP ships its own test support (cds.test, covered in course sap-btp-301), service-level tests are cheap to write. The flip side is that defects in configuration, such as destinations, roles and profiles, only appear in deployed environments, so the test strategy must cover both.