| 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
- SAP Business Application Studio / Visual Studio Code
- SAP BTP - Cloud Foundry Environment
- You've already gone through Consume External Service - Part 1
Blog Post Series
- Consume External Service – Part 1
- Consume External Service – Part 2
- Consume External Service – Part 3
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: liteNote 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 buildMake 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-srvmodule. 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
NorthWinddestination. Go to BTP Cockpit and look for the destination service instancecap-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/ProductsAs 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 watchClosing
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!~
- SAP Managed Tags:
72 Comments
