You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: guides/integration/data-federation.md
+213Lines changed: 213 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,6 +4,219 @@ CAP applications can integrate and federate data from multiple external data sou
4
4
{.abstract}
5
5
6
6
7
+
## Introduction
8
+
9
+
Displaying external data in lists commonly requires fast access to that data. Relying on live calls to remote services per row is clearly not an option, as that would lead to poor performance, excessive load on server, and a nightmare regarding resilience. Instead, we somehow need to ensure that all required data is available locally, so that it can be accessed fast and reliably by UIs, using good old SQL JOINs.
10
+
11
+
For example, we saw the need for that already in the [CAP-level Service Integration](calesi.md#coding-required) guide, where the `Customer` field in the travel requests list is populated from the remote S/4 Business Partner service, but missing when running the services separately:
12
+
13
+
1. First run these commands **in two separate terminals**:
14
+
15
+
```shell
16
+
cds mock apis/capire/s4.cds
17
+
```
18
+
```shell
19
+
cds mock apis/capire/xflights.cds
20
+
```
21
+
22
+
2. Start the xtravels server as usual **in a third terminal**, and note that it now _connects_ to the other services instead of mocking them:
23
+
24
+
```shell
25
+
cds watch
26
+
```
27
+
```zsh
28
+
[cds] - connect to S4BusinessPartnerService > odata {
[cds] - connect to sap.capire.flights.data > hcql {
34
+
url: 'http://localhost:54475/hcql/data'
35
+
}
36
+
```
37
+
38
+
2. Open the Fiori UI in the browser again -> data from the S/4 service is missing now, as we have not yet implemented the required custom code for the actual data integration, the same applies to the flight data from _xflights_:
39
+
40
+
41
+
42
+
43
+
44
+
In addition, when we again look into the log output, we see some bulk requests like shown below, which indicates that the Fiori client is desparately trying to fetch the missing customer data. If we'd scroll the list in the UI this would repeat like crazy.
In the xtravels app we accomplished that with a simple, yet quite effective data replication solution, which automatically replicates data as follows...
84
+
85
+
86
+
## Federated Consumption Views
87
+
88
+
Tag [consumption views](calesi#consumption-views) with the `@federated` annotation, to express your intent to have that data federated, i.e. in close access locally, for example:
89
+
90
+
```cds :line-numbers=4
91
+
@federated entity Customers as projection on S4.A_BusinessPartner { ... }
> By tagging entities with `@federated` we stay _intentional_ about **_what_** we want to achieve, and avoid any premature assumptions about **_how_** things are actually implemented. => This allows CAP runtimes – or your own _generic_ solutions, as in this case – to choose the best possible implementation strategies for the given environment and use case, which may differ between development, testing, and production environments, or might need to evolve over time.
97
+
98
+
99
+
## Generic Implementation
100
+
101
+
Here's the complete code, placed in file `srv/data-federation.js`:
Let's have a closer look at this code, which handles these main tasks:
147
+
148
+
1. **Prepare Persistence** – When the model is `loaded`, before it's deployed to the database, we collect all to be `@federated` entities, check whether their respective services are remote, and if so, turn them into tables forlocal replicas (line 11).
149
+
150
+
2. **Setup Replication** – Later when all services are `served`, we connect to each remote one (line 20), register a handler for replication (line 21), and schedule it to be invoked every three seconds (line 22).
151
+
152
+
3. **Replicate Data** – Finally, the `replicate` handler implements a simple polling-based data federation strategy, based on `modifiedAt` timestamps (lines 28-32), with the actual call to remote happening on line 29.
153
+
154
+
> [!tip] CAP-level Querying -> agnostic to databases & protocols
155
+
> We work with **database-agnostic** and **protocol-agnostic** [CQL queries](../../cds/cql) both for interacting with the local database as well as for querying remote services. In effect, we got a fully generic solution for replication, i.e., it works for**_any_** remote service that supports OData, or HCQL.
156
+
157
+
158
+
### Test Drive Locally
159
+
160
+
Let's see the outcome in action: to activate the above data federation code, edit `srv/server.js` file and uncomment the single line of code in there like this:
Finally, open the Fiori UI in the browser again, and see that customer data from S/4 as well as flight data from xflights is now displayed properly, thanks to the data federation implemented above.
213
+
214
+
215
+
216
+
0 commit comments