Run SAP HANA XS JOB – Part 3
Welcome all to the next tutorial in our SAP HANA XS JOBS series where we have created an XS JOB and successfully scheduled it too in our Part 1 and Part 2 of this tutorial from within the XS JOB dashboard. If you directly landed on this page, please visit these parts before reading this Part 3 tutorial for better understanding. Since we only ran the schedule that we configured in the SAP HANA XS JOB file, this execution was a design-time job execution. But how can non-developers or admins run SAP HANA XS JOB? In this tutorial, we learn how administrators can schedule their own ‘run-time’ XSJOBs without having to code or ask a developer to code a new XS file.
Note: Run-time XS Job Scheduling is usually done by SAP HANA admins and is not a developer’s job. The developer in most cases may not even have the privileges to do this activity as per the roles granted to his/her user. So, if you are a developer and and you see that the below activities are blocked for you, contact your SAP HANA administrators and ask them to do this activity.
Run SAP HANA XS JOB as run-time object
This tutorial continues off the screen for the XSJOB we scheduled in the previous tutorial. We already have a schedule that had a DESIGNTIME origin (meaning that it was created in HANA) as shown by the below screen shot. To add a RUNTIME schedule, click on the “Add Schedule” button marked below.
This will open up a pop-up asking for the same values you would be required to code in a DESIGNTIME XS JOB in SAP HANA. Since this is primarily built for administrators, it is quite a convenient interface to add a new schedule without bothering about learning the coding syntax.
As explained in our previous tutorial, the XS Cron schedule has a special format which is also explained in this pop-up with an example. We will try to add another job which runs every hour at the 59th minute. Also, provide a meaningful description to your schedule. Mark the ACTIVE checkbox to have it as an active job. If the job accepts parameters which is true in our example where we send a material number to the running stored procedure. The parameter name was P_MATERIAL in our case and in this example, we will send the material number ‘PROD319’.
After adding these values mentioned above, your entries should be looking like the image below. If you have only one input parameter, you can choose to press OK at this point but if you have more, press the plus button marked by the arrow shown.
This will create a new row for a second input parameter. Since we don’t have a second one, we just press OK.
As seen below, a wild XS job appears (Pokemon fans would appreciate that joke) which is now marked as RUNTIME which means that the administrator created it by him/herself.
A simple select on the SALES_LOG table after the job ran proves that the data was loaded successfully as per our input parameter.
This concludes our tutorial on XS JOBs. As you must have realized by now that these Design time and run time XS JOBs are really important from the perspective of automating recurring tasks. Hope this tutorial made the concept clear enough.
Please leave your comments below where you can discuss your own project scenarios for XS JOBs or leave a comment with your thoughts and questions on the topic. Let’s keep the community alive.
As always, in return for my time and expense in providing you this free tutorial, I request you to please share it on social media so that it grows in search rankings and benefits others as well.
If you feel the website helped you, please also contribute any small amount by using the “Donate button” on the right side of this page to help with the operational costs of this website and other systems involved.
Thank you for reading and wish you well on your HANA journey.
This is really a very informative and complete tutorial for XS jobs. The only thing i saw missing is the about the access required to create, schedule jobs are not included in the tutorial(the different hana roles .xsjobadmins, etc). For example if a job has been created to update a certain table then in order to successfully execute the job the user must have access to update that certain table otherwise the job might fail to execute. This is based on my understanding and may not be true exactly.
Hello sir,where was the object name(procedure) which needed to be triggered is mentioned ?
Thanks for detail and simple examples.
When creating the run time XS job, how the procedure name is passed?
Can I say, we can use the XS job scenario to take snapshots at a point of time, this could be a business requirement
in most of the projects.
Hi Shyam,
I added two new xsScheuler jobs, but for some reason the Stored Procedures used in these jobs are not loading data into the tables even after successful run of XS Jobs.
The same package has two other xsSecheduler jobs which was created last year, these run fine and load data.
Not sure what am I missing with the new scheduler jobs we created last week, any suggestions ?
Thank you!
Ravi