npm info @sap/cds
we look at the latest info on the @sap/cds
module, we can see that it's at version 3.7.1. I've deliberately not upgraded the version I have installed globally, which is still at 3.5.2. This resulted in some interesting effects, for new projects created (with cds init
) which we explore at this point.cds
executable is being used:=> which cds
/Users/i347491/.nvm/versions/node/v8.12.0/bin/cds
=> file `which cds`
/Users/i347491/.nvm/versions/node/v8.12.0/bin/cds: a /usr/bin/env node script text executable, ASCII text
=> which cds
/Users/i347491/.nvm/versions/node/v8.12.0/bin/cds
=> file $(!!)
/Users/i347491/.nvm/versions/node/v8.12.0/bin/cds: a /usr/bin/env node script text executable, ASCII text
cds
file, we see that it's actually a symbolic link to another file elsewhere in the @sap/cds
package:=> ls -l ~/.nvm/versions/node/v8.12.0/bin/cds
lrwxr-xr-x 1 i347491 staff 39 12 Apr 07:14 /Users/i347491/.nvm/versions/node/v8.12.0/bin/cds@ -> ../lib/node_modules/@sap/cds/bin/cds.js
cds
entrypoint, in particular, the "bootstrap" section which has this comment: "try to find a locally installed cds, otherwise launch this one".=> node --inspect-brk `which cds`
Debugger listening on ws://127.0.0.1:9229/d4274321-3b28-4ae2-90a0-fbf02c5bf1e0
For help see https://nodejs.org/en/docs/inspector
require_local
which is a module inside the global @sap/cds
package, specifically in lib/utils/
. This module attempts to load a project-local version of the module specified, and back in cds.js
we see the result of this, if successful, is assigned to the _main
constant, falling back to the main
function that's defined further down in this global cds.js
script.cds
from within a CAP project directory,We can see how this works now, and understand why, when we invoke cds
from within a CAP project directory, we get a different version of cds
compared to when we invoke it from outside a CAP project directory. The power of Node, Chrome Developer Tools and debugging in general! (And of course this would be almost impossible if we didn't have access to the source code).cds run
and cds serve all
..js
file, with the same base name as a service definition file, allows us to provide custom implementation logic for the contents of that service. You can use this technique to enhance or override standard CAP service functionality as you see fit.service.js
file alongside the service.cds
file, with the following contents:module.exports = srv => {
console.log("IN SERVICE IMPLEMENTATION", srv)
}
console.log
statement.console.log
statement from srv
to srv.name
, and we can more easily see that in fact the function we've defined gets called for each of the services defined in service.cds
:IN SERVICE IMPLEMENTATION Breezy
IN SERVICE IMPLEMENTATION Restricted
service.cds
, thus:using northbreeze from '../db/model';
service Breezy {
entity Products as projection on northbreeze.Products;
entity Suppliers as projection on northbreeze.Suppliers;
entity Categories as projection on northbreeze.Categories;
function hello (to:String) returns String;
}
service Restricted {
entity Orders as projection on northbreeze.Orders;
}
service.js
with this:if (srv.name === 'Breezy') {
srv.before('READ', 'Products', x => {
console.log(x)
}
}
service.cds
file. Of course, a function import will belong to a specific OData service, so we write the definition inside one of the two services defined there, specifically the 'Breezy' service, and the definition looks like this:function hello (to:String) returns String;
service.js
implementation file, which we do, like this:srv.on('hello', x => {
console.log(x)
}
http://localhost:4004/breezy/hello(to='dj')
data
, the value of the to
parameter that we passed ("dj"), which we now use in what we return, modifying the function so it now looks like this:srv.on('hello', x => `Hello there ${x.data.to} !`)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
38 | |
19 | |
13 | |
13 | |
11 | |
10 | |
10 | |
10 | |
8 | |
8 |