Skip to Content
Personal Insights
Author's profile photo Michael Keller

experiences with background jobs

Dear community, this week I’ve been working with background jobs. I haven’t done that in a long time. Below are some notes from my experience. Simply as a reminder. Instead of writing them in my notebook, the SAP Community is a much more better “storage location” 😉 Hopefully the notes will help someone.

  1. There should be a dedicated user to run a job step. The user should only be for background jobs. Don’t use a dialog user. A dialog user could be expired or be locked.
  2. Think about different dedicated job users so you don’t have one user with nearly SAP_ALL authorization (check comment of Christian Braukmüller).
  3. The name of a job should be chosen well. I chose a combination of client, module and keywords from the respective process.
  4. I was unable to provide any further information about a job in the job definition. As a result, after a short time you or your colleagues may no longer know what the job is doing, why it was scheduled and for which department it is. In my opinion, documentation must therefore be stored in another, centrally accessible location.
  5. Organizationally, the job must be assigned to someone. For example, a department. You have to talk to the department about the fact that a job has been set up for one of their processes.
  6. The scheduled times should be agreed with the job owner.
  7. The output of a job (printer, e-mail, etc.) should be coordinated with the job owner. See possibilites as B. Meijs describes in his example.
  8. A job without supervision is dangerous. At least at fixed intervals, someone should randomly evaluate jobs and what they did. Otherwise there is a risk that a job will be faulty over a long period of time.
  9. The runtime of the job should be checked. At least on the first run.
  10. Some jobs produce spool output. Others write to the business application log. In any case, a job should have some kind of feedback. Please only meaningful feedback, no messages like “nothing done” (please check the comment of Jelena Perfiljeva for further information).
  11. The “Client” column should be displayed in transaction SM37. Please check the comment of Hendrik Maas.
  12. The dedicated user for the background jobs needs the appropriate authorizations.
  13. If you deactivate a job, you should coordinate this with the job owner.
  14. If the job is designed to only have one instance running, implement logic so its only possible to have one instance running eg. via locking (note from Lars Hvam).
  15. Never allow end users to schedule periodic jobs (note from Juan Reyes).
  16. Never allocate a job to a fixed app server (unless there is a particular reason for it, note from Juan Reyes)
  17. The programs which are supposed to be scheduled as background jobs should provide troubleshooting mechanisms. For e.g., logging critical data objects with LOG-POINTS can sometimes be a lifesaver (note from Suhas Saha).
  18. Spool cleaning should be scheduled on a regular basis based on the spool retention period needed by the business (note from Mihet Marius).
  19. <your note/experience>

Please feel free to add your experiences in the comments. I’m happy to enhance the list 🙂

 

Best regards, thanks for reading and please stay healthy

Michael

