Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
jhodel18
Active Contributor






Updated on 9 November 2022

In my previous blog post Consume External Service - Part 1, I have tested the application using mock and real data. Just by configuring the NorthWind OData service URL in the credentials.url property, I was able to connect to the external service. This approach is only applicable for local development testing. If you try to deploy this into SAP BTP, you will encounter an error stating that this approach is not valid for production use.

The reason behind this is that external service consumption in this CDS framework is meant to use the Destination Service in Cloud Foundry. And this is the topic of this blog -- deploying the Node.js project into SAP BTP Cloud Foundry using Destination Service.

 


 

Prerequisites







 

Blog Post Series







 

Setup Destination Configuration






First of all, why do we need to set up a destination? A simple explanation is that it is best practice to avoid hard coding the external services that you use in your application inside your code. It is better for it to be configured separately from your application because as you deploy your application into different environments like DEV, QA, or PROD, you can have a different setup of the destination per environment. Also, it keeps sensitive information like credentials outside of your code.

See Step 8 of Deploy the application to BTP Cloud Foundry

 

 

Deploy the application to BTP Cloud Foundry






Now let's go back to our Node.js project -- if you were able to follow through my previous blog post, then your project will look exactly like the one I have below:

https://github.com/jcailan/cap-samples/tree/blog-es-part1

The next step is to prepare the application for deployment to BTP Cloud Foundry.

  • 1. Generate the mta.yaml file using the command below:


> cds add mta




  • 2. Generate the security descriptor file xs-security.json using the command below:


> cds add xsuaa

 

  • 3. Update mta.yaml file with declaration of xsuaa and destination resources and then binding it to our node module cap-samples-srv.


---
_schema-version: "3.1"
ID: com.jcailan.cap-samples
version: 1.0.0
description: "A simple CAP project."
parameters:
enable-parallel-deployments: true
build-parameters:
before-all:
- builder: custom
commands:
- npx -p @sap/cds-dk cds build --production

modules:
- name: cap-samples-srv
type: nodejs
path: gen/srv
parameters:
buildpack: nodejs_buildpack
build-parameters:
builder: npm-ci
provides:
- name: srv-api # required by consumers of CAP services (e.g. approuter)
properties:
srv-url: ${default-url}
requires:
- name: cap-samples-uaa
- name: cap-samples-destination

resources:
- name: cap-samples-uaa
type: org.cloudfoundry.managed-service
parameters:
service: xsuaa
service-plan: application
path: ./xs-security.json
config:
xsappname: cap-samples-${org}-${space}
tenant-mode: dedicated

- name: cap-samples-destination
type: org.cloudfoundry.managed-service
parameters:
service: destination
service-plan: lite

Note that in order for the destination service consumption to work, an xsuaa service is required to be bound to our application.

  • 4. Update the package.json cds configurations to use the NorthWind destination (we will create the actual destination configuration later after deployment):


	"cds": {
"requires": {
"NorthWind": {
"kind": "odata",
"model": "srv/external/NorthWind",
"[backend]": {
"credentials": {
"url": "https://services.odata.org/Experimental/OData/OData.svc"
}
},
"[production]": {
"credentials": {
"destination": "NorthWind"
}
}
},
"[production]": {
"auth": {
"kind": "xsuaa",
"restrict_all_services": false
}
}
}
}







NOTE: The restrict_all_services = false removes authentication to all the provided service endpoints and we are using this for this example just for the sake of simplicity and because the original service endpoint doesn't have authentication in place. However, in normal cases, you would want to keep the authentication on especially when the app is used productively.


  • 5. Build the MTA Project by using the command:


> mbt build

Make sure you have saved all the file changes we did before doing the build.

An MTA archive file will be generated in the mta_archives folder.

  • 6. Deploy the MTA archive file into BTP Cloud Foundry using the command:


> cf deploy mta_archives/com.jcailan.cap-samples_1.0.0.mtar


  • 7. Once the deployment has been completed, look out for the terminal logs which state the URL of your cap-samples-srv module. In my case, here's the generated URL:


s0017687913trial-dev-cap-samples-srv.cfapps.eu10.hana.ondemand.com


  • 8. But before proceeding to test the application, make sure to add the configuration for the NorthWind destination. Go to BTP Cockpit and look for the destination service instance cap-samples-destination -- then add below configuration:




 

Test the deployed Node.js app service







  • 1. Open the URL we got from the previous step using your favorite browser, the initial page will show, and now click on the Products entity. You should see the result below:



As you can see, it is very easy to deploy the app and use the destination service. We don't really need to do any additional JavaScript coding, all that we did is just do a little bit of configuration.

 

Testing the Node.js app locally






Now that we have deployed our application into BTP Cloud Foundry, we can test the app locally while still using the destination service in BTP Cloud Foundry. In order to be able to test locally, we need to capture the environment variable assigned to our Node.js module in BTP.

  • 1. Execute the command below to fetch the environment variables bounded to your deployed node module app:


> cf default-env cap-samples-srv
Environment variables for cap-samples-srv written to default-env.json







NOTE: You need to have the CF Plugin called DefaultEnv installed in your machine -- see installation instructions here: https://github.com/saphanaacademy/DefaultEnv

 

  • 3. Next thing to do is start the app locally using the command:


> cds watch --profile production


  • 4. Test the app on a browser by using the URL below:


http://localhost:4004/catalog/Products


As you can see we now can test the app locally using real data while also using the destination service of BTP Cloud Foundry.

If by any chance you still want to revert to testing the app using our mock data, you can still do so by executing the command:
> cds watch

 


 

Closing






Now you know how easy it is to consume an external service using CAP Model and use Destination Service to manage the connection configuration. We also tested our application in three different ways:

  • Test the service directly in BTP Cloud Foundry

  • Test the service locally while still using BTP CF Destination Service

  • Test the service locally using mock data


Take note that mocking the data for your service is essential for automated unit testing, but this is another topic better dealt with over another blog.

UPDATE:

Taking this project further into -- Unit Testing using Mocha and Chai

 

~~~~~~~~~~~~~~~~

Appreciate it if you have any comments, suggestions, or questions. Cheers!~

 
72 Comments
Labels in this area