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/inner-loops.md
+8-8Lines changed: 8 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -56,7 +56,7 @@ npm install
56
56
57
57
## Mocked Out of the Box
58
58
59
-
Within the context of application service integration and microservice architecture, we'd need to mock remote services in a consuming app to reach inner loop. CAP greatly does that for us, based on:
59
+
Within the context of application service integration and microservice architecture, we'd need to mock remote services in a consuming app to reach an inner loop. CAP handles this automatically for us, based on:
60
60
61
61
- A CDS service definition is all we need to serve a fully functional OData service
62
62
- APIs imported via `cds export` and `cds import` are CDS service definition
@@ -138,11 +138,11 @@ We can also use `cds mock` to mock remote services in separate processes, which
138
138
139
139
> [!tip] Decoupled Development → Contracts First
140
140
>
141
-
> Local inner loops allow promote decoupled development of separate parts / applications / microservices in larger solution projects. Each team can focus on their local domain and functionality with the required remote services mocked for them based on imported APIs. These APIs are the contracts between the individual teams.
141
+
> Local inner loops allow promoting decoupled development of separate parts / applications / microservices in larger solution projects. Each team can focus on their local domain and functionality with the required remote services mocked for them based on imported APIs. These APIs are the contracts between the individual teams.
142
142
143
143
> [!tip] Fast-track Inner-Loop Development → Spawning Parallel Tracks
144
144
>
145
-
> The mocked-out-of-the-box capabilities of CAP, with remoted services mocked in-process and a shared in-memory database, allows us to greatly speed up development and time to market. For real remote operations there is additional investment required, of course. But the agnostic nature of CAP-level Service Integration also allows you to spawn two working tracks running in parallel: One team to focus on domain and functionality, and another one to work on the integration logic under the hood.
145
+
> The mocked-out-of-the-box capabilities of CAP, with remote services mocked in-process and a shared in-memory database, allows us to greatly speed up development and time to market. For real remote operations there is additional investment required, of course. But the agnostic nature of CAP-level Service Integration also allows you to spawn two working tracks running in parallel: One team to focus on domain and functionality, and another one to work on the integration logic under the hood.
So far we assumed we mainly wirked within the *xtravels* project, and we consumed thte APIs from xflights via `npm publish` / `npm install`. There might be situations where we would want to shortcut this process. For example, we might want to consume a very latest version of the xflights API, which is not yet published to the *npm* registry. Or we might even want to work on both projects simultaneously, and test our latest changes to *xflights* in *xtravels* in close loops.
326
+
So far we assumed we mainly worked within the *xtravels* project, and we consumed the API from xflights via `npm publish` / `npm install`. There might be situations where we would want to shortcut this process. For example, we might want to consume a very latest version of the xflights API, which is not yet published to the *npm* registry. Or we might even want to work on both projects simultaneously, and test our latest changes to *xflights* in *xtravels* in close loops.
327
327
328
328
So, in essence, instead of exercising a workflow like that again and again:
Copy file name to clipboardExpand all lines: guides/protocols/odata.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -40,7 +40,7 @@ OData is an OASIS standard that enhances plain REST with standardized system que
40
40
|[Parameters Aliases](https://docs.oasis-open.org/odata/odata/v4.01/os/part1-protocol/odata-v4.01-os-part1-protocol.html#sec_ParameterAliases)| Replace literal value in URL with parameter alias | <X/> | <X/> <sup>(4)</sup> |
41
41
42
42
- <sup>(1)</sup> The elements to be searched are specified with the [`@cds.search` annotation](../services/served-ootb#searching-data).
43
-
- <sup>(2)</sup> Node.js only supports a limited subset in `$select` query option.
43
+
- <sup>(2)</sup> Node.js only supports a limited subset.
44
44
- <sup>(3)</sup> The navigation path identifying the collection can only contain one segment.
45
45
- <sup>(4)</sup> Supported for key values and for parameters of functions only.
[Managed fields](../guides/domain/index#managed-data) and [UUIDs](../guides/domain/index#prefer-uuids-for-keys) are automatically filled with `INSERT.entries()`, but not when using `INSERT.columns().values()` or `INSERT.columns().rows()`.
![renovate[bot]](https://avatars.githubusercontent.com/in/2740?v=4&size=40){kind=avatar}
0 commit comments