Skip to Content
Product Information

Re-directing transactions SM36, SM37, SA38: Controlling end-user scheduled jobs – Part 1

The following was already mentioned in a previous blog (see Job Interception: Controlling end-user scheduled jobs) and shall be again used as introduction for this blog as it hits the nail on its head: “Controlling background jobs that are scheduled by end-users is one of the top challenges for customers. End-user scheduled jobs that bypass a central scheduling are undermining all efforts of controlling the batch workload on a backend-system. So especially during times like Period End Closing, end-user scheduled jobs have led to overload situations of customer systems. Besides the problem of undermining a meaningful workload distribution, jobs that are run outside a central scheduling tool are usually not covered by any Service Level Agreement and are hence not properly monitored by the corresponding scheduling team. End-user jobs are also nowhere documented and no error-handling procedures exist. So even if these are covered by monitoring nobody knows how to react in case of an exception.”

Because SAP has taken this challenge very seriously a technical solution was provided early on – the Job Interception as part of the eXternal Batch Processing (XBP) interface version 2.0 (see Job Interception: Controlling end-user scheduled jobs). This technical solution was already made available to customers in Q1/2003. While it allowed getting back central control over all end-user scheduled jobs it could not overcome the problem that these jobs were not properly documented and running outside Service Level Agreements as well as that end-users did not follow a proper governance and procedure to request background jobs. This is a kind of compliance breach and its relevance should be checked for audits.

If you followed blogs on Job Scheduling Management over the last two years you will have recognized that SAP provided a complete Job Management Suite (SAP is first vendor to provide a comprehensive Job Management Suite) which supports a complete background job lifecycle (request, document, schedule, monitor and report on a job).

This blog describes how the developments made for the Job Management Suite are now brought together with developments made for the job interception and integrated with standard transactions SM36, SM37 and SA38. While part 1 of this blog is explaining the concept behind, the (separate) second part of the blog will be more hands-on explaining some configuration and giving a step by step run through of the scenario.


Explaining the concept:

The concept is quite simple and will be explained by means of SM36 (for SM37 and SA38 the same mechanisms are working). Many customers have policies in place where they cannot remove authorizations for transactions like SM36 or the authorization cannot be removed because then no background scheduling out of business transactions would be possible either. This solution described here will “disable” the direct scheduling functionality without taking authorizations away! Hence every end-user with SM36 authorization can call transaction SM36 like he is used to, but instead of accessing the SM36 screen he will be re-directed into a web-form provided by SAP Solution Manager. This form contains basically the same fields as SM36. Based on the data maintained by the end-user (one-time job vs. re-occurring job) this web-form decides whether the job is directly scheduled in the respective backend system or whether a Job Request is created and the job needs comprehensive documentation (within SAP Solution Manager) before it is centrally scheduled by the corresponding scheduling team. With this solution it is ensured that all re-occurring background jobs (that end-users tried to schedule via SM36, SM37 or SA38) have to follow a defined request process and are centrally documented in SAP Solution Manager.

Remark: Based on customer feedback it will be also possible to customize the solution in a way that ALL background jobs (also one-time jobs) have to go through the documentation process. So an optional all or nothing principle can be configured.


Periodic jobs

The graphic above shows the process in case of a periodic or re-occurring background job. The “Job Control” web form, that automatically collects and inserts system and user information from the managed system, will create a Job Request when saved. Out of this Job Request a Job Documentation can be created and then background job can be scheduled either via the BC-XBP interface or via the SAP Central Process Scheduling by Redwood tool.


One time job

The graphic above shows the process in case of a one-time or ad-hoc background job. The “Job Control” web form, that automatically collects and inserts system and user information from the managed system, will directly schedule the job via the BC-XBP interface in the managed system and no Job Request or Job Documentation is created in SAP Solution Manager. In order to keep central control over all jobs the job interception functionality of BC-XBP can be used, e.g. in combination with the SAP Central Process Scheduling by Redwood tool.


For details about technical prerequsites and basic configuration steps, please read Re-directing transactions SM36, SM37, SA38: Controlling end-user scheduled jobs – Part 2


List of selected related SDN blogs:

You must be Logged on to comment or reply to a post.
  • See SAP note 1383398 for information about how to setup the SM36/SM37 integration.
  • Hi, does this redirecting of end-user scheduled jobs apply if the user chooses the top right option “Program > Execute in Background”?

    It should also work for webgui transactions right?


    • Hello Gordon,

      no this option is not (yet) re-directed. The problem here is that every SAP application uses an API for scheduling jobs and every application was free to decide how they use this API. Hence we cannot simply re-direct all these activities before we have a better overview how differently the API is used.

      Best Regards

      • I see. That’s a shame, cos the majority of end-users schedule background jobs this way (at least in the projects I’m in).

        Thanks for clarifying!

  • Hi Volker,

    Congrats for the wonderful blog. I have a quick question, can you suggest how we can control SA38. I have same expectations for this transaction like SM36.

    In other words I want that system will take SA38 to the solution manager Job request form/ template as it is doing it for SM36.

    Please suggest the configuration or document for this, if possible.


  • Hi

    Thanks Volkar for quick response. I did the all the confoguration as suggest by your blog SM36 is working but not SA38,. Any suggestions….?

  • Hi Volker and Martin.

    How to exclude certain programs from restrictions JSM (redirection to SAP Solution Manager) ?

    We have the requirement to exclude from JSM jobs of financial closing of month.



    • Hello Alexey,

      the second part of the blog describes the Criteria Manager that needs to be configured. There you can include or exclude user names that shall be re-directed or not. Probably most closing jobs are triggered directly from some FI or CO transaction and hence would not be re-directed anyway.



      • Hello Volker,

        Thanks for a prompt response!

        We use CRIT exception only for the superuser’s exception.

        During financial closing,
        50-70 business users can plan jobs, then change start time.

        They plan in transaction of ckmlcp as a once period job.


        they change date\time of start of the job in transaction of SM37.

        Feature of this process in that,
        that the number of programs of closing of month is limited and doesn’t change.

        And here the list of business users changes every time of times a month.

        In my opinion,
        More effective than a message the list of exceptions according to programs, but not on users.

        Would be great to get feedback from you.

        Best regards,