Generate SAP CAP application from requirements — CDS models, OData services

Tier: Beta. SAP CAP is a beta target — Archiet generates real CDS models, OData service definitions, and CAP handlers, but unlike the web stacks it is not runtime-boot-verified in CI: running and deploying it requires your own SAP BTP subaccount / CAP toolchain. Treat the output as a strong, standards-correct starting point you validate with cds watch and a BTP dev space before production.

What generating a SAP CAP application from requirements produces

db/
  schema.cds                  # CDS entity definitions from your model
  data/                       # CSV seed data per entity
srv/
  service.cds                 # OData v4 service; entity projections + actions
  service.js                  # service handlers (before/after/on hooks)
app/                          # Fiori elements / UI annotations (where applicable)
package.json                  # @sap/cds dependencies, cds build/deploy scripts
mta.yaml                      # BTP multi-target app deployment descriptor
xs-security.json              # XSUAA roles + scopes
README.md

SAP CAP patterns Archiet gets right

CDS entity definitions with managed aspects and associations, the CAP-idiomatic way to model data:

namespace com.acme.orders;
using { cuid, managed } from '@sap/cds/common';

entity Orders : cuid, managed {
  status   : String enum { open; shipped; closed };
  total    : Decimal(13,2);
  customer : Association to Customers;
}

OData v4 service projections that expose entities cleanly, with draft handling where appropriate:

service SalesService @(requires: 'authenticated-user') {
  entity Orders as projection on com.acme.orders.Orders;
}

Service handlers for business logic. srv/service.js registers before/after/on hooks for validation and derived fields, instead of leaking logic into the UI.

XSUAA-based authorization. xs-security.json defines roles and scopes, and services are annotated with @requires, so authorization follows the BTP identity model rather than ad-hoc checks.

BTP deployment descriptor. mta.yaml wires the service, the database (HANA or PostgreSQL on BTP), and the XSUAA instance for cf deploy / cds deploy.

What is included

• CDS data model — entities, associations, managed aspects from your PRD
• OData v4 service — projections, actions, and @requires authorization
• Service handlers — Node.js before/after/on hooks for business logic
• Security + deployment — xs-security.json roles and mta.yaml for BTP
• Seed data + README — CSV seeds and cds watch / deploy instructions
• Architecture docs — ADRs under docs/decisions/

Related

• Step-by-step walkthrough: Generate a SAP CAP application from your PRD
• Related page: SAP RISE migration
• All use cases: archiet.com/use-cases

FAQ

What is generated for SAP CAP?

A CAP project: a CDS data model (db/schema.cds), an OData v4 service definition and handlers (srv/), XSUAA security config, and an mta.yaml BTP deployment descriptor — runnable with cds watch.

What do I need to run it?

The CAP toolchain (@sap/cds-dk) locally for cds watch, and a SAP BTP subaccount for deployment. Archiet generates the project; you run and deploy it in your own BTP environment.

Does it use OData?

Yes — OData v4 service projections over the CDS entities, the standard CAP service protocol, with authorization via @requires and XSUAA scopes.

Is the SAP CAP stack production-ready?

It is a beta target: the CDS models, OData services, and handlers are real and standards-correct, but it is not runtime-boot-verified in CI because running it requires your own BTP toolchain. Validate with cds watch and a BTP dev space before production.

CTA

Generate a SAP CAP application from your requirements — free plan, no credit card.

Describe your product, pick SAP CAP, and download a CAP project to run with cds watch.

Start free at archiet.com.