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 setup and start projects? See the Get Started menu in the left-hand-side 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 ​

Choose the LTS version, via the left-hand side button:

2. Install CAP's cds-dk ​

… by running this in a terminal:

npm add -g @sap/cds-dk

Running into problems? → See the troubleshooting guide.

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:

cds init bookshop

cds init bookshop --add java

Then open it in Visual Studio Code:

code bookshop

Project Structure ​

The default project structure of CAP projects is as follows:

bookshop/        # Your project's root folder
├─ app /         # UI-related content goes here
├─ srv/          # Service-related content goes here
├─ db/           # Domain models and database-related content goes here
├─ package.json  # Contains configuration for 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/"
    }
  }
}

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

[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'd go on 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

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 'inner loop' mode.

Following are the defaults used automatically in production, or development mode.

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, 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.

A step-by-step walkthrough can be found in our TechEd 2022 sample.

Speed up Your Pipelines ​

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.