SAP CAP provides a powerful and developer-friendly ecosystem for building full-stack enterprise applications. Before deploying to the cloud, most of your work happens locally — running services, debugging code, testing handlers, and validating your data models.
This blog explains the essential local development tools CAP developers rely on, helping you improve productivity, debug efficiently, and build confidently.
Why Local Development Tools Matter
CAP emphasizes a rapid, iterative development workflow. Local tools allow developers to:
- Run CAP applications instantly
- Debug Node.js services
- Test CDS models and OData services
- Use SQLite for quick local persistence
- Catch errors early before deployment
Mastering these tools accelerates CAP learning and prevents costly issues later.
Running CAP Projects Locally
The primary tool for running CAP applications locally is the CDS CLI.
Starting Your CAP Service
cds run
This command:
- Compiles CDS models
- Starts your application server
- Exposes REST and OData endpoints
- Connects to SQLite automatically (if configured)
CAP reloads models dynamically when you restart the server.
Using CDS Watch for Auto-Reloading
cds watch
Features:
- Auto restarts the server
- Watches CDS, JS, and YAML files
- Shows model preview and service interactions
This is perfect for rapid development.
Using SQLite for Local Development
SQLite is the preferred local database for CAP projects. CAP uses it by default when running locally.
Example SQLite configuration
"cds": {
"requires": {
"db": {
"kind": "sqlite",
"model": "db/"
}
}
}
Initialize SQLite database
cds deploy --to sqlite:my.db
This creates a local DB file and syncs CDS models.
Debugging CAP Applications
Debugging is a crucial part of CAP development, especially when working with custom handlers, actions, functions, or complex logic.
VS Code Debugging for CAP
CAP integrates seamlessly with VS Code’s debug environment.
Example launch.json
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Debug CAP Service",
"program": "${workspaceFolder}/node_modules/@sap/cds/bin/cds.js",
"args": ["run"],
"cwd": "${workspaceFolder}",
"console": "integratedTerminal"
}
]
}
Once set up, you can:
- Add breakpoints
- Inspect variables
- Step through request handlers
- Debug before/after event flows
Debugging Event Handlers
Example handler:
srv.before('CREATE', 'Orders', (req) => {
console.log("Debug:", req.data);
});
Use this during development to inspect payloads.
Testing CAP Services Locally
CAP includes built-in tools for testing OData REST services.
Run CAP and open the local service browser
http://localhost:4004
Features:
- Browse entities
- Run queries
- Test CRUD operations
- View the service API
Using CAP Testing Framework
Create a test file:
const cds = require('@sap/cds');
describe('CAP Service Tests', () => {
it('should return products', async () => {
const srv = await cds.connect.to('CatalogService');
const result = await srv.run(SELECT.from('Products'));
expect(result.length).toBeGreaterThan(0);
});
});
Run tests:
npm test
CAP Dev Sandbox (CAP Server Sandbox Mode)
CAP also has a development sandbox that simulates:
- Mock authentication
- Mock user roles
- Auto-generated databases
- Preloaded sample data
Enable sandbox:
cds watch --sandbox
Perfect for experimenting with security or mock users.
Environment Variables for Local Debugging
CAP respects environment variables to modify runtime behavior.
Example .env
PORT=5000
CDS_LOG_LEVEL=debug
Useful for:
- Changing ports
- Enabling detailed logs
- Testing production-like scenarios
Real-World Example
A typical local workflow for CAP developers:
- Start project using
cds watch - Develop handlers and CDS models
- Debug service interactions using VS Code
- Inspect data loaded into SQLite
- Write automated tests to verify logic
- Run everything locally before deploying to BTP
This workflow ensures a smooth development cycle and reduces production issues.
Best Practices
- Use
cds watchfor active development - Always use VS Code debugging for event handlers
- Keep SQLite only for development, not production
- Use
.envfiles to simulate runtime environments - Test with mocked roles while developing authorization
- Use CAP’s built-in test framework instead of custom scripts
Conclusion
Local development tools are essential for building reliable and efficient CAP applications. Whether you are testing your services, debugging handlers, or running your project with SQLite, these tools streamline the entire development process.
Understanding these workflows helps you move faster, avoid errors, and create production-ready CAP applications.
WhatsApp us