Homelab, Linux, JS & ABAP (~˘▾˘)~
 

Tag: multitenancy

BTP, CAP

[BTP] Get access token for specific tenant in a multitenant scenario using http rest client

 , , , , , , ,

https://docs.cloudfoundry.org/api/uaa/version/4.6.0/index.html#password-grant

# url from XSUAA Service Key, but replace in the url the provider subdomain with the consumer subdomain (the tenant you want to call)
@xsuaaUrl = {{$dotenv xsuaaUrl}}
# clientid from XSUAA Service Key
@xsuaaClientId = {{$dotenv xsuaaClientId}}
# clientsecret from XSUAA Service Key
@xsuaaClientSecret = {{$dotenv xsuaaClientSecret}}

@username = {{$dotenv btp_username}}
@password = {{$dotenv btp_password}}

### Get Access Token for Cloud Foundry using Password Grant with BTP default IdP
# @name getXsuaaToken
POST {{xsuaaUrl}}/oauth/token
Accept: application/json
Authorization: Basic {{xsuaaClientId}}:{{xsuaaClientSecret}}
Content-Type: application/x-www-form-urlencoded

grant_type=password
&username={{username}}
&password={{password}}
&response_type=token

### Store access token 
@access_token = {{getXsuaaToken.response.body.$.access_token}}
CAP

[CAP] Multitenant Job Scheduler – Request timeout after 15 seconds

 , , , , , ,

For Jobs running longer than 15 seconds, you have to manually inform the Job Scheduler if your operation succeeded or not. Else, your job will only stay in status COMPLETED/UNKNOWN due to the timeout.

Informing the Job Scheduler about your succeeded operation can be done vie REST API Endpoint Update Job Run Log. You can read more about Long-Running (Async) Jobs here. I therefore wrote a function named updateJobStatus, which I call at the end of every long-running endpoint. It checks if the endpoint is called manually or via Job Scheduler service and updates the Job Run Log using the @sap/jobs-client if required.

const cds = require('@sap/cds')
const LOG = cds.log('JobService')
const xsenv = require("@sap/xsenv")
const JobSchedulerClient = require("@sap/jobs-client")

async function fetchAccessToken(url, creds) {
    const response = await fetch(`${url}/oauth/token`, {
        method: 'POST',
        body: 'grant_type=client_credentials&client_id=' + creds.uaa.clientid + '&client_secret=' + creds.uaa.clientsecret,
        headers: {
            'Content-Type': 'application/x-www-form-urlencoded'
        }
    })
    return await response.json()
}

async function getJobscheduler(req) {
    xsenv.loadEnv()
    const services = xsenv.getServices({
        jobscheduler: { tags: "jobscheduler" }
    })
    if (!services.jobscheduler) req.reject("no jobscheduler service instance found")

    const subdomain = (process.env.NODE_ENV === 'production') ? req.http.req.authInfo.getSubdomain() : 'customer1' // workaround for local testing
    const domain = `https://${subdomain}.${services.jobscheduler.uaa.uaadomain}`
    const token = await fetchAccessToken(domain, services.jobscheduler)

    const options = {
        baseURL: services.jobscheduler.url,
        token: token.access_token
    }
    return new JobSchedulerClient.Scheduler(options)
}

async function updateJobStatus(req) {
    const jobId = req.headers['x-sap-job-id']
    const scheduleId = req.headers['x-sap-job-schedule-id']
    const runId = req.headers['x-sap-job-run-id']

    if (!jobId || !scheduleId || !runId) return
    LOG.info('Endpoint is called via Job Scheduler')

    const scheduler = await getJobscheduler(req)

    const payload = {
        jobId: jobId,
        scheduleId: scheduleId,
        runId: runId,
        data: { success: true, message: 'The endpoint has successfully executed the long-running job' }
    }

    scheduler.updateJobRunLog(payload, function (err, result) {
        if (err) return LOG.error('Error updating run log: %s', err)
        //Run log updated successfully
        LOG.info('Run log updated successfully')
    })
}

module.exports = {
  updateJobStatus
}
CAP

[CAP] Multitenant Job Scheduler – Fixing Scope issue

 , , , , , , , , , , , , ,

