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!