Running the whole stack on a laptop against real bindings — the service, the UI and the routing in front of it — without deploying to see a change.
@sap/ams-dev Compiles the DCL authorization policies of SAP's Authorization Management Service to DCN, so an AMS-secured application runs and is tested on a laptop.
@sap/cds-dk The command line client and development toolkit for CAP projects, with the commands cds build, cds deploy, cds watch and cds add among them.
@sap/cds Mocks every imported remote service in process with mock data in the same in-memory database, and authenticates with mocked users by default in development, so the whole stack runs on a laptop before anything is bound.
com.sap.cds:cds-feature-dev-dashboard A browser dashboard for a running CAP Java service that shows and manages its messaging, resilience and multitenancy state while developing, open to users with the cds.Developer role.
com.sap.cds:cds-maven-plugin The Maven plugin that runs CDS build steps in a CAP Java project: compiling the model, generating typed Java accessor interfaces and adding facets to an existing project.
Not covered: The watch loop stops at the service process: the App Router that carries the authentication flow is a second process started beside it, which capire documents as cds add approuter with cds bind --exec -- npm start on port 5000, and the pages read here document no local stand-in for the HTML5 application repository. What the service runs against is not what production runs: mocked authentication is not suitable for production, a mocked service returns no data across its associations out of the box, and SQLite is not fit for production.
dev-approuterdev-approuterA development-time wrapper for the SAP Application Router that serves UI5 and CDS modules once they are added to the project as dependencies.community org, cap runs the router as a development-time process that serves a project's UI5 and CDS modules, @neoimpulse/cap-js-bootstrap@neoimpulse/cap-js-bootstrapA command-line tool that starts a local CAP environment with several services and an AppRouter together from one command, documented in German and requiring Node 22 or newer.independent, cap starts several services and the router from one command, and the local HTML5 repository of @cap-js-community/common@cap-js-community/commonSix independent features for CAP services in one package: replication cache, migration check, rate limiting, a Redis client broker, a local HTML5 repository and a CDM builder.community org, cap serves the apps in the app folder from the file system and proxies the rest to the remote repository. @sang2x/captools@sang2x/captoolsA CLI of eight CAP development commands aimed at Cloud Foundry workflows, shipped without a repository or README, whose binding step writes resolved VCAP_SERVICES into default-env.json.independent, cap chains the Cloud Foundry binding and cds watch --profile hybrid behind one command, writing the resolved VCAP_SERVICES into default-env.json.
A developer opens the application on a laptop at the address the App Router serves, logs in through the real authentication flow, and reaches the CAP service and the UI modules behind it the way a deployed request would.
Covers the routing and the login in front of the service. Starting the service itself is a separate outcome, and so is resolving the cloud bindings the router's authentication needs. Assessed on Node.js, where capire documents the local App Router setup; the same router in front of a CAP Java service was not assessed here.
Conditions: an XSUAA or SAP Identity service instance exists in the cloud and is bound with cds bind, since the credentials the router starts with come from that binding the CAP application runs beside the router with the hybrid profile
Remaining work: Create the service instance and the service key in the cloud, bind them, and keep two processes running. The router itself needs no restart on a file change, since it serves static files or delegates to the backend service.
Remaining work: Add the modules as dependencies. The registry page carries no README, so what it expects of the environment around it is not documented here.
Conditions: a default-env.json in the approuter folder holds a valid HTML5 repository configuration from the deployment environment the app or library sits in the app folder and contains a ui5.yaml, which is what the local repository picks up
Remaining work: Write the configuration file and run the local-html5-repo command beside the router. The package is a bundle, so depending on it for this one feature brings its other five.
Conditions: Node.js 22 or newer, which the package states as its requirement a binding the router's own start command can resolve, since it starts the router through cds bind --exec
Remaining work: Configure the services it is to start. The documentation is in German, and the repository declared in the package metadata returns 404, so the npm page is the only thing to read.
A developer edits a CDS file or a handler and the running service answers the next request against the changed model, without stopping and starting it.
Covers the loop between a saved file and a served request. Attaching a debugger to that process is debugging, and what the service is bound to while it runs is a separate outcome.
Remaining work: Nothing beyond running it. The restart follows any changed file the project holds, seed data included, which is the loop working as documented rather than a setting.
Conditions: Spring Boot Devtools are on the project, without which the goal performs a complete restart of the application after a CDS model change, which capire calls slower on Windows the watch goal only works if the Spring Boot Devtools are enabled
Remaining work: Add the Devtools dependency, and the plugin group com.sap.cds to ~/.m2/settings.xml for the short mvn cds:watch form. Devtools detects changes to .class files only, so a change to Java code is picked up once the build has produced them.
A service running on a laptop reads and writes through a service instance that exists in the cloud — a database, a destination, an authentication service — instead of through the local substitute, with nothing deployed.
Covers how the local process comes to hold the instance's credentials and what kinds of instance can be reached. The network path to a system behind a firewall is connectivity rather than binding, and the router's login flow is its own outcome.
Conditions: the developer is logged in to the target Cloud Foundry space or Kubernetes cluster, which is where cds bind resolves the instance from the same profile name is used to create the binding and to run, since bindings are assigned to the hybrid profile by default
Remaining work: Create the instance and its service key in the cloud and keep the profile name consistent. The binding is resolved when the process starts, so a service only reachable through a tunnel still needs the tunnel.
Conditions: the target is a Cloud Foundry space with the application already deployed, since the command reads the bound services of an app the resolved VCAP_SERVICES may be written into default-env.json in the project
Remaining work: Keep the written file out of the repository, and read the published dist to know what a command does: there is no repository and no README.
A CAP project whose model imports a remote service and whose endpoints are authenticated starts, serves and answers requests on a laptop with no service instance bound, no database provisioned and no upstream system reachable.
Covers what answers in place of the database, the identity provider and the imported service. Reaching a real instance of any of them from the same laptop is hybrid testing and is assessed separately, and what the router in front adds is its own outcome.
Remaining work: Supply the mock data as CSV under srv/external/data. An association of a mocked service returns no data until the imported model is extended by hand, and the mocked users say nothing about how the deployed application will authenticate.
Remaining work: Nothing beyond running it. The database is reset on each application start, so seed data is the only data a fresh run has.
Remaining work: Add the plugin group com.sap.cds to ~/.m2/settings.xml for the short mvn cds:watch form, and generate the SQLite or H2 schema in the build where the local database needs one.
Neither the package manifest nor the repository tree declares a licence.
Neither the package manifest nor the repository tree declares a licence.
cds bind gained support for service instances shared across Cloud Foundry orgs and spaces. Before 7.9.0, hybrid testing against a shared instance needed its own binding created per org and space; after it, cds bind can use an instance already shared into the current space directly, given Space Developer on both spaces.
Advice that hybrid testing needs a dedicated service instance per org and space. True before mid-2024; a shared instance is enough since.
cds bind and cds watch --profile hybrid gained support for user-provided service instances, not only SAP BTP managed ones. Before this, hybrid testing against a user-provided service meant wiring VCAP_SERVICES by hand; after it, cds bind --to my-user-provided-service resolves the binding the same way it does for a managed service.
Guidance that hybrid testing only reaches managed BTP services. Since January 2023 a user-provided service binds the same way.
These are the questions used to compare what the artifacts do. Values come from their documentation and may apply to a particular ecosystem or runtime. Each recorded value in the comparison opens its statement and sources.
capability:local-development