diff --git a/node.js/cds-compile.md b/node.js/cds-compile.md index 46754d61c..f39e6d53b 100644 --- a/node.js/cds-compile.md +++ b/node.js/cds-compile.md @@ -179,7 +179,8 @@ console.log (edm) ```js // for all services let all = cds.compile.to.edm (csn, {service:'all'}) -for (let [edm,{file,suffix}] of all) console.log (file,suffix,edm) +for (let [edm,{file,suffix}] of all) +console.log (file,suffix,edm) ``` @@ -197,7 +198,7 @@ For example, use it as follows: ```js let all = cds.compile.to.hdbtable (csn) for (let [src,{file}] of all) - console.log (file,src) +console.log (file,src) ``` @@ -402,12 +403,13 @@ If no files are found, `undefined` is returned. Examples: ```js -cds.env.folders // = folders db, srv, app by default -cds.env.roots // + schema and services in cwd -cds.resolve('*',false) // + models in cds.env.requires -cds.resolve('*') // > the resolved existing files -cds.resolve(['db']) // > the resolved existing files -cds.resolve(['db','srv']) // > the resolved existing files -cds.resolve('none') // > undefined +[dev] cds repl +> cds.env.folders // = folders db, srv, app by default +> cds.env.roots // + schema and services in cwd +> cds.resolve('*',false) // + models in cds.env.requires +> cds.resolve('*') // > the resolved existing files +> cds.resolve(['db']) // > the resolved existing files +> cds.resolve(['db','srv']) // > the resolved existing files +> cds.resolve('none') // > undefined ``` -> Try this in cds repl launched from your project root to see that in action. +> Try this in cds repl launched from your project root to see that in action. \ No newline at end of file diff --git a/node.js/cds-facade.md b/node.js/cds-facade.md index 804716388..7d38fca88 100644 --- a/node.js/cds-facade.md +++ b/node.js/cds-facade.md @@ -138,7 +138,7 @@ if (major < 6) // code for pre cds6 usage Returns the pathname of the `@sap/cds` installation folder from which the current instance of the `cds` facade module was loaded. -```log +```js [dev] cds repl > cds.home // [!code focus] ~/.npm/lib/node_modules/@sap/cds @@ -176,7 +176,7 @@ Trace : { } ``` -For example, [`cds-plugins`](cds-serve) can use that to plugin to different parts of the framework for different commands being executed. +For example, [`cds-plugins`](cds-serve) can use that to plug into different parts of the framework for different commands being executed. @@ -185,7 +185,7 @@ For example, [`cds-plugins`](cds-serve) can use that to plugin to different part Provides access to the effective configuration of the current process, transparently from various sources, including the local _package.json_ or _.cdsrc.json_, service bindings and process environments. -```console +```js [dev] cds repl > cds.env.requires.auth // [!code focus] { @@ -232,15 +232,17 @@ service ReviewsService {} You can access the entries as follows: ```js -cds.env.requires.db //> the effective config for db -cds.env.requires.reviews //> the effective config for reviews -cds.env.requires.ReviewsService //> undefined +[dev] cds repl +> cds.env.requires.db //> the effective config for db +> cds.env.requires.reviews //> the effective config for reviews +> cds.env.requires.ReviewsService //> undefined ``` ```js -cds.requires.db //> the effective config for db -cds.requires.reviews //> the effective config for reviews -cds.requires.ReviewsService //> same as cds.requires.reviews +[dev] cds repl +> cds.requires.db //> the effective config for db +> cds.requires.reviews //> the effective config for reviews +> cds.requires.ReviewsService //> same as cds.requires.reviews ``` The additional entries are useful for code that needs to securely access the service by cds definition name. @@ -248,8 +250,9 @@ The additional entries are useful for code that needs to securely access the ser Note: as `cds.requires` is an overlay to `cds.env.requires`, it inherits all properties from there via prototype chain. In effect using operations which only look at *own* properties, like `Object.keys()` behave different than for `cds.env.requires`: ```js -Object.keys(cds.env.requires) //> [ 'db', 'reviews' ] -Object.keys(cds.requires) //> [ 'ReviewsService' ] +[dev] cds repl +> Object.keys(cds.env.requires) //> [ 'db', 'reviews' ] +> Object.keys(cds.requires) //> [ 'ReviewsService' ] ``` diff --git a/node.js/cds-server.md b/node.js/cds-server.md index 0744719df..d76b3cb1a 100644 --- a/node.js/cds-server.md +++ b/node.js/cds-server.md @@ -10,7 +10,7 @@ status: released -CAP Node.js servers a bootstrapped through a [built-in `server.js` module](#built-in-server-js), which can be accessed through [`cds.server`](#cds-server). You can plug-in custom logic to the default bootstrapping choreography using a [custom `server.js`](#custom-server-js) in your project. +CAP Node.js servers are bootstrapped through a [built-in `server.js` module](#built-in-server-js), which can be accessed through [`cds.server`](#cds-server). You can plug-in custom logic to the default bootstrapping choreography using a [custom `server.js`](#custom-server-js) in your project. @@ -121,7 +121,7 @@ module.exports = (o)=>{ } ``` -::: tip +::: tip `req` != `req` The `req` object in your express middleware is not the same as `req` in your CDS event handlers. ::: diff --git a/node.js/events.md b/node.js/events.md index 254992fe3..e98bf9bf4 100644 --- a/node.js/events.md +++ b/node.js/events.md @@ -24,12 +24,13 @@ Usually that context is set by inbound middleware. The property is realized as a so-called continuation-local variable, implemented using [Node.js' async local storage](https://nodejs.org/api/async_context.html) technique, and a getter/setter pair: The getter is a shortcut for[`getStore()`](https://nodejs.org/api/async_context.html#asynclocalstoragegetstore). The setter coerces values into valid instances of [`cds.EventContext`]. For example: ```js -cds.context = { tenant:'t1', user:'u2' } -let ctx = cds.context -ctx instanceof cds.EventContext //> true -ctx.user instanceof cds.User //> true -ctx.tenant === 't1' //> true -ctx.user.id === 'u2' //> true +[dev] cds repl +> cds.context = { tenant:'t1', user:'u2' } +> let ctx = cds.context +> ctx instanceof cds.EventContext //> true +> ctx.user instanceof cds.User //> true +> ctx.tenant === 't1' //> true +> ctx.user.id === 'u2' //> true ``` If a transaction object is assigned, its `tx.context` is used, hence `cds.context = tx` acts as a convenience shortcut for `cds.context = tx.context`: diff --git a/node.js/messaging.md b/node.js/messaging.md index 0b902434b..19d911a4b 100644 --- a/node.js/messaging.md +++ b/node.js/messaging.md @@ -361,9 +361,8 @@ Example: If your server is authenticated using [XSUAA](authentication#jwt), you need to grant the scope `$XSAPPNAME.emcallback` to SAP Event Mesh for it to be able to trigger the handshake and send messages. -In _xs-security.json_: - -```js +::: code-group +```js [xs-security.json] { ..., "scopes": [ @@ -378,6 +377,7 @@ In _xs-security.json_: ] } ``` +::: Make sure to add this to the service descriptor of your SAP Event Mesh instance: