Jumpstart & Grow as You Go
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 set up and start projects? See the Getting Started menu in the left-hand sidebar.
Setup for Local Development
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.
1. Install Node.js
… from nodejs.org
On the Node.js page, use the download button which gets you the current long-term support (LTS) version:
See other ways to install Node.js.Learn more about long-term support (LTS) versions.
2. Install CAP's cds-dk
… by running this in a terminal:
npm add -g @sap/cds-dk
cds #> run the installed CLI
The cds
command supports shell completion with the tab key for several shells and operating systems. Run this command for the initial setup:
cds add completion
Find more information in the cds
CLI documentation
3. Install Git
Run this in a terminal to check whether you already have Git installed:
git version
If not, download and run the appropriate installer from git-scm.com.
4. Install SQLite
- On Windows only: Download and run the appropriate installer from sqlite.org.
5. Install Java & Maven
- If you want to go for CAP Java projects, ensure you have Java and Maven installed as described here.
6. Install Visual Studio Code
… from code.visualstudio.com
Choose your preferred editor or IDE for developing CAP applications.
We recommend Visual Studio Code.
In addition we recommend installing these VS Code Extensions:
Jumpstart CAP Projects
Assumed we want to create a project named bookshop, we'd do so like this:
cds init bookshop
cds init bookshop --add java
Then open it in Visual Studio Code:
code bookshop
Note: VS Code CLI on macOS needs extra setup
In order to start VS Code via the code
CLI, 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. Read VS Code's macOS setup guide for help.
Project Structure
The default project structure of CAP projects is as follows:
bookshop/ # Your project's root folder
├─ app/ # UI-related content
├─ srv/ # Service-related content
├─ db/ # Domain models and database-related content
├─ package.json # Configuration for cds + cds-dk
└─ readme.md # A readme placeholder
Minimal Configuration
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:
{ ...
"cds": {
"folders": {
"db": "database/",
"srv": "services/",
"app": "uis/"
}
}
}
Convention over Configuration
We recommend to stay with CAP's conventions to benefit from things just working out of the box. Only add configuration or override the defaults if you really need to do so.
Rapid Development
After having created a project we can immediately start a live server by running this in an Integrated Terminal in Visual Studio Code:
cds watch
cd srv && mvn cds:watch
From the log output we see cds watch
is waiting for things to come...
[dev] cds w
cds serve all --with-mocks --in-memory?
live reload enabled for browsers
___________________________
No models found in db/,srv/,app/,schema,services.
Waiting for some to arrive...
We continue by adding CDS domain models and service definitions, as well as custom logic, as outlined in these sample project guides:
Served out of the box...
Whenever we add content, cds watch
reacts 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.
Mocked Platform Services
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 an 'inner loop' mode.
These are the defaults used automatically in production, or development mode.
Production | Development |
---|---|
SAP HANA Cloud | SQLite (in-memory or persistent) |
IAS, XSUAA | Mocked Authentication Strategy |
Message Brokers, Kafka | File-based Messaging |
Audit Log Service | Console-based Logger |
Stay in Inner Loop Development
... as much as possible to benefit from accelerated development at minimized cost. Use the full 'near-production' setup only when you need it, for example for integration tests before releases.
Mocked Remote Services
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, assuming 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 it 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.
A step-by-step walkthrough can be found in our TechEd 2022 sample.
Speed up Your Pipelines
We strongly recommend using the mocked services setup, not only in development, but also for functional tests in your test pipelines to speed them up by orders of magnitude.
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 speed up your test runs by orders of magnitude, makes them more robust, and last but not least: helps to minimize costs. Make use of them as much as possible and only use the full monty for real integration tests.