In this blog post we shall write a nodejs application trying to retrieve externalized technical information about
destinations that are required to consume the target remote
service from an application.
So, what is destinations
Connectivity destinations are part of SAP Cloud Platform Connectivity and are used for the outbound communication of a cloud application to a remote system. They contain the connection details for the remote communication of an application. Connectivity destinations are represented by symbolic names that are used by on-demand applications to refer to remote connections. The connectivity service resolves the destination at runtime based on the symbolic name provided. The result is an object that contains customer-specific configuration details. These details contain the URL of the remote system or service, the authentication type, and the relative credentials.
for detailed overview of what is a destination service can be read from
help.
kindly go through my previous
blog on how to consume destinations from UI5 application running on cloud foundry.
This exercise involves the following main steps.
- Creating a new nodejs application.
- Binding a destination service on to the above application.
- Access the destination service from application by passing access token.
- once we have access to destination service, lets look for right destination and consume it on our application.
NOTE: we are trying to consume only a public endpoint available on cloud. if you have an endpoint coming from onprem world you need connectivity service as well. for more on that follow this
link
Lets get into coding.
Git clone the
project. open it in a IDE. Code of our interest lies in "odata.js" whenever we call the application, a function "readOrderDetails" is called inside "odata.js".
Code inside "readOrderDetails" tries to get the destination URL which is defined inside the instance of a destination service. I repeat "destination created inside the instance of a destination service".
Destinations can be created under
- Subaccount level - destination created over here is accessable to all the space under this sub account.
- Instance level - destination created inside destination instance are readOrderDetails only to application bound by that instance of destination service.
In our case.. we have choose option 2.
Inorder to access destination, we need a access token which can be generated using credentials like clientID, clientSecret and credentials url. all this variable values are available under environment variables of destination service.
function createToken(destAuthUrl, clientId, clientSecret) {
return new Promise(function(resolve, reject) {
// we make a post using x-www-form-urlencoded encoding for the body and for the authorization we use the
// clientid and clientsecret.
// Note we specify a grant_type and client_id as required to get the token
// the request will return a JSON object already parsed
request({
url: `${destAuthUrl}/oauth/token`,
method: 'POST',
json: true,
form: {
grant_type: 'client_credentials',
client_id: clientId
},
auth: {
user: clientId,
pass: clientSecret
}
},
function(error, response, body) {
if (error) {
reject(error);
} else {
resolve(body.access_token);
}
});
});
}
once we have the access token, we can use the same token to get the destination details.
function readOrderDetailsDestinationUrl() {
return new Promise(function (resolve, reject) {
getCredentials()
.then(function (credentials) {
return createToken(credentials.url, credentials.clientid, credentials.clientsecret)
})
.then(function (access_token) {
return getDestination(access_token, API_EndPoint);
})
.then(function (destination) {
const url = `${destination.URL}`;
console.log(`Accessing ODATA URL ${url}`);
resolve(url);
})
.catch(function (error) {
console.error(`Error getting Order_Details destination URL`);
reject(error);
})
});
}
once we get info on the endpoint details rest is a normal API call from nodejs application.
In our next blog I shall talk about how to access a endpoint secured by XSUAA via destination from a different micro service.
Thanks to todd, paul for helping out on this blog.
