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
  • 1. Install Node.js
  • 2. Install CAP's cds-dk
  • 3. Install Git
  • 4. Install SQLite
  • 5. Install Java & Maven
  • 6. Install Visual Studio Code
• Jumpstart CAP Projects
  • Project Structure
  • Project Content
  • Minimal Configuration
• Rapid Development
  • Mocked Platform Services
  • Mocked Remote Services
• Speed up Your Pipelines

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:

• SAP CDS Language Support
• ESLint
• REST Client
• SQLite Viewer
• Rainbow CSV

Jumpstart CAP Projects

Assumed we want to create a project named bookshop, we'd do so like this:

Node.js

cds init bookshop

Java

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

Project Content

Principle of locality

Using CAP, it's a rule of thumb that related files are placed next to each other. This is prominently demonstrated with sibling .js files, next to .cds sources, for implementing services.

Using Subfolders

CAP assumes some default locations for your files. If you want to deviate from those defaults, for example, to organize annotations files or database-specific files in subfolders, you need to add an index.cds file that contains the information where to find the needed files.

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:

package.json

{ ...
  "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:

Node.js

cds watch

Java

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:

• Hello World!
• Getting Started in a Nutshell

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.