Continuing on from the previous back-to-basics episode, we now look at the role of SAP Cloud SDK and also at cds env, in the external service integration scenario we’re putting together. Join us, everyone welcome, especially beginners!
Topics:
SAP Cloud SDK, CAP, cds, JavaScript, OData, HTTP, npm, EDMX, metadata, destinations
Links:
Main Hands-on SAP Dev with qmacro playlist:
What’s Next for SAP CodeJam in 2023?
SAP Developer News February 16th 2023:
Chapters:
00:00 Welcome and introduction
08:40 Looking at where we left off last time
13:20 Starting off with cds watch, getting ‘show’ served, and ‘API_BUSINESS_PARTNER’ mocked
14:13 Understanding the nuances of –with-mocks relating to cds.requires and external service bindings
16:50 Mocking ‘API_BUSINESS_PARTNER’ in a separate process with cds mock
18:30 Starting cds watch in a second terminal and noting ‘API_BUSINESS_PARTNER’ is not mocked by that second CAP server process
20:20 Thinking about the @cds.persistence.skip and “cannot be served generically” error and why it happens
21:50 Adding a show.js file with some specific handling of READ events for the ‘Participants’ entity, which delegate those requests to a remote system
27:20 Looking at the new log message we get (‘connect to API_BUSINESS_PARTNER odata { … }’) when cds watch (re)starts
28:40 Rejoicing in a new, different error when we now make an OData request to get participants data – a missing @sap-cloud-sdk/http-client package
30:00 Understanding why the SAP Cloud SDK is needed, and what it does for CAP services
32:40 Installing the @sap-cloud-sdk/http-client package and having a look what it brings
36:10 Re-requesting the Participants entity set and seeing now a successful retrieval of data from the (still mocked, in a separate process) remote service
37:00 Staring at the request that was sent to the remote system (via bupa.run(req.query))
38:50 Adding some system query options to see them come through in a new request
39:50 Stop mocking the remote service (and getting yet another error (ECONNREFUSED) which we learn from and which tells us something)
42:10 Getting the sandbox URL from the SAP API Business Hub
42:50 Starting to look again at cds env and adding information to a new .env file, including the use of a “sandbox” profile
44:30 Using cds env get (and ls) to see the environment values for the API_BUSINESS_PARTNER requires information in general and in the sandbox-specific profile
45:50 Running cds watch –profile sandbox and understanding why API_BUSINESS_PARTNER is not mocked – in contrast to when it is mocked when we don’t use –profile sandbox
48:05 Thinking about the difference between the ‘odata’ and ‘odata-v2’ kinds, and why we get different ones in different circumstances
48:50 Requesting the Participants entity set again and seeing yet another error which we learn from – an HTTP 401 response with a message telling us an API key is missing
49:30 Adding a new entry in .env to specify the API key value
50:20 Specifying a deliberately incorrect API key value, and getting a 401 error with a message now telling us that the API key is invalid (and yes, 401 is in fact the appropriate status code here too)
51:52 Adding my API key to the .env file in ‘secret mode’ and restarting ‘cds watch –profile sandbox’, and thinking about what this collection of credentials is, effectively a destination definition
53:40 Making yet another request to the Participants entity set successfully, with data being retrieved from the remote sandbox server!
55:12 Adding DEBUG=remote to .env to enable us to see the details of the request (which is delegated to the remote system) in our local CAP server log output (after we fixed the missing newline in the file)
source
