Technical Articles
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
Links
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
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:
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.
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
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,
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.
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!
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
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
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
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.
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
Hello Carlos
Exactly. Just did a PoC and it seems to work.
Kind regards,
Martin
Great, thanks !
Hi Carlos
I read through all your blogs about BTP Job Scheduling Service and it was very useful to me! Thank you very much for your articles!
Now I have a rather confusing place, that is, the difference between use case 2 and use case 3 in the multi-tenant case and the usage scenario, you described that the job of use case 2 is customer-specific - and visible for customers; the job of use case 3 is customer-specific - but invisible for customers.
In response to their visible or invisible, I don't quite understand what exactly that means. And what are the differences between provider and consumer in two different use cases.
If you have time please also trouble to explain my question specifically, looking forward to your reply!
Best Regards,
Wenjun
Hi Wenjun Zheng ,
thanks for your question which helps to clarify questions that others might have as well.
As a developer, you create a MT application which is the provider app and deployed to the provider subaccount, there's no other app.
As a customer admin / consumer, you subscribe to the app in your consumer subaccount.
As a consumer, you can e.g. create data that is displayed in the app.
As a developer, you have to store the data for each consumer in a separate space/schema/database
As a consumer, you might have a feature that allows you to configure the app.
E.g. configure themes, settings. Such settings can be e.g. the time of a recurrent update-job
This is what I mean with "visible" for consumers.
In this case, the developer needs consumer-specific information and I represented the visibility by an action-URL that is consumer-specific by concatenating it with the consumer-subdomain
In case that the developer decides himself about the time of the job (or whatever job-setting), no job-related-configuration is required in the app-UI.
In this case, it is "invisible". In my representation, the action-URL doesn't need to concatenate the consumer-subdomain, job-generation and execution is done under the hood. The consumer-info is still required and is read from the JWT token
Finally, as a MT developer, you have lot of freedom to decide on the architecture.
The consumer-info is always there in the JWT-token, so you never really need to concatenate action-URLs.
I just tried to make confusing role of Jobscheduler in MT-scenario more clear
Kind Regards,
Carlos
Hello Carlos,
Thanks for explaining new Job scheduler on BTP.
The key areas I would like you to explore are:
Will you help to do this.
Regards,
Dhileep
Hi Dhileep,
I already answered your questions per email.
Kind Regards,
Oliver Heinrich