From 6373ad2f242b6ead5c59984794bb213db2ed02d6 Mon Sep 17 00:00:00 2001 From: Rene Jeglinsky Date: Tue, 7 Jul 2026 08:23:12 +0200 Subject: [PATCH 1/3] fix: replace i.e. --- cds/models.md | 2 +- get-started/bookshop.md | 2 +- get-started/concepts.md | 13 ++++++++----- guides/databases/cdl-to-ddl.md | 2 +- guides/integration/calesi.md | 8 ++++---- guides/integration/data-federation.md | 4 ++-- guides/protocols/mcp.md | 2 +- guides/security/cap-users.md | 2 +- guides/services/constraints.md | 4 ++-- guides/uis/i18n.md | 2 +- java/working-with-cql/query-api.md | 4 ++-- node.js/cds-compile.md | 2 +- node.js/cds-ql.md | 2 +- node.js/core-services.md | 2 +- node.js/events.md | 2 +- node.js/fiori.md | 4 ++-- 16 files changed, 30 insertions(+), 27 deletions(-) diff --git a/cds/models.md b/cds/models.md index ab67d21abc..d0cdd739c0 100644 --- a/cds/models.md +++ b/cds/models.md @@ -20,7 +20,7 @@ For example, a *data model describes the type structure (commonly also called *' ### Representations -Models can come in different *representations*, which follow different *syntaxes*. For example, we use the *CDL* syntax for *human-readable* representations of CDS models, while CSN is an *object notation*, i.e. a special form of *syntax*, used for *machine-readable* representations of CDS models. +Models can come in different *representations*, which follow different *syntaxes*. For example, we use the *CDL* syntax for *human-readable* representations of CDS models, while CSN is an *object notation*, that is a special form of *syntax*, used for *machine-readable* representations of CDS models. ::: details On CSN representations... diff --git a/get-started/bookshop.md b/get-started/bookshop.md index b97a71973a..cae5e2d08b 100644 --- a/get-started/bookshop.md +++ b/get-started/bookshop.md @@ -135,7 +135,7 @@ entity Genres : sap.common.CodeList { ###### Focus on Domain > [!tip] Primary Focus on Domain -> Strive to keep your domain models simple, concise and comprehensible, focused on the core concepts of your domain, i.e., [_“Keep it simple, stupid!”_](https://en.wikipedia.org/wiki/kiss_principle). Factor out secondary concerns into separate sources, which _extend_ and _annotate_ the core models.\ +> Strive to keep your domain models simple, concise and comprehensible, focused on the core concepts of your domain, that is, [_“Keep it simple, stupid!”_](https://en.wikipedia.org/wiki/kiss_principle). Factor out secondary concerns into separate sources, which _extend_ and _annotate_ the core models.\ > See also: [_Separation of Concerns_](#separation-of-concerns). [Learn more about _Domain Modeling_.](../guides/domain/index){ .learn-more} diff --git a/get-started/concepts.md b/get-started/concepts.md index 7d46dc852d..dcf3722cc3 100644 --- a/get-started/concepts.md +++ b/get-started/concepts.md @@ -44,7 +44,7 @@ The major building blocks are as follows: - [**Core Data Services** (CDS)](../cds/) — CAP's universal modeling language, and the very backbone of everything; used to capture domain knowledge, generating database schemas, translating to and from various API languages, and most important: fueling generic runtimes to automatically serve request out of the box. -- [**Service Runtimes**](../guides/services/providing-services) for [Node.js](../node.js/) and [Java](../java/) — providing the core frameworks for services, generic providers to serve requests automatically, database support for SAP HANA, SQLite, and PostgreSQL, and protocol adaptors for REST, OData, GraphQL, ... +- [**Service Runtimes**](../guides/services/providing-services) for [Node.js](../node.js/) and [Java](../java/) — providing the core frameworks for services, generic providers to serve requests automatically, database support for SAP HANA, SQLite, and PostgreSQL, and protocol adapters for REST, OData, GraphQL, ... - [**Platform Integrations**](../plugins/) — providing CAP-level service interfaces (*'[Calesi](#the-calesi-pattern)'*) to cloud platform services in platform-agnostic ways, as much as possible. Some of these are provided out of the box, others as plugins. @@ -702,12 +702,15 @@ Your application models are your services, also served automatically by generic ### Protocol Adapters -Behind the scenes, i.e., in the **outer hexagon** containing stuff, you as an application developer should not see, the CAP runtime employs Protocol Adapters, which translate requests from (and to) low-level protocols like HTTP, REST, OData, GraphQL, ... to protocol-agnostic CAP requests and queries. +Behind the scene - that is, in the **outer hexagon** containing stuff, you as an application developer should not see - the CAP runtime employs Protocol Adapters, which translate requests from (and to) low-level protocols like HTTP, REST, OData, GraphQL, ... to protocol-agnostic CAP requests and queries for inbound and outbound communication. -- for ***inbound*** communication → i.e., requests your application *receives*, as well as as... -- for ***outbound*** communication → i.e., requests your application *sends* to other services. +--> ***Inbound*** Communication +: Requests your application *receives*. -In effect your service implementations stay agnostic to (wire) protocols, which allows us to exchange protocols, replace targets by mocks, do fast inner loop development in airplane mode, ... even change topologies from a monolith to micro services and vice versa late in time. +--> ***Outbound*** Communication +: Requests your application *sends* to other services. + +In effect your service implementations stay agnostic to (wire) protocols, which allows you to exchange protocols, replace targets by mocks, do fast inner loop development in airplane mode, ... even change topologies from a monolith to micro services and vice versa late in time. ![protocol-adapters.drawio](./assets/concepts/protocol-adapters.drawio.svg) diff --git a/guides/databases/cdl-to-ddl.md b/guides/databases/cdl-to-ddl.md index db3239c71f..d7d5bfef17 100644 --- a/guides/databases/cdl-to-ddl.md +++ b/guides/databases/cdl-to-ddl.md @@ -735,7 +735,7 @@ CREATE VIEW Bar AS SELECT ... FROM Foo; -- skipped [!code --] > All parts of the view definition not relevant for the signature, such as `where`, `group by`, `having`, `order by`, or `limit`, are ignored. > [!tip] Use Case: Replica Caching Tables -A common use case for this annotation is to create projections on entities from imported APIs, i.e., so-called _consumption views_, and at the same time use them as replica cache tables. +A common use case for this annotation is to create projections on entities from imported APIs, so-called _consumption views_, and at the same time use them as replica cache tables. diff --git a/guides/integration/calesi.md b/guides/integration/calesi.md index 1a6669341f..4e578cb7aa 100644 --- a/guides/integration/calesi.md +++ b/guides/integration/calesi.md @@ -55,7 +55,7 @@ The graphic below illustrates what happened here: ![Diagram illustrating CAP-level service integration showing two scenarios: Local services where Consumer connects to Service via CQL, and Remote services where Consumer connects to Proxy via CQL, Proxy connects to Protocol Adapter via OData, and Protocol Adapter connects to Service via CQL. ](assets/remoting.drawio.svg) -Remote CAP services can be consumed using the same high-level, uniform APIs as for local services – i.e., **_as if they were local_**. `cds.connect` automatically constructs remote proxies, which translate all local requests into protocol-specific ones, sent to remote services. Thereby also taking care of all connectivity, remote communication, principal propagation, as well as generic resilience. +Remote CAP services can be consumed using the same high-level, uniform APIs as for local services – that is, **_as if they were local_**. `cds.connect` automatically constructs remote proxies, which translate all local requests into protocol-specific ones, sent to remote services. Thereby also taking care of all connectivity, remote communication, principal propagation, as well as generic resilience. > [!note] Model Free > @@ -860,9 +860,9 @@ const xflights = await cds.connect.to ('sap.capire.flights.data') The `cds.connect.to()` function used here is the single common way to address service instances. It's used for and works the same way for both, local as well as remote services: -- for **local** services, it returns the local service providers – i.e., instances of [`cds.ApplicationService`](../../node.js/app-services), or your application-specific subclases thereof. +- for **local** services, it returns the local service providers – that is, instances of [`cds.ApplicationService`](../../node.js/app-services), or your application-specific subclasses thereof. -- for **remote** services, it returns a remote service proxy – i.e., instances of [`cds.RemoteService`](../../node.js/remote-services), generically constructed by the client libs. +- for **remote** services, it returns a remote service proxy – that is, instances of [`cds.RemoteService`](../../node.js/remote-services), generically constructed by the client libs. ![Diagram illustrating CAP-level service integration showing two scenarios: Local services where Consumer connects to Service via CQL, and Remote services where Consumer connects to Proxy via CQL, Proxy connects to Protocol Adapter via OData, and Protocol Adapter connects to Service via CQL. ](assets/remoting.drawio.svg) @@ -1200,7 +1200,7 @@ Note that for the handler above, incoming requests always refer to: In effect, we are delegating a query to the S/4 service, which refers to an entity actually not known to that remote service. How could that work at all? -It works because we fuelled the CAP runtime with CDS models, so the generic handlers detect such situations, and automatically translate delegated queries into valid queries targeted to underlying remote entities – i.e. `A_BusinessPartner` in our example. When doing so, all column references in select clauses, where clauses, etc., are translated and delegated as well, and the results' structure transformed back to that of the original target – i.e., `TravelService.Customers` above. +It works because we fuelled the CAP runtime with CDS models, so the generic handlers detect such situations, and automatically translate delegated queries into valid queries targeted to underlying remote entities – that is, `A_BusinessPartner` in our example. When doing so, all column references in select clauses, where clauses, etc., are translated and delegated as well, and the results' structure transformed back to that of the original target – that is, `TravelService.Customers` above. diff --git a/guides/integration/data-federation.md b/guides/integration/data-federation.md index 5dda8407ed..ba5b912f03 100644 --- a/guides/integration/data-federation.md +++ b/guides/integration/data-federation.md @@ -102,7 +102,7 @@ npm install ## Federated Consumption Views -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, we did so in our consumption view for entities imported from XFlights as well as for the S/4 Business Partners entity: +Tag [consumption views](calesi#consumption-views) with the `@federated` annotation, to express your intent to have that data federated, that is, in close access locally. For example, we did so in our consumption view for entities imported from XFlights as well as for the S/4 Business Partners entity: ::: code-group @@ -183,7 +183,7 @@ Let's have a closer look at this code, which handles these main tasks: 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. > [!tip] CAP-level Querying -> agnostic to databases & protocols -> 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. +> 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, that is, it works for **_any_** remote service that supports OData, or HCQL. ## Test Drive Locally diff --git a/guides/protocols/mcp.md b/guides/protocols/mcp.md index f63dc6e271..c0b73c3292 100644 --- a/guides/protocols/mcp.md +++ b/guides/protocols/mcp.md @@ -374,7 +374,7 @@ During startup, the generated MCP servers and their URL are added to the client- When the application stops, the added configuration is removed. This is only intended for local development. > [!warning] For Development Only -> The autowiring is only enabled during development (i.e., when running `cds watch` or `mvn cds:watch`) and not meant for production use cases. +> The autowiring is only enabled during development (that is, when running `cds watch` or `mvn cds:watch`) and not meant for production use cases. #### Mock Authentication diff --git a/guides/security/cap-users.md b/guides/security/cap-users.md index a82fcf1347..c23ca5a9d0 100644 --- a/guides/security/cap-users.md +++ b/guides/security/cap-users.md @@ -1206,7 +1206,7 @@ In addition, there are getters to retrieve information about [pseudo-roles](#pse | `isAuthenticated()` | _True if the current user has been authenticated._ | `authenticated-user` | | `isSystemUser()` | _Indicates whether the current user has pseudo-role `system-user`._ | `system-user` | | `isInternalUser()` | _Indicates whether the current user has pseudo-role `internal-user`._ | `internal-user` | -| `isPrivileged()` | _Returns `true` if the current user runs in [privileged mode](#switching-to-privileged-user), i.e. is unrestricted._ | - | +| `isPrivileged()` | _Returns `true` if the current user runs in [privileged mode](#switching-to-privileged-user), that is is unrestricted._ | - | diff --git a/guides/services/constraints.md b/guides/services/constraints.md index 03b62e5cf0..b54435f53a 100644 --- a/guides/services/constraints.md +++ b/guides/services/constraints.md @@ -454,7 +454,7 @@ entity Person : cuid { ### Localized Messages -Whenever you specify an error message with the annotations above, i.e., in the `then` part of an `@assert: ()` or in `@mandatory.message`, `@assert.format.message`, or `@assert.range.message`, you can either specify a plain text, or a [I18n text bundle key](../uis/i18n#externalizing-texts-bundles). +Whenever you specify an error message with the annotations above, that is, in the `then` part of an `@assert: ()` or in `@mandatory.message`, `@assert.format.message`, or `@assert.range.message`, you can either specify a plain text, or a [I18n text bundle key](../uis/i18n#externalizing-texts-bundles). Actually, we saw this already in the [sample in the introduction](#introduction): @@ -499,7 +499,7 @@ If you use a message key, the message is automatically looked up in the message ## Field Control -Declarative constraints can also be used to do field control in Fiori UIs, i.e. to add visual indicators to mandatory or readonly fields, or to hide fields. In particular, CAP automatically adds respective OData annotations to generated EDMX $metadata documents for the CDS listed below. +Declarative constraints can also be used to do field control in Fiori UIs, that is, to add visual indicators to mandatory or readonly fields, or to hide fields. In particular, CAP automatically adds respective OData annotations to generated EDMX $metadata documents for the CDS listed below. ### `@mandatory` diff --git a/guides/uis/i18n.md b/guides/uis/i18n.md index 840afa2747..22631c7a7b 100644 --- a/guides/uis/i18n.md +++ b/guides/uis/i18n.md @@ -73,7 +73,7 @@ bookshop/ -By default, text bundles are fetched from folders named *_i18n* or *i18n* in the neighborhood of models, i.e. all folders that contain `.cds` sources or parent folders thereof. For example, given the following project layout and sources: +By default, text bundles are fetched from folders named *_i18n* or *i18n* in the neighborhood of models, that is, all folders that contain `.cds` sources or parent folders thereof. For example, given the following project layout and sources: ```zsh bookshop/ diff --git a/java/working-with-cql/query-api.md b/java/working-with-cql/query-api.md index 34af880760..9c03f4dbec 100644 --- a/java/working-with-cql/query-api.md +++ b/java/working-with-cql/query-api.md @@ -188,7 +188,7 @@ Select.from(BOOKS).byParams("title", "author.name"); #### Filtering Map Data -You can also filter by _content_ of [map data](../cds-data.md#cds-map) (i.e. elements of type `cds.Map`). +You can also filter by _content_ of [map data](../cds-data.md#cds-map) (that is, elements of type `cds.Map`). Let's use this model as an example: @@ -899,7 +899,7 @@ The pagination isn't stateful. If rows are inserted or removed before a subseque #### Sorting by Map Data -You can also sort by _content_ of [map data](../cds-data.md#cds-map) (i.e. elements of type `cds.Map`). Considering this model +You can also sort by _content_ of [map data](../cds-data.md#cds-map) (that is, elements of type `cds.Map`). Considering this model ```cds entity Product : cuid { diff --git a/node.js/cds-compile.md b/node.js/cds-compile.md index a70e9c1763..de3d9f1532 100644 --- a/node.js/cds-compile.md +++ b/node.js/cds-compile.md @@ -462,7 +462,7 @@ This is the right place to, for example, add custom elements required at runtime ### compile.to.dbx {.event} -Emitted every time before database-specific artifacts, i.e. SQL DDL scripts, are generated from the model. +Emitted every time before database-specific artifacts, that is, SQL DDL scripts, are generated from the model. This is the right place to, for example, add custom elements required in your persistence. diff --git a/node.js/cds-ql.md b/node.js/cds-ql.md index 29b2f0899c..64277c4037 100644 --- a/node.js/cds-ql.md +++ b/node.js/cds-ql.md @@ -205,7 +205,7 @@ let input = 201 //> might be entered by end users let books = await SELECT.from `Books` .where ('ID='+input) let bookz = await SELECT.from `Books` .where (`ID=${input}`) ``` -> **Note** also that tagged template strings never have surrounding parentheses! I.e., the third line above does the very same string concatenation as the second line. +> **Note** also that tagged template strings never have surrounding parentheses! That means, the third line above does the very same string concatenation as the second line. A malicious user might enter some SQL code fragment like that: diff --git a/node.js/core-services.md b/node.js/core-services.md index 8ea29f4681..c7b7802544 100644 --- a/node.js/core-services.md +++ b/node.js/core-services.md @@ -535,7 +535,7 @@ class BooksService extends cds.ApplicationService { **Argument `entity`** can be one of: -- A `CSN definition` of an entity served by this service → i.e., from [`this.entities`](#entities) +- A `CSN definition` of an entity served by this service → from [`this.entities`](#entities) - A `string` corresponding to the _name_ of an entity served by this service - A `path` navigating from a served entity to associated ones → e.g., `Books/author` diff --git a/node.js/events.md b/node.js/events.md index c9f325a6f1..db378cce47 100644 --- a/node.js/events.md +++ b/node.js/events.md @@ -545,7 +545,7 @@ All errors are collected in property `req.errors`, which is initially `undefined if (req.errors) ... //> errors occurred ``` -After each phase of request processing, i.e. _before_ / _on_ / _after_, the framework checks whether errors got recorded in `req.errors`. If so, it automatically [rejects](#req-reject) the request with an aggregate error containing all recorded errors, and the request is not processed further. So, in essence, the above ends up in the equivalent of: +After each phase of request processing, that is, _before_ / _on_ / _after_, the framework checks whether errors got recorded in `req.errors`. If so, it automatically [rejects](#req-reject) the request with an aggregate error containing all recorded errors, and the request is not processed further. So, in essence, the above ends up in the equivalent of: ```js return req.reject ({ diff --git a/node.js/fiori.md b/node.js/fiori.md index fd09ec3efd..dce63a3a7d 100644 --- a/node.js/fiori.md +++ b/node.js/fiori.md @@ -79,7 +79,7 @@ srv.on('EDIT', MyEntity, /*...*/) The `EDIT` event is triggered when the user starts editing an active entity. As a result, a new entry to `MyEntity.drafts` is created. -For logical reasons handlers for the `EDIT` event are registered on the active entity, i.e. `MyEntity` in the code above, not on the `MyEntity.drafts` entity. +For logical reasons handlers for the `EDIT` event are registered on the active entity, that is, `MyEntity` in the code above, not on the `MyEntity.drafts` entity. ### `PATCH` @@ -105,7 +105,7 @@ srv.on('SAVE', MyEntity.drafts, /*...*/) The `SAVE` event is triggered when the user saves / activates a draft. This results in either a CREATE or an UPDATE on the active entity depending on whether the draft was created via `NEW` or `EDIT`. > [!note] -> The `SAVE` event is also available for non-draft, i.e. active entities. In that case it acts as an convenience shortcut for registering handlers for the combination of `CREATE` and `UPDATE` events. In contrast to that, the `SAVE` event on draft entities is a distinct event that is only triggered when **activating** a draft. +> The `SAVE` event is also available for non-draft, that is, active entities. In that case it acts as an convenience shortcut for registering handlers for the combination of `CREATE` and `UPDATE` events. In contrast to that, the `SAVE` event on draft entities is a distinct event that is only triggered when **activating** a draft. From 26ccb7cca3c8e05ae81e68f28756037924295011 Mon Sep 17 00:00:00 2001 From: Rene Jeglinsky Date: Tue, 7 Jul 2026 11:52:02 +0200 Subject: [PATCH 2/3] replace e.g. --- cds/cxl.md | 2 +- cds/types.md | 4 ++-- get-started/bookshop.md | 2 +- get-started/concepts.md | 2 +- guides/databases/initial-data.md | 2 +- guides/databases/schema-evolution.md | 2 +- guides/deploy/cicd.md | 4 ++-- guides/integration/calesi.md | 8 ++++---- guides/integration/platform/attachments.md | 2 +- guides/integration/platform/ias-xsuaa.md | 2 +- guides/protocols/mcp.md | 8 ++++---- guides/security/authentication.md | 2 +- guides/security/cap-users.md | 2 +- guides/services/constraints.md | 2 +- guides/uis/i18n.md | 2 +- java/building-plugins.md | 2 +- java/event-handlers/indicating-errors.md | 2 +- java/security.md | 2 +- node.js/cds-connect.md | 2 +- node.js/cds-ql.md | 2 +- node.js/cds-reflect.md | 2 +- node.js/core-services.md | 10 ++++++---- node.js/events.md | 2 +- 23 files changed, 36 insertions(+), 34 deletions(-) diff --git a/cds/cxl.md b/cds/cxl.md index fe41f9a421..7f8ec13f4d 100644 --- a/cds/cxl.md +++ b/cds/cxl.md @@ -234,7 +234,7 @@ This syntax diagram describes the possible expressions: ### In Queries - Expressions can be used in various parts of a query, e.g., on the select list, in the where clause, in order by clauses, and more: + Expressions can be used in various parts of a query, for example,, on the select list, in the where clause, in order by clauses, and more: ```cds live SELECT from Books { diff --git a/cds/types.md b/cds/types.md index c876abf6da..748431d5e7 100644 --- a/cds/types.md +++ b/cds/types.md @@ -24,8 +24,8 @@ ANSI SQL types, when deployed to a relational database (concrete mappings to spe | `UInt8` | Unsigned 8-bit integer, range *[ 0 ... 255 ]* | _TINYINT_ | | `Decimal`(`p`,`s`) | Decimal with precision `p` and scale `s` | _DECIMAL_ | | `Double` | Floating point with binary mantissa | _DOUBLE_ | -| `Date` | e.g. `2022-12-31` | _DATE_ | -| `Time` | e.g. `23:59:59` | _TIME_ | +| `Date` | for example, `2022-12-31` | _DATE_ | +| `Time` | for example, `23:59:59` | _TIME_ | | `DateTime` | _sec_ precision | _TIMESTAMP_ | | `Timestamp` | _µs_ precision, with up to 7 fractional digits | _TIMESTAMP_ | | `String` (`length`) | Default *length*: 255; on HANA: 5000 | _NVARCHAR_ | diff --git a/get-started/bookshop.md b/get-started/bookshop.md index cae5e2d08b..bdd3a0e5db 100644 --- a/get-started/bookshop.md +++ b/get-started/bookshop.md @@ -597,7 +597,7 @@ We can also send such OData requests programmatically, for example, doing the ve await cds.service.bindings ``` ::: details About _cds.service.bindings_ ... - The `cds.service.bindings` command fetches the service bindings from a running CAP server instance in another process, and makes them available in the current process, e.g., within `cds repl`. + The `cds.service.bindings` command fetches the service bindings from a running CAP server instance in another process, and makes them available in the current process, for example, within `cds repl`. ```js [cds] - using bindings from: { registry: '~/.cds-services.json' } Bindings { diff --git a/get-started/concepts.md b/get-started/concepts.md index dcf3722cc3..235f0049f6 100644 --- a/get-started/concepts.md +++ b/get-started/concepts.md @@ -150,7 +150,7 @@ INNER JOIN Countries as country ON country.code = author.country_code -- the actual filter condition: WHERE country.code = 'GB'; ``` -Path expressions in *infix filters* become *SEMI JOINs*, e.g.using `IN`: +Path expressions in *infix filters* become *SEMI JOINs*, for example, using `IN`: ```sql CREATE VIEW EnglishBooks AS SELECT * FROM Books -- for Association Books:author: diff --git a/guides/databases/initial-data.md b/guides/databases/initial-data.md index 86db8bc40b..8066d7d866 100644 --- a/guides/databases/initial-data.md +++ b/guides/databases/initial-data.md @@ -138,7 +138,7 @@ cds: ``` ::: -Use `cds env` to check which configuration is active in your current profile, e.g.: +Use `cds env` to check which configuration is active in your current profile, for example: ```shell cds env requires.db.data --profile development ``` diff --git a/guides/databases/schema-evolution.md b/guides/databases/schema-evolution.md index 78c21f27bb..e12a4c81ec 100644 --- a/guides/databases/schema-evolution.md +++ b/guides/databases/schema-evolution.md @@ -115,7 +115,7 @@ Let's simulate the workflow with the [@capire/bookshop](https://github.com/capir Some changes to the CDS model are considered disallowed in the context of schema evolution, as they could lead to data loss or inconsistencies. The following list shows examples of such changes: - Renaming entities or fields (instead, add new ones and migrate data) -- Changing data types in incompatible ways (e.g., from String to Integer) +- Changing data types in incompatible ways (for example, from String to Integer) - Removing entities or fields (instead, consider deprecating them first) - Reducing the length of strings or binary fields - Reducing the precision of numeric fields diff --git a/guides/deploy/cicd.md b/guides/deploy/cicd.md index 3a0f940f75..08d039af1e 100644 --- a/guides/deploy/cicd.md +++ b/guides/deploy/cicd.md @@ -103,13 +103,13 @@ For the actual release we want to override org-wide sandbox variables to deploy Go to **Settings** → **Environments** → **New environment** → enter "Production". -Now override org-wide variables (e.g. `CF_ORG` and `CF_SPACE` in Cloud Foundry) to use a dedicated subaccount you created for the release deployment. +Now override org-wide variables (for example `CF_ORG` and `CF_SPACE` in Cloud Foundry) to use a dedicated subaccount you created for the release deployment. #### Publish the release On your repository front page go to `Releases` → `Draft a new release` → `Select tag`. -Now enter a tag name, e.g. `v1.0.0` and select `Create new tag: v1.0.0 on publish`. +Now enter a tag name, for example, `v1.0.0` and select `Create new tag: v1.0.0 on publish`. You can optionally add a release title and release notes. Hit **Publish release** once you're ready. diff --git a/guides/integration/calesi.md b/guides/integration/calesi.md index 4e578cb7aa..62c9755833 100644 --- a/guides/integration/calesi.md +++ b/guides/integration/calesi.md @@ -459,7 +459,7 @@ This allows us to update imported APIs later on using standard commands like `np You can also `cds import` APIs from other sources, such as OData APIs for customer data from SAP S/4 HANA systems: -1. Get an [_OData EDMX_](https://api.sap.com/api/API_BUSINESS_PARTNER/overview) source, e.g., from [*SAP Business Accelerator Hub*](https://api.sap.com): +1. Get an [_OData EDMX_](https://api.sap.com/api/API_BUSINESS_PARTNER/overview) source, for example, from [*SAP Business Accelerator Hub*](https://api.sap.com): ::: details Detailed steps through SAP Business Accelerator Hub ... - Open https://api.sap.com in your browser @@ -630,7 +630,7 @@ namespace sap.capire.s4; The noteworthy aspects here are: -- We map names to match our domain, e.g., `A_Business_Partner` -> `Customers`, and choose simpler names for the elements we want to use. +- We map names to match our domain, for example, `A_Business_Partner` -> `Customers`, and choose simpler names for the elements we want to use. - For entity `Flights` we flatten data from associations directly into the consumption view. This is another [denormalization](#using-denormalized-views) to make life easier for us in the xtravels app. @@ -1080,7 +1080,7 @@ await s4.run (q2) > Modifying queries prior to forwarding them to remote services is a powerful technique to implement advanced integration scenarios. For example, you can adapt queries to the capabilities of target services, implement custom filtering, paging, or sorting logic, or even split and merge queries across multiple services. ::: details First-Class Query Objects -On a side note: We leverage key principles of [_first-class objects_](https://google.com/search?q=first+class+objects+programming) here, as known from functional programming and dynamic languages: As queries are represented as first-class CQN objects, we can construct and manipulate them programmatically at runtime, pass them as arguments, and return them from functions. And, not the least, this opens the doors for things like higher-order queries, query delegation – e.g. push down to databases –, and late materialization. +On a side note: We leverage key principles of [_first-class objects_](https://google.com/search?q=first+class+objects+programming) here, as known from functional programming and dynamic languages: As queries are represented as first-class CQN objects, we can construct and manipulate them programmatically at runtime, pass them as arguments, and return them from functions. And, not the least, this opens the doors for things like higher-order queries, query delegation – for example push down to databases –, and late materialization. ::: > [!warning] Always Clone Before Modifying @@ -1238,7 +1238,7 @@ await SELECT.from (Bookings) .where`Flight.ID in ${flightIDs}` ::: > [!tip] What is 'Navigation'? -> The term 'navigation' commonly refers to traversing associations between entities in queries. In CAP, this is typically expressed using [path expressions](../../cds/cql#path-expressions) along (chains of) associations – e.g., `flight.origin.name` –, which can show up in all query clauses (_select_, _from_, _where_, _order by_, and _group by_). +> The term 'navigation' commonly refers to traversing associations between entities in queries. In CAP, this is typically expressed using [path expressions](../../cds/cql#path-expressions) along (chains of) associations – for example, `flight.origin.name` –, which can show up in all query clauses (_select_, _from_, _where_, _order by_, and _group by_). ### Expands diff --git a/guides/integration/platform/attachments.md b/guides/integration/platform/attachments.md index b40c250afe..2a4a16a5d4 100644 --- a/guides/integration/platform/attachments.md +++ b/guides/integration/platform/attachments.md @@ -41,7 +41,7 @@ } ``` - 5. **Implement Attachment Logic**: In your service implementation file (e.g., `srv/your-service.js`), implement the logic to handle attachment operations such as upload, download, and delete. + 5. **Implement Attachment Logic**: In your service implementation file (for example, `srv/your-service.js`), implement the logic to handle attachment operations such as upload, download, and delete. 6. **Test Your Application**: Run your CAP application and test the attachment functionality to ensure everything is working as expected. diff --git a/guides/integration/platform/ias-xsuaa.md b/guides/integration/platform/ias-xsuaa.md index 0b736e0cc3..19ffc4fc25 100644 --- a/guides/integration/platform/ias-xsuaa.md +++ b/guides/integration/platform/ias-xsuaa.md @@ -11,7 +11,7 @@ It allows users to authenticate using various methods, including social logins, When integrated with CAP applications, IAS can serve as the primary identity provider, managing user identities and authentication flows. -To integrate IAS with a CAP application, you typically need to configure the application to trust IAS as an identity provider and set up the necessary SSO protocols (e.g., SAML, OAuth2). +To integrate IAS with a CAP application, you typically need to configure the application to trust IAS as an identity provider and set up the necessary SSO protocols (for example, SAML, OAuth2). For more details on configuring IAS with CAP applications, refer to the [SAP IAS documentation](https://help.sap.com/viewer/product/SAP_IDENTITY_AUTHENTICATION/). ## SAP Authorization and Trust Management Service (XSUAA) XSUAA is a service that provides authentication and authorization capabilities for applications running on SAP Business Technology Platform (BTP). diff --git a/guides/protocols/mcp.md b/guides/protocols/mcp.md index c0b73c3292..96268437ea 100644 --- a/guides/protocols/mcp.md +++ b/guides/protocols/mcp.md @@ -13,7 +13,7 @@ The [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) is an open- > [!note] > -> This guide is about the *MCP Adapter* – e.g. as provided through the [*@cap-js/mcp*](https://github.com/cap-js/mcp) plugin – which powers domain-specific application use cases, for example, to respond to questions for CAP-based applications like *"List all overstocked books"*. +> This guide is about the *MCP Adapter* – for example, as provided through the [*@cap-js/mcp*](https://github.com/cap-js/mcp) plugin – which powers domain-specific application use cases, for example, to respond to questions for CAP-based applications like *"List all overstocked books"*. > > In parallel, there's also the *MCP Server* plugin ([*@cap-js/mcp-server*](https://github.com/cap-js/mcp-server)), which serves a different purpose, though, that is: AI-assisted *development* of CAP projects. @@ -106,7 +106,7 @@ INFO com.sap.cds.adapter.mcp.McpServlet : MCP Server initialized at endpoint '/m ``` ::: -You can also specify an alternative path under which the MCP server should be served, e.g. like that: +You can also specify an alternative path under which the MCP server should be served as follows: ```cds annotate CatalogService with @mcp:'books' @@ -458,7 +458,7 @@ npx @modelcontextprotocol/inspector The inspector should automatically open in your browser. 1. Select _Streamable HTTP_ as Transport Type. -2. Enter the URL of your service (e.g., `http://localhost:4004/mcp/browse`). +2. Enter the URL of your service - for example, `http://localhost:4004/mcp/browse`. 3. Select `Via Proxy` as connection type and select _Connect_. 4. Go to the _Tools_ tab and select _List Tools_. 5. To get data, select the _query_ tool. @@ -492,4 +492,4 @@ Future versions of the adapter may add support for data changes using CREATE, UP > [!caution] > The MCP adapter does not perform any input validation or output validation regarding prompt injections. -> Hence, for production use cases ensure you use infrastructure and practices that mitigate prompt injection risks and connect only to trusted MCP agents (e.g., Joule). +> Hence, for production use cases ensure you use infrastructure and practices that mitigate prompt injection risks and connect only to trusted MCP agents (for example, Joule). diff --git a/guides/security/authentication.md b/guides/security/authentication.md index cf79bd2edb..e17bf86590 100644 --- a/guides/security/authentication.md +++ b/guides/security/authentication.md @@ -1252,7 +1252,7 @@ For these scenarios, the CAP Node.js runtime allows to specify an implementation :::warning Be **very** careful when creating your own `auth` implementation. -This should be a last resort for when every other possible solution (e.g. through [modelling](./authorization.md#restrictions) or by [configuration](#pluggable-authentication)) has been investigated and dismissed. +This should be a last resort for when every other possible solution (for example through [modelling](./authorization.md#restrictions) or by [configuration](#pluggable-authentication)) has been investigated and dismissed. ::: Like any other [custom middleware](../../node.js/cds-serve.md#custom-middlewares), the auth middleware you create needs to accept express's `req`, `res` and `next` and end up by sending a response, throwing an error or calling `next()`. diff --git a/guides/security/cap-users.md b/guides/security/cap-users.md index c23ca5a9d0..4114c6dc4a 100644 --- a/guides/security/cap-users.md +++ b/guides/security/cap-users.md @@ -762,7 +762,7 @@ If not done yet, prepare your project Cloud deployment as [explained before](./a Policies can be automatically deployed to the AMS server during deployment of the application by means of AMS deployer provided by module `@sap/ams`. -Enhancing the project by `cds add ams` automatically adds task e.g. in the MTA for AMS policy deployment. +Enhancing the project by `cds add ams` automatically adds task for example in the MTA for AMS policy deployment.
diff --git a/guides/services/constraints.md b/guides/services/constraints.md index b54435f53a..5e86675e23 100644 --- a/guides/services/constraints.md +++ b/guides/services/constraints.md @@ -73,7 +73,7 @@ annotate TravelService.Travels with { The constraints are enforced automatically by the CAP runtimes on any input, and if failures occur, the request is ultimately rejected and the transaction rolled back. -Some of the checks, e.g. the static `@mandatory` checks, are validated directly on the input data, while the ones specified with `@assert:(\)` are collected into a query and **pushed down to the database** for execution. This in turn means, that first the respective `INSERT`s and `UPDATE`s are sent to the database, followed by the validation query. +Some of the checks, for example, the static `@mandatory` checks, are validated directly on the input data, while the ones specified with `@assert:(\)` are collected into a query and **pushed down to the database** for execution. This in turn means, that first the respective `INSERT`s and `UPDATE`s are sent to the database, followed by the validation query. diff --git a/guides/uis/i18n.md b/guides/uis/i18n.md index 22631c7a7b..8bc2066df9 100644 --- a/guides/uis/i18n.md +++ b/guides/uis/i18n.md @@ -241,7 +241,7 @@ In effect, this means: - We support incoming locales as [language tags](https://www.ietf.org/rfc/bcp/bcp47.txt) using hyphens to separate sub tags 1, for example `en-GB`. - We always normalize these to underscores, which is `en_GB`. - Always use underscores in filenames, for example, `i18n_en_GB.properties` -- Always use underscores when filling `LOCALE` columns of localized text tables (e.g. in CSV files). +- Always use underscores when filling `LOCALE` columns of localized text tables (for example, in CSV files). 1 CAP Node.js also supports underscore separated tags, for example `en_GB`. diff --git a/java/building-plugins.md b/java/building-plugins.md index e14f749da2..d974205382 100644 --- a/java/building-plugins.md +++ b/java/building-plugins.md @@ -87,7 +87,7 @@ Additionally, the `resolve` goal from the CDS Maven Plugin needs to be added, to ::: ::: details Scope of the Reuse Package -Usually you would declare the dependency to the reuse package in the `srv` module of your CAP Java project. Since CAP Java 4.4.0 this makes the reuse models available to all CDS files in the CAP project. The models are extracted to the root `target/cds` folder. In case you want to make the reuse models only available within the Maven module that declared the dependency (e.g. `srv`) set the configuration `to` of the `resolve` goal to `${project.build.directory}`. In earlier versions of CAP Java reuse models where only available within CDS files placed in the Maven module that declared the dependency by default. +Usually you would declare the dependency to the reuse package in the `srv` module of your CAP Java project. Since CAP Java 4.4.0 this makes the reuse models available to all CDS files in the CAP project. The models are extracted to the root `target/cds` folder. In case you want to make the reuse models only available within the Maven module that declared the dependency (for example, `srv`) set the configuration `to` of the `resolve` goal to `${project.build.directory}`. In earlier versions of CAP Java reuse models where only available within CDS files placed in the Maven module that declared the dependency by default. ::: When your Maven build is set up correctly, you can use the reuse models in your CDS files using the standard `using` directive: diff --git a/java/event-handlers/indicating-errors.md b/java/event-handlers/indicating-errors.md index a129cd1863..2ba23ab4c3 100644 --- a/java/event-handlers/indicating-errors.md +++ b/java/event-handlers/indicating-errors.md @@ -167,7 +167,7 @@ In case of actions and functions SAP Fiori also requires the message target to b When creating a message target, the correct parameter needs to be selected to specify what the relative message target path refers to. By default a message target always refers to the CQN statement of the event. In case of CRUD events this is the targeted entity. In case of bound actions and functions this is the entity that the action or function was bound to. -As CRUD event handlers are often called from within bound actions or functions (e.g. `draftActivate`), CAP's OData adapter adds a parameter prefix to a message target referring to the `cqn` parameter only when required. +As CRUD event handlers are often called from within bound actions or functions (for example, `draftActivate`), CAP's OData adapter adds a parameter prefix to a message target referring to the `cqn` parameter only when required. ::: info When using the `target(String)` API, which specifies the full target as a `String`, no additional parameter prefixes are added by CAP's OData adapter. When using this API, [draft state messages](../../guides/uis/fiori#validating-drafts) can't be invalidated automatically on `PATCH`. diff --git a/java/security.md b/java/security.md index 6e12c42f7d..f76fdc3fdd 100644 --- a/java/security.md +++ b/java/security.md @@ -157,7 +157,7 @@ public class ActuatorSecurityConfig { In case you want to write your own custom security configuration that acts as a last line of defense and handles any request you need to disable the CAP security configurations by setting cds.security.authentication.authConfig.enabled: false, as Spring Security forbids registering multiple security configurations with an any request security matcher. -If you even want to deactivate OAuth token validation for XSUAA or IAS, e.g. to establish an own authentication strategy, +If you even want to deactivate OAuth token validation for XSUAA or IAS, for example, to establish an own authentication strategy, the following properties can be used: | Configuration Property | Description | Default diff --git a/node.js/cds-connect.md b/node.js/cds-connect.md index 812b292275..091e90a763 100644 --- a/node.js/cds-connect.md +++ b/node.js/cds-connect.md @@ -25,7 +25,7 @@ Use `cds.connect.to()` to connect to services configured in a project's `cds.req const ReviewsService = await cds.connect.to('ReviewsService') ``` -The method returns a _Promise_ resolving to a _[Service](../cds/cdl#services)_ instance which acts as a client proxy to the service's API, allowing you to call its methods and access its data using common [`cds.Service`](core-services#consuming-services) methods, e.g.: +The method returns a _Promise_ resolving to a _[Service](../cds/cdl#services)_ instance which acts as a client proxy to the service's API, allowing you to call its methods and access its data using common [`cds.Service`](core-services#consuming-services) methods, for example: ```js let reviews = await ReviewsService.read ('Reviews') diff --git a/node.js/cds-ql.md b/node.js/cds-ql.md index 64277c4037..d44963d099 100644 --- a/node.js/cds-ql.md +++ b/node.js/cds-ql.md @@ -114,7 +114,7 @@ let books = await cats.run (query) > `CatalogService` might be a remote service connected via OData. In this case, the query would be translated to an OData request sent via HTTP. -The APIs are also available through [`cds.Service`'s CRUD-style Convenience API](core-services#crud-style-api), e.g.: +The APIs are also available through [`cds.Service`'s CRUD-style Convenience API](core-services#crud-style-api), for example: ```js const db = cds.db diff --git a/node.js/cds-reflect.md b/node.js/cds-reflect.md index 330aa4e0ad..3ec65bf724 100644 --- a/node.js/cds-reflect.md +++ b/node.js/cds-reflect.md @@ -138,7 +138,7 @@ for (let each of m.entities('my.bookshop')) console.log (each.name) > [!info] > Note: In the dictionaries returned by `.entities` there are no entries for [`.texts`](#texts) entities, as these are generated, and hence living in a shadow world. They did show up in former releases, which caused a lot of confusion, and was fixed since cds 9.6. -> They are always accessible via the main entity's [`.texts`](#texts) property, e.g. `Books.texts`. +> They are always accessible via the main entity's [`.texts`](#texts) property, for example `Books.texts`. ### each() {#each .method } diff --git a/node.js/core-services.md b/node.js/core-services.md index c7b7802544..469ada692b 100644 --- a/node.js/core-services.md +++ b/node.js/core-services.md @@ -520,9 +520,11 @@ class BooksService extends cds.ApplicationService { **Methods `.on`, `.before`, `.after`** refer to corresponding *phases* during request processing: -- **`.on`** handlers _fulfill_ requests, for example, by reading/writing data from/to databases -- **`.before`** handlers run before the `.on` handlers, e.g., for validating inbound data -- **`.after`** handlers run after the `.on` handlers, e.g., to enrich outbound data +|Method | Description | Example +| --- | --- | --- | +| `.on`| handlers _fulfill_ requests | reading/writing data from/to databases | +| `.before` | handlers run before the `.on` handlers | validating inbound data | +| `.after` | handlers run after the `.on` handlers | enrich outbound data | **Argument `event`** can be one of: @@ -537,7 +539,7 @@ class BooksService extends cds.ApplicationService { - A `CSN definition` of an entity served by this service → from [`this.entities`](#entities) - A `string` corresponding to the _name_ of an entity served by this service -- A `path` navigating from a served entity to associated ones → e.g., `Books/author` +- A `path` navigating from a served entity to associated ones, e.g., `Books/author` **Multiple `events` or `entities`** – for both parameters, you can also specify: diff --git a/node.js/events.md b/node.js/events.md index db378cce47..f1a431ceec 100644 --- a/node.js/events.md +++ b/node.js/events.md @@ -570,7 +570,7 @@ req.info ('Some information message') req.warn ('Some warning message') ``` -The methods are similar to [`req.error()`](#req-error), also accepting the [same arguments](#req-reject), but the messages are collected in `req.messages` instead of `req.errors`, not decorated with stack traces, and returned in a HTTP response header (e.g. `sap-messages`), instead of the response body. +The methods are similar to [`req.error()`](#req-error), also accepting the [same arguments](#req-reject), but the messages are collected in `req.messages` instead of `req.errors`, not decorated with stack traces, and returned in a HTTP response header (for example, `sap-messages`), instead of the response body. ::: warning User Input & Injection Vulnerabilities Ensure proper validation of the message text if it contains values ​​from user input. From c990713aeb3b622a2a2bb4da84c3a1111ffaf322 Mon Sep 17 00:00:00 2001 From: Rene Jeglinsky Date: Tue, 7 Jul 2026 12:53:45 +0200 Subject: [PATCH 3/3] add redirect for databases-sqlite --- redirects.md | 1 + 1 file changed, 1 insertion(+) diff --git a/redirects.md b/redirects.md index 2c7c01f270..82d4445c9d 100644 --- a/redirects.md +++ b/redirects.md @@ -42,6 +42,7 @@ - [guides/using-services](guides/integration/calesi) - [guides/databases-hana](guides/databases/hana) - [guides/databases-postgres](guides/databases/postgres) +- [guides/databases-sqlite](guides/databases/sqlite) - [security](guides/security/) - [security/aspects](guides/security/overview)