Assigned tags

      22 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Lars Hvam
      Lars Hvam

      If the job is designed to only have one instance running, implement logic so its only possible to have one instance running eg. via locking.

      Author's profile photo GED HURST
      GED HURST

      Or use RSBTONEJOB2 as a first step.

      Author's profile photo Lars Hvam
      Lars Hvam

      looking at the code of RSBTONEJOB2, it just does database selects, no semaphores

      I guess if trying to start 100 jobs at the same time with RSBTONEJOB2 as first step, then much more than one actual job will trigger

      Author's profile photo Suhas Saha
      Suhas Saha

      Apparently RSBTONEJOB2 just selects using the jobname and not the actual program name. I assume that if someone was clever enough to define jobs with different names for the same program, this won’t help anyway.

      IMHO, the best way to prevent multiple instances of the program running in background is to implement some kind of locking mechanism as suggested by Lars Hvam

      Author's profile photo GED HURST
      GED HURST

      The same program could be running with different variants simultaneously. This is OK. The important thing is to prevent the same data being processed by the same program in multiple jobs.

      Author's profile photo GED HURST
      GED HURST

      Thanks Lars. Briefly, how would you implement this semaphore approach? Just create a custom enqueue object? Use a standard one?

      Author's profile photo Lars Hvam
      Lars Hvam

      yea, an enqueue object, and then if the background job has multiple commits, then make sure to set _SCOPE accordingly so the enqueue is not lost at commit

      Author's profile photo Juan Reyes
      Juan Reyes
      • Never allow end users to schedule periodic jobs
      • Never allocate a job to a fixed app server (unless there is a particular reason for it)
      Author's profile photo Michael Keller
      Michael Keller
      Blog Post Author

      Your first point is exactly the "big thing": If anyone is scheduling, you will have a massive chaos 🙂

      Author's profile photo Hendrik Maas
      Hendrik Maas

      Regarding 9: include the client

      It is possible, but not as comfortable as it could be:

      1. GoTo: Settings -> Layout -> change Layout (Ctrl + F7)
        Add Client field to the list
      2. GoTo: Settings -> Layout -> Saving (Ctrl + F9)
        Save the layout 
      3. GoTo: Settings -> Layout -> Managment (Ctrl + F5)
        Mark the saved layout as default
      Author's profile photo Michael Keller
      Michael Keller
      Blog Post Author

      Many thanks for this hint. I will have a try!

      Author's profile photo Suhas Saha
      Suhas Saha

      Here are my 2 cents:

      • Points (2) & (3): Use generic users to schedule the jobs and not to assign them to specific (end) users. This has the following advantages:
        • (end) users’ authorization profile doesn’t get bloated unnecessarily
        • these generic users can then be assigned department specific roles needed to process the batch jobs. E.g., a user GL_ACCOUNTANT doesn’t (generally) need authorization to post SD documents
      • Point (6): There should be automation in place to notify a (human) user that something has gone wrong with the job. It is not humanly possible to check productive jobs randomly
      • Point (8): The programs which are supposed to be scheduled as background jobs should provide troubleshooting mechanisms. For e.g., logging critical data objects with LOG-POINTS can sometimes be a lifesaver

       

      Author's profile photo B. Meijs
      B. Meijs

      Point 6: there is an option (in S/4HANA) to specify an Email Notification when creating a job.

      Author's profile photo Matthew Billingham
      Matthew Billingham

      In the last place I worked, I'd get messages saying that "my" job has failed. It wasn't my job. I just scheduled it but the running account was a generic user.

      Author's profile photo Mihet Marius
      Mihet Marius
      1. Some jobs produce spool output. Others write to the business application log. In any case, a job should have some kind of feedback. >>Spool cleaning should be scheduled on a regular basis based on the spool retention period needed by the business.
      Author's profile photo Thales Batista
      Thales Batista

      It takes part on documentation but even there is forgotten and only remembered when job fails: Error Handling procedures. “Who to contact, what business operations are impacted by, what operations should be suspended until solved“. Information owner is the one who requested that job, not the person who is monitoring them, yet business always try to find those answers with the monitoring one.

      (Subtle pick-up line for Job Management that I want to blog about but I’m still struggling to find a time slot to schedule its writing. I do recommend reading that Help Page and plant a subversive message to eventually implement it because addresses many points in a process-driven way)

      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      Underrated blog. It could've had a catchier title, like "Top 10 background job tips Basis people don't want you to know". 🙂

      If I rated these tips, I'd put number 10 on the list ("There should be a dedicated user to run a job step") as number one. So many problems have been created by not following this. Also, there could be different batch users, if necessary. Sometimes a business process consists of many steps, programs, and jobs involved, which makes the "whodunit" troubleshooting very difficult because some changes could be done by different jobs/programs. But change the user IDs and there you go, it quickly becomes apparent what exactly happened.

      Also one of my first SAP production nightmares was when once the system ran out of spool numbers in the middle of the night and ALL background jobs started failing. Turned out that someone put WRITE 'Nothing found' into almost every program thus generating enormous amount of useless spools. Don't do that, folks.

      Author's profile photo Michael Keller
      Michael Keller
      Blog Post Author

      Hehe, thanks 😉 I haven't changed the title. That would not be fair to the basis people. They help me so often 🙂 But I have included your other tips and hints.

      Author's profile photo Christian Braukmüller
      Christian Braukmüller

      Adding one aspect to Jelena Perfiljeva good hint:
      "Also, there could be different batch users, if necessary."

      There is one good reason to ALWAYS use different batch users:

      => If you use only one batch user for most of your jobs, you have a good chance that its authorizations are close to SAP_ALL.     (with all the risks that comes with it)

      Therefore a dedicated user for e.g. each application area is a good way to go.

      Author's profile photo Christian Braukmüller
      Christian Braukmüller

      Great idea to pick up a topic that seems to be old,
      but isn‘t.

      We are going to struggle with one or the other point at least the next 19 years with S/4. Your blog will still be found and being useful in many years. 😉

      I remember a session many many years ago ( around  release 6.20 ) at a user group meeting.
      „News around BatchJobs/Scheduling.“

      It turned out that there were just some minor additions ... and not big efforts to improve the handling. A very disappointing session. And not many changes since then.

      The list is long for things that SAP can improve BatchJobs without interrupting the stable architecture:  

      • A field to add a description would be so helpful to explain the intention of this job.  (Could be used to mention the ticket number of the request , or the interface / scenario this job is used for) 
      • Having a modern swimlane diagram  to see what is/was running in the system .. in all the BTC processes of all instances.
      • Having something like a „average runtime“ of a Job that is running periodically. That would give you an idea if the current runtime is normal or longer than usually. Call it „Predictive Processing“ and it sounds cool.

      (There are products to take care of the schedule outside of the SAP system, but the effort to set this up only pays out for customers with a larger and complex landscape .. and a team that takes care of all dependencies.
      And it hardly brings more transparency for one specific system.)

       

      Christian

      Author's profile photo Michael Keller
      Michael Keller
      Blog Post Author

      Great comment! I used to get a lot of information in 160 characters (SMS). If I only had a description text of 160 characters per job 😉 I think your suggestions for new functions are all great. I would love to have it right away.

      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      Yes! I mean how difficult is it to add a description field? Add it to the table, slam it on the screen and be done. No need to change any "design".