SAP BTP series
SAP CAPM: Cloud Application Programming Model for Clean-Core Extensions
- SAP CAP
- CAPM
- CDS
- HANA Cloud
- Clean core
SAP CAP (searched as CAPM) is CDS, services, events, HANA Cloud, destination service, XSUAA, multitenancy. It is how you extend S/4 without breaking clean core. cds watch is not production. Principal propagation that dies on Friday night is the real exam. SR Soft staffs CAP in Node and Java with people who have deployed to Cloud Foundry or Kyma.
Challenges we actually see
- Domain models that match a tutorial, not a business object
- No outbox — events lost on a crash
- Destinations hard-coded, principal propagation skipped
- Multitenancy promised to an ISV and never tested
- Handlers that call S/4 synchronously from a user click and time out
- 01
Object first
The S/4 object is the model. Not a bookstore.
- 02
Outbox
Events survive a crash or they are not events.
- 03
Propagation
The user in S/4 is the user in CAP.
- 04
Operate
Logs, retries, alerts — named on-call.
CAP skills we place
Every S/4 program we run asks: RAP in the core, CAP beside it, or both. We staff both. Future: CAP + Datasphere + Joule tools.
Outbox, propagation, and the Friday-night destination
CAP without an outbox loses events on a crash. Destinations hard-coded in a handler will die when the URL changes. Principal propagation skipped means the CAP service is a superuser — a SoD finding and a data-leak pattern. Multitenancy promised to an ISV and never load-tested is a lawsuit. We staff people who have deployed to CF or Kyma and who have been on-call when a destination expired.
The domain model is the S/4 object, not a bookstore. Handlers that call S/4 synchronously from a click will time out. We design async first. RAP in-stack versus CAP beside is a gravity question we write down. Both, when both are honest.
