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!
Showing results for 
Search instead for 
Did you mean: 
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.





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:

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."
enable-parallel-deployments: true
- builder: custom
- npx -p @sap/cds-dk cds build --production

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

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

- name: cap-samples-destination
type: org.cloudfoundry.managed-service
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": ""
"[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:

  • 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:


  • 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:


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




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.


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



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

Labels in this area