Skip to Content
Technical Articles
Author's profile photo Carlos Roggan

Job Scheduler in SAP Business Technology Platform: Overview of Blog Posts

This series of blog posts explains how to use SAP Job Scheduling Service running on SAP Business Technology Platform (aka SAP Cloud Platform)

Job Scheduler
-> is a tool
—> allows to define jobs
——> schedule to run regularly
———> trigger REST endpoints

Job Scheduler runs in Cloud Foundry environment and provides more convenience like support for OAuth 2.0, Multitenancy, CF Tasks, etc.

And it has the following cool icon:

Now it is your job to define your own schedule to regularly run through the following blog posts:

Introduction

Part 0 : Using Job Scheduler in SAP Cloud Platform [0]: Intro and Prep

Tutorials

Part 1: First simple use case in Trial account
Part 2: Simple use case with security
Part 3: Simple use case with authentication and authorization
Part 4: Using App Router in between Job and endpoint
Part 5: Long-running operations (async jobs)
Part 6: Troublemaking (get little help for 403 error)
Part 7: Multitenancy with Job Scheduler (0): introduction and use cases
Part 8: Multitenancy with Job Scheduler (1): preparation + first very simple sample (really simple)
Part 9: Multitenancy with Job Scheduler (2): generation of tenant-specific job
Part 10: Multitenancy with Job Scheduler (3): securing tenant-specific action endpoint
Part 11: Multitenancy with Job Scheduler (4): use token exchange for protected createjob endpoint
Part 12: Multitenancy with Job Scheduler (5): adding approuter
Part 13: Multitenancy with Job Scheduler (6): Small but complete sample

Part 14: FAQs

SAP Help Portal
Job Scheduler documentation main entry
Support for multitenancy in Job Scheduler
Job Scheduler functionality can be managed via dashboard and REST API
Job Scheduler client library docu.
Job Scheduler FAQs
Job Scheduler in Discovery Center
Pricing information in Sap Store

Blog Posts
Granting authorization between apps with different xsuaa

Multitenancy
Developing Multitenant Applications in Cloud Foundry Environment
SaaS Registry in Discovery Center
Using REST API of SaaS to manage MT apps
API Reference of the SaaS REST API
Using Custom Domains
Blog on Multitenancy Architecture in Cloud Foundry Environment
Blog on developing multitenant application
Another blog on developing MT apps
Sample for Multitenancy
Another sample
Java sample

More
xssec security library in node

xsuaa in SAP Help Portal
And the reference for xs-security.json

 

 

