@capire/xflights

This is a reuse package to manage and serve master data like Airlines, Airports, and Flights. It publishes a pre-built client package, that is used in the xtravels application.

Table of Contents

• Domain Model
• Service Interfaces
• Exporting APIs
• Publishing APIs
• Consuming APIs
• Using Workspaces

Domain Model

The domain model is defined in db/schema.cds. It centers around normalized FlightConnections, which connect two Airports operated by an Airline, while entity Flights represents scheduled flights on specific dates with a specific aircraft and price.

Service Interfaces

Two service interfaces are defined in srv/admin-service.cds, and srv/data-service.cds, to serve different use cases as shown below:

• an admin service to maintain the master data from UIs or remote systems
• a data service to consume it from remote applications

Tip

Serving denormalized views

The data service exposes a denormalized view of `Flights` and associated `FlightConnections` data, essentially declared like that:

entity Flights as projection on my.Flights { 
  *,          // all elements from Flights
  flight.*,   // all elements from FlightConnections
}

With that consumers aren't bothered with normalized data but can just consume flat data, looking like that:

Exporting APIs

Given the respective service definition, we create a pre-built client package for the data API, which can be used from consuming apps in a plug-and-play fashion.

We use cds export to create the API package, based on the Data Service definition:

cds export srv/data-service.cds

This generates a separate CAP reuse package within subfolder apis/data-service that contains only the effective service API definitions, accompanied by automatically derived test data and i18n bundles.

Initially, cds export also adds a package.json, which we can modify as appropriate, and did so by changing the package name to @capire/xflights-data:

{
- "name": "@capire/xflights-data-service",
+ "name": "@capire/xflights-data",
  ...
}

Publishing APIs

We can finally share this package with consuming applications using standard ways, like npm publish:

cd apis/data-service
npm publish

Tip

Using GitHub Packages

Within the capire org, we're publishing to GitHub Packages, which requires you to npm login once like that:

npm login --scope=@capire --registry=https://npm.pkg.github.com

As password you're using a Personal Access Token (classic) with read:packages scope (for retrieving and installing a package). Read more about that in Authenticating to GitHub Packages.

Consuming APIs

Use the published client package in your consuming application by installing it via npm:

npm add @capire/xflights-data

With that, we can use the imported models as usual, and as if they were local in mashups with our own entities like so:

using { sap.capire.flights.data as imported } from '@capire/xflights-data';
entity TravelBookings { //...
  flight : Association to imported.Flights;
}

▷ Learn more about consuming APIs and CAP-level data integration in the xtravels application.

Using Workspaces

Instead of exercising a workflow like that again and again:

• ( develop → export → publish ) → npmjs.com → ( update → consume )

... we can use npm workspaces technique to work locally and speed up things as follows:

mkdir -p cap/works; cd cap/works
git clone https://github.com/capire/xflights
git clone https://github.com/capire/xtravels
echo '{"workspaces":["xflights","xtravels"]}' > package.json

Add a link to the local @capire/xflights-data API package, enclosed with the cloned xflights sources:

npm add ./xflights/apis/data-service

Check the installation using npm ls, which would yield output as below, showing that @capire/xtravel's dependency to @capire/xflights-data is nicely fulfilled by a local link to ./xflights/apis/data-service:

npm ls @capire/xflights-data

works@ ~/cap/works
├── @capire/xflights-data@0.1.11 -> ./xflights/apis/data-service
└─┬ @capire/xtravels@1.0.0 -> ./xtravels
  └── @capire/xflights-data@0.1.11 deduped -> ./xflights/apis/data-service

Start the xtravels application → and note the sources loaded from ./xflights/apis/data-service, and the information further below about the sap.capire.flights.data service mocked automatically:

cds watch xtravels

[cds] - loaded model from 20 file(s):

  xtravels/srv/travel-service.cds
  xtravels/db/schema.cds
  xtravels/db/xflights.cds
  xflights/apis/data-service/index.cds
  xflights/apis/data-service/services.csn
  ...

[cds] - mocking sap.capire.flights.data {
  at: [ '/odata/v4/data', '/rest/data', '/hcql/data' ],
  decl: 'xflights/apis/data-service/services.csn:3',
}

Using Proxy Packages

The usage of npm workspaces technique as described above streamlined our workflows as follows:

• Before: ( develop → export → publish ) → npmjs.com → ( update → consume )
• After: ( develop → export ) → ( consume )

We can even more streamline that by eliminating the export step as follows...

Create a new subfolder xflights-api-shortcut in which we add two files as follows:

mkdir xflights-api-shortcut

Add a package.json file in there with that content:

{
  "name": "@capire/xflights-data",
  "dependencies": {
    "@capire/xflights": "*"
  }
}

And an index.cds file with that content:

using from '@capire/xflights/srv/data-service';

Using the shell's "here document" technique

You can also create those two files from the command line as follows:

cat > xflights-api-shortcut/package.json << EOF
{
  "name": "@capire/xflights-data",
  "dependencies": {
    "@capire/xflights": "*"
  }
}
EOF

Take the same approach for the index.cds file:

cat > xflights-api-shortcut/index.cds << EOF
using from '@capire/xflights/srv/data-service';
EOF

With that in place, change our API package dependency in the workspace root as follows:

npm add ./xflights-api-shortcut

Check the effect of that → note how @capire/xflights-data dependencies now link to ./xflights-api-shortcut:

npm ls @capire/xflights-data

works@ ~/cap/works
├── @capire/xflights-data@ -> ./xflights-api-shortcut
└─┬ @capire/xtravels@1.0.0 -> ./xtravels
  └── @capire/xflights-data@ deduped -> ./xflights-api-shortcut≤

Start the xtravels application → and note the sources loaded from ./xflights-api-shortcut, and the information further below about the sap.capire.flights.data service now being served, not mocked anymore:

cds watch xtravels

[cds] - loaded model from 20 file(s):

  xtravels/srv/travel-service.cds
  xtravels/db/schema.cds
  xtravels/db/xflights.cds
  xflights-api-shortcut/index.cds
  xflights/srv/data-service.cds
  xflights/db/schema.cds  
  ...

[cds] - serving sap.capire.flights.data {
  at: [ '/odata/v4/data', '/rest/data', '/hcql/data' ],
  decl: 'xflights/apis/data-service/services.csn:3',
}

Which means we've streamlined our workflows as follows:

• Before: ( change → export → publish ) → npmjs.com → ( update → consume )
• Step 1: ( change → export ) → ( consume )
• Step 2: ( change ) → ( consume )

License

Copyright (c) 2026 SAP SE or an SAP affiliate company. All rights reserved. This file is licensed under the Apache Software License, version 2.0 except as noted otherwise in the LICENSE file.