Using destination as tenant aware services

[srinivas2210]

Using destination as tenant aware services

[saphanaacademy]

​Hi Srinivas,

Thanks for watching the HANA Academy video tutorials and using the generators.

The generators are actively updated - however we lack bandwidth to update all of the existing video tutorials as BTP and the generators themselves evolve. As such there might be some inconsistencies. It seems that's the case here and the destinations video tutorial is a little outdated. Apologies for that.

The generator is actually working as expected, just that the getDestination function in srv/library.js is no longer required. This change happened during implementation of the feature request here. Rather than accessing destinations via Axios, this is now done using the SAP Cloud SDK (see executeHttpRequest call in server.js srv/destinations endpoint). SAP Cloud SDK takes care of the multitenancy aspects for you and this is a more succinct approach.

So, for the time being please ignore some of the code walkthrough this video tutorial. We will try to refresh it in the near future (for what it's worth we did refresh the ones in that series covering routes using CF API).

We're always happy to hear feedback and welcome suggestions for improvements (either in the video tutorials or the generators themselves).

Best regards,

Philip

SAP HANA Academy

[srinivas2210]

Hi Philip,

Thanks for the response. I am also following on the discussion on the issue 4 which is logged to this repository. I seem to have an issue in understanding as to how "SAP Cloud SDK" takes care of the multi-tenancy ? I can understand that the executeHttpRequest function executes the required function, but how does RetrieveJwT function gets the right token. Is it a standard function in the core SDK? If yes, I could not find any documentation around this "RetrieveJwt" and it being tenant aware. May be I am looking at wrong places.
Could you please help ?

Thanks & Regards
Srinivas Rao.

[saphanaacademy]

Hi Srinivas,

RetrieveJWT get the token of the currently logged on user for eventual "passthrough" to actual destinations (when using identity propagation).

However this is totally different from to how authenticate to the destination service itself!

When using the destination service as a dependency in a multitenant scenario you should authenticate to it using the subscriber subdomain and not the provider subdomain in the authentication URL. In that case it will use the destination(s) defined in the subscriber subaccount. Cloud SDK is multitenant aware so does this for you automatically - that's why things just work.

Best regards,

Philip

SAP HANA Academy

[srinivas2210]

Thank you Philip for this help. I know that this is not the right channel to ask you such questions, but I am struggling anyway since I am beginner and believe me I am putting my best foot forward to understand and learn. In doing so, I have tried to understand your answers to this issue and the issue 4, and I feel - if I have to consume the destination from the consumer subaccount for one of the service that will be invoked, then I have to write the code something like this:

Could you please check this once and let me know if I am in the right direction ?

`app.get('/srv/getdata', async function(req, res) {
try {
// use tenant subdomain to authenticate
let url = services.dest.url.split('://')[0] + '://' + subdomain + services.dest.url.slice(services.dest.url.indexOf('.'));
try {
let options1 = {
method: 'POST',
url: url + '/oauth/token?grant_type=client_credentials',
headers: {
Authorization: 'Basic ' + Buffer.from(services.dest.clientid + ':' + services.dest.clientsecret).toString('base64')
}
};
let res1 = await axios(options1);
try {
options2 = {
method: 'GET',
url: dest.uri + '/destination-configuration/v1/destinations/' + destination,
headers: {
Authorization: 'Bearer ' + res1.data.access_token
}
};
let res2 = await axios(options2);
} catch (err) {
console.log(err.stack);
return err.message;
}
} catch (err) {
console.log(err.stack);
return err.message;
}

    let resp = await core.executeHttpRequest(dest, {
        method: 'GET',
        uri: res2.data.destinationConfiguration.url + "/sap/opu/odata/sap/<API>/<resource>",
        headers: {
            Authorization: 'Bearer ' + res1.data.access_token
        }
    });
    return res.type("application/json").status(200).send({
        results: resp.data.d.results
    });
} catch (err) {
    console.error('Getdataerror===>>>' + JSON.stringify(err));
    return res.type("application/json").status(err.response.status).send(JSON.stringify(err));
}

});`

But, I have questions like:

1. the function signature contains "req, res". It comes as undefined. So, I understand that is not required. right?
2. How do I pass the subdomain to this service that gets called?
3. If I happen to do this logic of getting the destination, I will end up doing the same piece of logic in all the services that I will write for the Fiori application. Isn't it performance wise bad ? Shouldn't I be doing it only once and then consume it for all the services? If yes, does it mean that I add a "getDestination" in the module.exports in server.js file ?
4. About the callback for dependencies, I understand that we are passing the xsappname. What I don't understand is how this is used to get the destination from the consumer subaccount ? I assume, it does not play any role. I see that it is only in xs-app.json that it influences. I may be wrong, but I know I still need lot of reading.

If you could help me in this, I will be extremely thankful to you !!

Regards
Srinivas Rao.

[saphanaacademy]

Hi Srinivas,

These are all great questions but this is the wrong place.

I suggest you ask the SAP Community where you'll reach a much broader group of experts and where others can more easily find and benefit from the answers.

Feel free to open GitHub issues for the generators should they be crashing or not working in some way or for enhancement requests etc.

But this is not the right place for general discussion on multitenancy in BTP.

As such I'm closing this issue.

Best regards,
Philip