CAP-level Data Federation

A Devtoberfest 2026 session (CAP-31) on letting one CAP application read another's data as if it were local. The modelling half is the same for both answers, which is why the two technical edges hold: the provider defines an API service and exports it with CDS export as an npm package carrying the model, mock data and translated texts, the consumer imports it and puts consumption views on top, and only then is it wired either as service-level replication that copies the rows into local tables each time the server starts, or over the SAP HANA synonyms that cds-federation-synonymscds-federation-synonymscds-pluginAn experimental CAP plugin for CAP-to-CAP data federation over SAP HANA synonyms, so one project reads another's tables without the rows being copied.sap official, cap generates, with HDI grants on the provider side and a service replacement that redirects each synonym from its mock table to the provider's container. It is worked through on xflightsxflightssampleA reuse package serving master-data entities (Airlines, Airports and Flights) as a service that other CAP applications compose into their own data model.sap official, cap and xtravelsxtravelssampleA travel-booking application built on the master data that xflights publishes, composing another package's schema into its own rather than owning master data itself.sap official, cap, including the local run where CDS watch mocks the imported service from the CSV files inside the package.