Technical Articles
SAP Job Scheduling Service + Cloud Application Programming Model application (CAP) + SAP Authorization and Trust Management Service (XSUAA)
Introduction
SAP introduced the SAP Job Scheduling Service on the SAP Business Technology Platform to provide a service to define and manage jobs that run once or on a reoccurring schedule. The service can call REST API endpoints once or in time intervals, by sending specified HTTP calls.
The functionality of the SAP Job Scheduling Service can be combined with cloud applications running in the Cloud Foundry environment of the SAP Business Technology Platform, especially applications, which utilize the SAP Cloud Application Programming Model. In general, calling an unsecured API endpoint is quite straight forward, but the complexity of the same scenario can rise, when the aspects of data security and data protection are considered.
The purpose of this blog post is to demonstrate the necessary steps to provide a functioning setup for a secured endpoint within an SAP Cloud Application Programming Model application, which is secured by the SAP Authorization and Trust Management Service, called by the SAP Job Scheduling Service.
Disclaimer:
This blog post can be seen as an extension of Carlos Roggans blog post (LINK). It will pick up some steps of the blog post and will continue providing the necessary steps within the cloud application. Kudos to Carlos Roggan for his great blog post serie.
Implementation steps
Instantiating an instance of the SAP Job Scheduling Service
First we need an instance of the service, which is supposed to be used to define and maintain the job. The value of the service name can be freely chosen, but the value will be needed at a later step.
Details for the service creation:
Service name: “jobschedulerexample” (choose this value freely)
Service plan: “Standard”
Parameters:
{
"enable-xsuaa-support": true
}
Instantiating or updating an SAP Authorization and Trust Management Service instance
For our example scenario we also need an instance of the SAP Authorization and Trust Management Service, which is supposed to be used by the cloud application.
Details for the service creation:
Service name: “xsuaa”
Service plan: “application”
Parameter:
{
"xsappname": "jobschedulerexample",
"tenant-mode": "dedicated",
"scopes": [
{
"name": "$XSAPPNAME.jobscheduler",
"description": "JobScheduler Scope",
"grant-as-authority-to-apps": [
"$XSSERVICENAME(jobschedulerexample)"
]
}
]
}
The value in the $XSSERVICENAME string needs to be equal to the name of the service instance of the Job Scheduling service.
Definition of OData service in the Cloud Application Programming Model application
The Cloud Application Programming Model framework distinguishes different pseudo roles for accessing APIs within an application (Link). The role “authenticated-user” refers to real business users, who access the web application via an UI for example. The role “system-user” referrers to an unnamed user for technical communication between systems / applications. In this case the role “system-user” is most suited for this kind of scenario.
The accessible service is defined as:
@(requires: 'system-user')
service TechService {
function calculateTotalDailyTransactionValue @(restrict : [{
grant : 'READ',
to : 'jobscheduler'
}])() returns String;
}
Compared to a service for business users, the value for the “requires” annotation differs for a technical user.
Additionally the respective security scope “$XSAPPNAME.jobscheduler”, which was defined in the xs-security.json file, is needed to be able to call the function import of this OData service to further tighten the restrictions and increase the level of security.
SAP Job Scheduling Service
To be able to call the application, the service needs to be bound via “service binding” to the web application / Cloud Foundry application. The job declaration and schedule definition doesn’t include any special steps for this scenario. After the execution of the respective job / API call from the jobscheduler, an additional entry can be checked in the logs. As expected, the call was successful.
Conclusion
- The SAP Job Scheduling Service can be used to trigger custom logic in an Cloud Application Programming Model application.
- The necessary steps are
- Add a scope for the job scheduler service in xs-security.json file
- Modify the “requires” annotation to “system-user” in the respective service
- Add restriction the to be called entity / function import / action
- Bind job scheduler instance to the application via service binding
- Define the job
Feel free to comment on this post or leave a feedback!
Great post, Pat! Keep it going 🙂
very well explained Vinh Phat Tu !!
Keep posting more and more innovative ways 🙂
Hi Vinh
Thanks for your blog. I followed the steps:
I keep getting an 401 unauthorized error in my Job Scheduler service when annotating the CAP service with @requires('system-user'). Do you have any idea how to fix this?
The problem has been solved, it was cause by missing authorization configuration in my CAP project. cds.requires.auth was missing in my package.json file
Hi Phat,
Thank you for this amazing blog post which was very useful for me as I'm implementing the same use case.
I would like to share the error that I was facing maybe this will be helpful for someone.
I was facing the following error because when I have created the schedule with POST method I didn’t past the body because my end point require an empty body.
so giving an empty list "{}" in Data for the body of the request solves the issue as you can see below
Thank you and best regards,
Mariam