When I was integrating the Job Scheduler service into my Multitenant Application, I ran into the following JWT Token issue, when the Job Scheduler was calling my CAP action. Means the job creation was already working fine and was also displaying the right tenant for my job, but the Job Scheduler was not able to successfully call the given endpoint. This is the error I got in the logs:

Error: Jwt token with audience: [
'sb-a1e9d3b8-2bee-47db-xxxx-07e5a54aec1e!b180208|sap-jobscheduler!b3',
'uaa'
] is not issued for these clientIds: [
'sb-MyApp-mtdev-App!t180208',
'MyAp-mtdev-App!t180208'
].

After reading some of the great blogs from Carlos Roggan, I noticed that I forgot to grant the Job Scheduler the necessary authority to actual call my CAP action. So I added the following lines to the xs-security.json file

    {
      "name": "$XSAPPNAME.jobscheduler",
      "description": "Scope for Job Scheduler",
      "grant-as-authority-to-apps": [
        "$XSSERVICENAME(job-scheduler)"
      ]
    }

and also annotated my CAP action using the new scope @(requires: ['jobscheduler']).

I redeployed everything, but the issue still persists. 🙁

Turned out, for the standard plan, tokens are cached in Job Scheduler up to 12 hours.

https://help.sap.com/docs/job-scheduling/sap-job-scheduling-service/secure-access?locale=en-US

After waiting 12 hours, the endpoint was successfully called by the Job Scheduler. 🙂

CAP

[CAP] Get subdomain in a multitenant scenario

 , , , , , , ,

Until recently, I was always decoded the JWT to get the subdomain of a subscribed tenant like this:

const jwt = retrieveJwt(req)
const subdomain = decodeJwt(jwt).ext_attr.zdn

I now noticed that you can also use the original request object and the getSubdomain function of the authInfo object. It’s provided by @sap/xssec and is only available when using XSUAA, means not with mocked authentication. This way you can get the subdomain in a single line:

const subdomain = req.http.req.authInfo.getSubdomain()

And there are some more helpful functions, that are documented here:

CAP

[CAP] Dynamically set destination in package.json for an external connection

 , , , , , 
  "cds": {
    "requires": {
      "sfsf": {
        "kind": "odata-v2",
        "credentials": {
          "destination": "<set during runtime>",
          "path": "/odata/v2",
          "requestTimeout": 18000000
        }
      }
    }
  },

  /*
   * Handover query to some external SF OData Service to fecth the requested data
   */  
  srv.on("READ", Whatever, async req => {

        const sf_api_def = cds.env.requires['sfsf'] //defined in package.json

        sf_api_def.credentials.destination = "myDestinationName" //set your Destination name, could come from a customizing table

        const sfsfSrv = await cds.connect.to(sf_api_def)

        return await sfsfSrv.run(req.query)
    })

CAP

[CAP] Use Destinations from Subscriber Account

 , , , , , , ,

While working on this topic, there are currently two chapters in the CAP docs regarding this topic:

And some SCN posts: here, here and here

But all this didn’t help me to complete the task. Got the solution which finally worked for me from this SAP Sample Susaas (two snippets: here and here).

server.js

const cds = require("@sap/cds")

cds.on('served', async () => {
    const { 'cds.xt.SaasProvisioningService': provisioning } = cds.services
    // Add provisioning logic only if multitenancy is there..
    if (provisioning) {
        let tenantProvisioning = require('./provisioning')
        provisioning.prepend(tenantProvisioning)
    } else {
        console.log(">>> There is no service, therefore does not serve multitenancy!")
    }
})

module.exports = cds.server

provisioning.js

const xsenv = require('@sap/xsenv')
xsenv.loadEnv()

module.exports = (service) => {

    service.on('dependencies', async (req, next) => {
        let dependencies = await next()
        const services = xsenv.getServices({
            registry: { tag: 'SaaS' },
            destination: { tag: 'destination' }
        })
        dependencies.push({ xsappname: services.destination.xsappname }) //adds the subscriber destination as dependency
        console.log(">>> SaaS Dependencies:", JSON.stringify(dependencies))
        return dependencies
    })

}

It injects the destination dependency by manually reading it using xsenv package and returning it in a dependencies callback handler.