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