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.
On the ABAP door the laptop runs a whole system: SAP's trial image is an application server and a database in one container, and a developer's own setup happens in that system after it starts, which is the part abapDevSysInit by Mike PokrakaMike Pokrakamaintains 1 entry, contributed to 11 entries scripts.
SAP publishes the ABAP Cloud Developer Trial as a Docker image, an AS ABAP with its SAP HANA database, free for education and demo purposes. Its ABAP license lasts three months and is renewed by importing a demo license into the container.
Not covered: At a running system. What a developer then sets up inside it on every new container, a user profile, abapGitabapGitA Git client written in ABAP that runs inside the system, so objects are cloned, pulled and pushed without leaving it; with no package manager in ABAP, a cloned repository is how code is distributed.community org, abap, SSL certificates and a destination for GitHub, and the repositories to pull, is done by hand.
abapDevSysInitpokrakam/abapDevSysInitA single ABAP report that automates setting up a new ABAP Developer Edition or trial system, from the user profile and a GitHub RFC destination to fetching abapGit and pulling repositories.independent, abap scripts that setup inside a trial system, and abap_trial_dockerabap_trial_dockerShell scripts that build a Docker image from the SAP NetWeaver ABAP Developer Edition 7.52 SP04 installation files and run it as an unprivileged container, setting the stable hostname the installer wants.independent, abap builds the NetWeaver ABAP Developer Edition into a Docker container. web-abap2UI5web-abap2UI5A build pipeline and the page it deploys: the abap2UI5 backend downported, transpiled to JavaScript and webpacked into one script that runs inside a browser tab, with no server and no SAP system behind it.community org, abap and the abap2UI5 Playgroundabap2UI5 PlaygroundABAP in the editor on the left and the abap2UI5 app it builds on the right, both inside one browser tab: the framework is transpiled to JavaScript at build time and the class in the editor is compiled when Run is pressed.community org, abap run abap2UI5 transpiled to JavaScript in a browser tab with no ABAP system behind it, and open-steamgateopen-steamgateAn ABAP application server you clone and run on your own machine: transpiled ABAP serving classic /IWBEP/ OData v2 to Fiori over a local database, with no SAP system attached.independent, abap runs transpiled ABAP and the Gateway on the developer's machine.
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