CAP promotes getting started with minimal upfront setup, based on convention over configuration, and a grow-as-you-go approach, adding settings and tools later on, only when you need them. So, let's get started…
Looking for other ways to setup and start projects? See the Get Started menu in the left-hand-side sidebar.
Follow the steps below to set up a local development environment. If you are a developer, you might already have most things installed, such as Node.js, Git, SQLite, Java, Maven, VS Code, and you only need to install cds-dk as described in step 2 below.
Assumed we want to create a project named bookshop, we'd do so like this:
Then open it in Visual Studio Code:
Note: VS Code CLI on macOS needs extra setup
Users on macOS must first run a command (Shell Command: Install 'code' command in PATH) to add the VS Code executable to the PATH environment variable. Find detailed instructions in VS Code's macOS setup guide.
Following the convention over configuration paradigm, CAP has defaults for many things that you'd have to configure in other frameworks. The goal is that things should just work out of the box, with zero configuration, whenever possible. You can override these defaults by specific configuration if you need to do so.
For example you could override the defaults for the project structure like that:
Whenever we add content, cds watch would react immediately, for example, by bootstrapping an in-memory SQLite database, filling it with initial data, and serving services to OData automatically, without need for time-consuming builds and deployments.
The rapid development experience, with minimum setup and fast turn-around times, is enabled by the CAP runtimes providing local stand-ins for common platform services. These allow us to run fully functional servers locally during development, in 'inner loop' mode.
Following are the defaults used automatically in production, or development mode.
SAP HANA Cloud
SQLite (in-memory or persistent)
Mocked Authentication Strategy
Message Brokers, Kafka
Audit Log Service
Stay in Inner Loop Development
... as much as possible to benefit from accelerated development at minimized costs. Use the full near-production setup only when you need it, for example for integration tests before releases.
A CDS service definition is all CAP needs to serve fully-functional OData services, with extensive database access included out of the box. This also allows us to mock remote services in service integration scenarios.
For example, assumed we want to integrate Business Partners from S/4, we do so by importing a service API, for example, the EDMX from SAP Business Accelerator Hub, and translating that into a CDS service definition using cds import. As we now have a service definition we can just serve this by CAP as a mock implementation instead of always having to use the remote S/4 service during development. This again greatly speeds up development turn-around times.
We strongly recommend to use the mocked services setup not only in development but also for functional tests in your test pipelines to speed them up by magnitudes.
Not only are inner-loop pipeline tests much faster, they also mean there's less complex setups, less dependency on high availability, and no risks your tests are considered denial of service attacks by used services.
Overall, using inner-loop tests...
helps speeding up your test runs by magnitudes, makes them more robust, and not the least: helps to minimize costs. Make use of that as much as possible and only use the full monty for real integration tests.