All topics
17 / 65
Basisbeginner

SAP Background Job Scheduling & Management

Defining, scheduling, monitoring, and troubleshooting background jobs using SM36 and SM37.

Most high-volume SAP work runs in the background: month-end runs, interface files, mass updates. A user sitting at a screen waiting for a two-hour posting run is not a workable design.

Background jobs are like a factory's overnight shift running on a punch-clock schedule - SM36 is the shift schedule board, SM37 is the shift supervisor's log book showing who showed up and what happened, and ST22 is the incident report filed when a machine actually broke down mid-shift.

Key Concepts

1
Background processes are a separate pool. Dialog work processes serve interactive users; background processes run jobs. They do not compete, which is why a heavy batch load does not freeze everyone's screens — provided the system is sized for both.
2
This is also why a long-running report should be scheduled rather than executed interactively. Run in dialog, it occupies a dialog process for the duration and hits the runtime limit, which is where TIME_OUT dumps come from.
TIME_OUT
3
Defining a job in SM36. A job is a name, one or more steps, and a start condition.
SM36
4
    step 1   program ZFI_EXTRACT   variant MONTHLY
    step 2   program ZFI_POST      variant MONTHLY
5
Steps run in sequence, and a step that fails stops the job. So a job is also a way of expressing "only do the second thing if the first worked".
6
Start conditions, and the one worth knowing.
    immediate      now
    date/time      at a fixed moment
    after job      when a named job finishes
    after event    when an event is raised
    periodic       repeats; a new run is created after each completion
7
Events beat fixed times for dependencies. Scheduling job B for 02:00 because job A "usually finishes by 01:30" works until the day A takes two hours. Then B runs on incomplete data, and nothing reports an error.
8
Raising an event at the end of A (SM64, or from ABAP) and starting B on that event removes the guess. B runs when A is actually done.
SM64
9
Monitoring in SM37. Filter by name, user, status and date; open the job log to see what happened.
SM37
10
    scheduled   defined, no start condition met yet
    released    ready to run
    active      running now
    finished    completed
    cancelled   failed
11
A cancelled job is diagnosed in two steps. The job log first — it usually carries the business error message. If the log says a runtime error occurred, ST22 holds the short dump with the full call stack.
ST22
12
Two operational habits that prevent most batch incidents.Spread the load. Everything scheduled at 00:00 competes for the same background processes, so jobs queue and the window overruns. Stagger them, and use batch server groups to spread jobs across application servers.
13
Watch for jobs that never finish and jobs that never start. A periodic job whose run is cancelled does not always reschedule, so the job quietly stops happening. Nobody notices until a report is missing at month-end, because a job that does not run produces no error.
14
What the interviewer is probing.1. "How do you keep a nightly chain in order?" Probing: the mechanism. Stalls: "Time gaps." Moves up: event-driven or successor jobs, so step two starts when step one actually finishes, not at a hoped-for time.
15
2. "Where do you look when a job fails?" Probing: the workflow. Stalls: "Ask the user." Moves up: SM37 for the status and job log, then the spool and any short dump in ST22.
16
3. "Why can a job run fine in dialog and fail in background?" Probing: the difference. Stalls: "It should not." Moves up: no screen interaction, different authorizations for the step user, and a different memory and runtime limit regime.
17
4. "What is the risk of scheduling many jobs at once?" Probing: the capacity point. Stalls: "None." Moves up: background work processes are finite, so jobs queue — and a long-running one can starve the rest of the window.
Use cases:background-jobssm36sm37batch-processing