Assigned Tags

      10 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Somnath Paul
      Somnath Paul

      Hi Carlos Roggan,

      No doubt this is a gold mine! I am still following and yet to complete.

      I have a specific scenario, which I am not yet able to make things work as expected. Could you please share your thoughts or any pointers to a blog post that I can read and learn from?

      From the BTP background job, I am calling a node js application that is protected thru passport middleware. So I am using the XSUAA attached to the job scheduling service and can able to generate the required OAuth token for my node application. So this first one is working.

      From the Node JS application, I am trying to make a call to another RAP service URL which is also OAuth protected. It works well when I try to specific user credentials and use foreign-scope-references. But as I am trying SSO based approach so I would like to propagate the previous JWT token to authenticate the RAP service as well and there it fails.

      My xs-security.json is as below:

      {
      "xsappname":"myapp",
      "tenant-mode":"dedicated",
      "scopes":[{
      "name":"$XSAPPNAME.scopeformyapp",
      "description":"my node js app",
      "grant-as-authority-to-apps":["$XSSERVICENAME(mybtpjobinstance)"],
      },
      {
      "name":"$XSAPPNAME(application,<rap-app-unique-id>).AllAccess",
      "description":"my RAP Service",
      "grant-as-authority-to-apps":["$XSSERVICENAME(mybtpjobinstance)"],
      }
      ],
      }

      I can't use foreign-scope-references, as I understood this is for user role-specific, so definitely something I am missing to properly whitelisting the RAP service for Job instances to work.

      Will be very helpful if you let me know the missing things over here.

      • Thanks, Somnath
      Author's profile photo Carlos Roggan
      Carlos Roggan
      Blog Post Author

      Hi Somnath Paul , thanks very much for the feedback - and thanks for the question.
      This is an interesting question, I’ve never tried such scenario, so I cannot give you professional advice how to properly solve it.
      One question, if the RAP service is also bound to XSUAA?
      So in your diagram you have actually 3 instances of XSUAA, right?

      1) I guess usually in such scenario you would use SAML, but Jobscheduler doesn’t support that and also I’m not familiar here.

      2) What you’re trying to do, as far as I understand: Jobscheduler should send a token that is accepted by both app1 (which is bound to JS) and app2 (RAP)
      Only app1 is bound to JS, so app1 needs to grant everything that is required to JS.
      Granting a scope has 2 effects:
      the scope will be contained in the “scopes” claim of the token
      The xsappname will be contained in the aud claim of the token
      Now, the xsappname of app2 should arrive to JS.
      So you want to
      Grant scope2 to app1 -> then grant scope1+2 to Jobscheduler
      I don’t know, but I assume, the grant can only be used for scopes defined in the same xs-security.
      So you’re referring to an existing “foreign” scope, in the scopes section, which looks tricky and cool
      But I think it is not possible, because probably the scopes section is only used to define new scopes.
      Have you checked the token which is sent by JS? Which scopes does it send?

      3) I have no other idea.
      Token exchange? It can be done, but I assume it wouldn’t make a difference to fetching a new token with client-credentials.
      We have to see that:
      Jobscheduler does only client-credentials. Which is natural, as JS is a service and has no user context for executing Jobs.
      So your RAP service should support client-credentials as well.
      If a user would be really required…..then it somehow wouldn’t fit in a “jobscheduling” scenario.
      So anyways you would need to do workarounds.

      Sorry for not having better answer here.

      Cheers,
      Carlos

      Author's profile photo Somnath Paul
      Somnath Paul

      Hi Carlos Roggan

      Many thanks for finding the time and sharing your thoughts!

      So in your diagram, you have actually 3 instances of XSUAA, right?

      I am using a single XSUAA instance which I have bound to Node JS only (with manifest. YAML). As per your blog post, it's working fine, because JS requests JWT from the XSUAA, and then it forwards the same to the node app, so the endpoint gets triggered within which I am checking the scope. The same token now I am passing while calling the RAP service from my node app,  hoping this will resolve authentication but it doesn't.

      One question, if the RAP service is also bound to XSUAA?

      If I go via the human user approach then the below setup will work to authenticate RAP service,

      {
        "xsappname":"rapjob",
        "tenant-mode":"dedicated",
        "foreign-scope-references":[ "$XSAPPNAME(application,e070506aa-ddc0-435c-aab6-7abc40008538).AllAccess"]
      }

      But as this is a background job scenario, the above concept not working and so I am trying with the below approach, this is something I am not doing correctly I believe.

      {
         "xsappname":"myapp",
         "tenant-mode":"dedicated",
         "scopes":[{
             "name":"$XSAPPNAME.scopeformyapp",
             "description":"my node js app",
             "grant-as-authority-to-apps":["$XSSERVICENAME(mybtpjobinstance)"],
            },
            { 
             "name":"$XSAPPNAME(application,<rap-app-unique-id>).AllAccess",
             "description":"my RAP Service",
            "grant-as-authority-to-apps":["$XSSERVICENAME(mybtpjobinstance)"],
           }
         ]
      }

      So you want to
      Grant scope2 to app1 -> then grant scope1+2 to Jobscheduler

      yes, something that I am trying to achieve but not sure how to frame my xs-security.json to handle such scopes and granting.

      Thanks again!

      • BR, Somnath

       

      Author's profile photo Carlos Roggan
      Carlos Roggan
      Blog Post Author

      Hi Somnath Paul ,
      I still haven't understood about the RAP service, but I think this seems to be a third-party service which is not being developed by you?
      Probably it is tailored to grant access and scope to any authenticated user who accepts that scope.
      So it looks like it doesn't support client-credentials.
      I think you need to find that out, try to contact the dev team of that service.

      I think, typical use case for Jobscheduler is to run regular jobs that don't require logged-in user. Or, at DB-level, a routine is used for scenario with technical user, or similar things like this.

      Keeping fingers crossed that you get your scenario running!

      Cheers,
      Carlos

       

      Author's profile photo Martin Koch
      Martin Koch

      Dear Carlos

      thanks for the great blog!!

      We have the requirement to call SAP Cloud Integration via the Job Scheduler and were not able to find a solution. The binding only works on an application-level, but not on a subscription level.

      So it is not possible to bind the Job Scheduler to Cloud integration in order to do the authentication.

      Do you have any solution / proposal for this?

      Thanks!

      Best regards

      Martin

      Author's profile photo Carlos Roggan
      Carlos Roggan
      Blog Post Author

      Hello Martin Koch ,

      you're right, the only thing you could do is a workaround:
      You can create a little proxy application, which you can bind to jobscheduler.
      So jobscheduler would call this app.
      In the app implementation, you would then call the SAP Cloud Integration and do the authentication programmatically.

      Kind Regards,

      Carlos

      Author's profile photo Martin Koch
      Martin Koch

      Thanks!

      I'll use the API Management as a proxy with, no authentication but using an api key and API management calls cloud integration and authenticates against cloud integration using basic auth or OAuth.

       

      Author's profile photo Carlos Roggan
      Carlos Roggan
      Blog Post Author

      Hello Martin Koch , thanks for the info, this sounds like a nice solution.
      So as far as I understand,
      - you create an API which wraps your cloud integration endpoint.
      - The API configures a policy that can do the OAuth client-credentials?
      - The endpoint doesn't require a scope?
      - The API can be called with apikey as URL parameter?

      Kind Regards,
      Carlos

      Author's profile photo Martin Koch
      Martin Koch

      Hello Carlos

      Exactly. Just did a PoC and it seems to work.

      Kind regards,

      Martin

      Author's profile photo Carlos Roggan
      Carlos Roggan
      Blog Post Author

      Great, thanks !