We are in the midst of the age of cloud computing and the change in IT system landscapes and software development projects is both noticeable and irreversible. Large, heavyweight monoliths are no longer in vogue, IT systems are becoming smaller and more distributed, technology stacks more heterogeneous, a development that also no longer stops at the SAP world. In future, the core systems are to be kept clean; instead of Z-tables, the migration-plagued IT professional now prefers to use side-by-side extensions. If the standard functionality of a system does not sufficiently reflect the process reality of a company, additional functionality is provided as independent, small and lean Fiori apps. So far, so good. But of course these extensions do not exist on their own in a vacuum, but should be loosely coupled with other extensions and of course also with the underlying back-end systems in order to achieve a noticeable business benefit across the entire process chain. This sounds simple at first, but is quickly accompanied by hard nuts to crack:
To master at least part of this challenge, SAP Business Technology Platform offers so-called destinations. Destinations are used to configure connection information and to simplify the handling of individual communication steps and outsource them to a destination service. The main focus here is on the respective mechanisms for authentication. There is already a lot of official documentation on Destinations on the Internet, as well as many great blog articles and other community contributions that help to familiarise oneself with the cosmos of SAP BTP Destinations. Nevertheless, in my day-to-day work with developers and architects, I notice that there is often a lack of clarity about how destinations are to be used and which destination type is suitable for the respective integration scenarios. What I personally have often lacked in my research over the past years were tangible and touchable examples. This motivated me to create a GitHub repository in which I gradually provide examples for the different destination types, supplementing them with text contributions in which I describe the use cases for which the respective destination type is suitable. I also provide some background information on what goes on behind the scenes of such a destination.
In order to try out the examples in the repository, you should have some basic experience in working with the SAP BTP Cloud Foundry environment. Knowledge of node / npm / JavaScript is also definitely an advantage. All examples are built with SAP CAP with Node.js and use Multi Target Applications (MTA) for deployment. To build and deploy the examples you will need in any case:
For each destination type there is a separate branch with a README file describing how to deploy client and server on Cloud Foundry and how to test the connection between client and server.
srv.on('helloWorldClientCloudSDK', async () =>
return executeHttpRequest({ destinationName: 'Server' })
.then((response) => response.data)
})
const { executeHttpRequest } = require('@sap-cloud-sdk/http-client'
const axios = require('axios')
module.exports = async (srv) => {
srv.on('helloWorldClientPlain', async () => {
// get all the necessary destination service parameters
// from the service binding in the VCAP_SERVICES env variable
const vcapServices = JSON.parse(process.env.VCAP_SERVICES)
const destinationServiceUrl =
vcapServices.destination[0].credentials.uri +
'/destination-configuration/v1/destinations/'
const destinationServiceClientId =
vcapServices.destination[0].credentials.clientid
const destinationServiceClientSecret =
vcapServices.destination[0].credentials.clientsecret
const destinationServiceTokenUrl =
vcapServices.destination[0].credentials.url +
'/oauth/token?grant_type=client_credentials'
// before we can fetch the destination from the
// destination service, we need to retrieve an auth token
const token = await axios.post(destinationServiceTokenUrl, null, {
headers: {
authorization:
'Basic ' +
Buffer.from(
`${destinationServiceClientId}:${destinationServiceClientSecret}`
).toString('base64'),
},
})
const destinationServiceToken = token.data.access_token
// with this token, we can now request the
// "Server" destination from the destination service
const headers = {
authorization: 'Bearer ' + destinationServiceToken,
}
const destinationResult = await axios.get(
destinationServiceUrl + 'Server',
{
headers,
}
)
const destination = destinationResult.data
// now, we use the retrieved the destination
// information to send a HTTP request to the server endpoint
const destinationResponse = await axios.get(
destination.destinationConfiguration.URL
)
return destinationResponse.data
})
srv.on('helloWorldClientCloudSDK', async () => {
return executeHttpRequest({ destinationName: 'Server' })
.then((response) => response.data)
})
})
This example is far from passing for rocket science. But don't worry - in terms of complexity, it is guaranteed to increase in the coming parts of this series!
What are your experiences with destinations in SAP BTP so far? Which integration scenarios have you already had to deal with? What were the biggest challenges? If you have any suggestions or improvement requests, or if something doesn't work as you hoped, please let me know. It is my wish and goal to continuously expand and improve this repository, and for that I depend on your feedback from the SAP BTP community! 🙂
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
22 | |
8 | |
6 | |
5 | |
5 | |
5 | |
4 | |
4 | |
3 | |
3 |