Skip to Content

Do you want to know how much backend workload is caused by background jobs?

In the previous blog The 5 most common customer goals related to Job Scheduling Management I highlighted several problem statements from customers. One of those typical customer statements was “we assume 30% of our daily background jobs are no longer needed…we just don’t what the 30% are”. In the following I outlined the answer by mentioning the Job Scheduling Management Helath Check and I wrote “This is first a problem of visibility and transparency but at the end customers want to get rid of the x% of unnecessary jobs in order to save hardware resources. These clean-up activities are often missing at customers. Additionally many customers do not have any systematic approach on what and how to clean-up the existing job schedule. Answer to this problem: The Job Scheduling Management Health Check in SAP Solution Manager can extract job workload data from the respective SAP backend system and stores it in dedicated InfoCubes within the SAP Solution Manager. The application provides then standard web templates with queries that shall show which jobs cancel or finish most often and cause the highest workload. It also shows which users created/scheduled the most jobs and how many jobs are executed on which application server and cause how much runtime.”


Within this blog I want to give some more details on this tool and I also want to draw your attention to the newly released “Job Scheduling Management Health Check – Setup Guide” document which you can find attached to SAP note 1516666 or on the SAP Service Marketplace (SMP login required) at > Media Library or directly here.



The Job Scheduilng Management (JSM) Health Check uses the Extractor Framework (EFWK) of SAP Solution Manager Diagnostics (SMD) to extract and to aggregate job execution data from respective managed systems into InfoCubes located in the SAP BW component of SAP Solution Manager. All jobs in selected managed systems with a final status (“finished” or “cancelled”) are considered for the JSM Health Check. The extracted data can be displayed via predefined Web Templates which execute queries on respective InfoCubes. The InfoCube data is updated by extractors on an hourly basis. Two different extractors are available to extract job execution data from the managed systems. The first one only takes the job execution header information from table TBTCO into account, while the other extractor combines data from job execution header (TBTCO) and job execution item (TBTCP) table.




The web template illustrate different KPIs with the following information (graphically as well as in tabular views):

  • Job Status Analysis: Finished vs. Canceled (number of jobs as well as accumulated duration of jobs, top long runners; etc.)
  • Workload Distribution (per job duration; per start delay; by creation or scheduling user; by execution server; etc.)

The graphical views enable an easy overview about the job execution status and distribution in the managed systems.

The tabular views provide more detailed information via drilldown functionality. In addition these tabular views can also be exported as MS excel files.

With such reports, the JSM Health Check provides you an overview about the job scheduling situation and system workload caused by background jobs in the managed systems, thus enhances the transparency of the existing job schedule and jobs which are causing problems or which can be improved.

In SAP Solution Manager 7.1 the dashboards are fully integrated in the Job Management Work Center. In SAP Solution Manager 7.0 the end user can execute the dashboards directly via Web Templates URL, i.e. as favorites in the SAP system or as favorite shortcut directly from an internet browser (after additional configuration).

For more information refer to the “Job Scheduling Management Health Check – Setup Guide” document which you can find attached to SAP note 1516666.

SAP Teched 2011 

Visit us also on SAP TechEd 2011 at ALM264 – Manage Your Background Jobs Using Job Scheduling Management

In this hands-on session you will learn how to manage background jobs with SAP Solution Manager. With reference to the Solution Directory, you may document, request, schedule, and monitor jobs using the external job scheduling tool SAP Central Process Scheduling by Redwood. In addition, you will get an introduction of how to optimize your job schedule concept using Job Scheduling Management Health Check in SAP Solution Manager.


Frequently Asked Questions about Job Scheduling Management are answered under

If you are interested in further reading. The following blogs (in chronological order) provide further details about Job Scheduling Management functionalities within the SAP Solution Manager.

You must be Logged on to comment or reply to a post.
  • Hello Volker

    I just tried this out the Job Scheduling Management Health Check on my Solution Manager 7.1 sandbox and it’s pretty interesting I must say.

    I already thought so when I saw the blog but hands-on is always more interesting than seeing a few screenshots of course.

    I did have to do a couple of steps manually (stolen from the Sol Man 7.0 configuration in the PDF in attachment of SAP Note 1516666 – Job Scheduling Management Health Check – Setup Guide) because for some reason the BI Extractor Jobs where missing although the system meets the recommended prerequisites.

    Kind regards


    • Hello Tom,

      nice to hear that the tool is live even better than described in my blog. Thank you for the extractor job remark – we will have an eye on it if it also happens with other 7.1 customers.

      Best Regards

      • Hello Volker

        Some more feedback/questions after playing around in the Job Scheduling Health Check.

        Is it possible to have a drilldown concept like in Root Cause Analysis so you can choose the metrics on top to dive into or is the data from the Job Scheduling Health Check also visible somewhere else where this is possible?

        I noticed that most of the times the Scheduling User is one of the metrics. I do understand the reason because it makes it possible to see who scheduled the job but one important metric I’m missing is the Job step executing user.

        For example when someone leaves the company it would be useful to track down all the spots that his/her userid is executing a job step to make sure those are changed before removing the user.

        Another good reason is just the fact that background job steps shouldn’t run on personal users but should have technical/generic users instead.

        Kind regards


        • Hello Tom,

          I am wondering what you are actually missing in the drill-down functionality. If you look at the tabular queries then you can typcically drill-down to the job name or job count (in the daily view) level. I personally do not find the web template UI flexible enough so that we are considring to change the UI to some business graphics in one of the next releases.

          With regards to the reported user. If you only extract TBTCO data then only the “Craetion User” is available. If you also extract TBTCP data then you should see some additional query where the (more meaningful) executing user is also evaluated.

          Best Regards

          • Hello Volker,

            I checked in our system and indeed the job step wasn’t included in the reporting at first. I can see the execution user of the respective job step now in the reporting so you can disregard my comment on the fact that the execution user metric seems to be missing.

            However I can’t find a good way to provide an answer to my question though, an overview of which job steps run under user X in system Y.

            As a system administrator and I do believe this functionality will often by used by system administrators it would really come in handy that I can see which job steps run under user X without having to drill-down each job and job step first to get to the result.

            End-users are not supposed to be running those job steps with their own user-id but it happens nevertheless. Sometimes due to wizards being executed, sometimes on purpose. When such an end-user leaves the company, this results in jobs that are cancelled and possibly impact the business. To avoid that we should know up front where their user-id is running background job steps. This health check report is the ideal place to insert such a graphic / tabular drill-down.

            I see a top 10 executing user – number of jobsteps which is currently available. In fact adding a (all) executing user graph / tabular drill-down would already do the trick.

            I hope my explanation makes sense, you are always welcome to contact me and talk about it.

            It’s definitely not my intention to criticize. I’m trying to provide constructive feedback to a very interesting new feature.

            Kind regards


          • Hello Tom,

            thank you for your feedback. As you said I take it as constructive feedback in order to enhance the application even further and wouldn’t see as criticism.
            Your idea about the user list is a valid one and we will see if and how we can realize it in a next SP, perhaps some additional dialog on the entry screen will be provided.
            For the moment I would see two possibilities to gain this info. Either you know how to deal with BEx Query designer and try to adjust the existing query so that the Top 10 user restriction is removed. Or you check the user directly in the backend system and use workload transaction ST03 as it also lists executing users on step level when it comes to background tasks. Go to ST03 > Select time frame & server (ALL) > Transaction profile > Task type “background”