Skip to content

Commit 8e3d001

Browse files
committed
Doc cds export
1 parent 3407ddb commit 8e3d001

File tree

2 files changed

+66
-0
lines changed

2 files changed

+66
-0
lines changed

tools/assets/cds-export.png

69.7 KB
Loading

tools/cds-cli.md

Lines changed: 66 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -468,6 +468,72 @@ To customize the diagram layout, use these settings in the _Cds > Preview_ categ
468468
- [Diagram: Namespaces](vscode://settings/cds.preview.diagram.namespaces)
469469
- [Diagram: Queries](vscode://settings/cds.preview.diagram.queries)
470470

471+
472+
## cds export
473+
474+
With `cds export` you create an API client package to be used
475+
for data exchange via CAP-level Service integration ("Calesi").
476+
477+
First define a data provider service in your CDS model that serves as an
478+
interface to your data. Put each such data provider service in a separate file.
479+
480+
For the [xflights](https://github.com/capire/xflights) sample app,
481+
an API that provides information about flights, airports, and airlines
482+
could look like this:
483+
484+
::: code-group
485+
486+
```cds [srv/data-service.cds]
487+
using { sap.capire.flights as my } from '../db/schema';
488+
489+
@data.product @hcql @rest @odata
490+
service sap.capire.flights.data {
491+
@readonly entity Flights as projection on my.Flights;
492+
@readonly entity Airlines as projection on my.Airlines;
493+
@readonly entity Airports as projection on my.Airports;
494+
}
495+
```
496+
497+
:::
498+
499+
Then create an API client package for this service:
500+
501+
```sh
502+
cds export srv/data-service.cds
503+
```
504+
505+
The API client package is generated into a new folder _apis/data-service_.
506+
507+
![The screenshot is described in the accompanying text.](assets/cds-export.png) {style="filter: drop-shadow(0 2px 5px rgba(0,0,0,.40));"}
508+
509+
The `service.csn` contains only the interface defined in the service,
510+
stripping away the query part of the entities and all the model underneath it.
511+
In addition, there are i18n bundles with the localized metadata relevant
512+
for the interface, and a _data_ folder with test data
513+
that exactly matches the structure of the entities in the API.
514+
515+
`cds export` also adds a _package.json_. The package name is the
516+
application name (from the main _package.json_) prefixed with the
517+
file name of the data service, in our example `@capire/xflights-data-service`.
518+
You can change this name as appropriate.
519+
520+
The generated package can then be published, e.g. via `npm publish`.
521+
522+
For consuming the API in another CAP application
523+
* import the API package with `npm add`
524+
* define consumption views on the imported entities
525+
* use them in your model as if they were local entities
526+
* add custom code to access the data in the provider app via any of the offered protocols
527+
528+
Have a look at the [xtravels](https://github.com/capire/xtravels) sample app for an
529+
example of using an API client package.
530+
531+
With the possibility to export and import API packages via `cds export` and `npm add`,
532+
you no longer have to use EDMX (or OpenAPI) as intermediate format for exchanging API information
533+
between CAP applications, with the known problem of loosing information.
534+
535+
536+
471537
## cds watch
472538

473539
Use `cds watch` to watch for changed files, restarting your Node.js server.

0 commit comments

Comments
 (0)