SAP Jobs

Many SAP tasks are too long or too regular to run interactively, so they run as background jobs on background work processes. Examples: nightly MRP, periodic billing, data extracts, and interface processing. Jobs have steps (programs to run), a schedule, and a target server.

• SM36: define/schedule a job (steps, timing, variants).
• SM37: monitor jobs, their status (scheduled, released, active, finished, cancelled) and logs.
• Set up job chains and event-triggered jobs for dependencies.

A job is a small structure and knowing its parts makes both scheduling and diagnosis easier.

Steps. A job contains one or more, each a program or an external command, run in sequence. A multi-step job stops at the first failing step, which is how a dependency is expressed within one job.

A variant per step, holding the selection parameters. This is where a job that ran correctly for a year starts producing nothing, because somebody changed the variant rather than the job.

A start condition. Immediate, at a date and time, periodic, after another job, after an event, or when a specific operation mode begins. The two worth knowing are after job, which is a real dependency, and event driven, which is how an external system triggers processing when a file arrives.

A user. The job runs under an account, and its authorisations decide what it can do. A job scheduled by somebody who has left, running under their locked account, is a classic overnight failure.

A target server or group, which decides where it runs and is how heavy work is kept off the instance users are on.

The distinction between time-based and dependency-based scheduling is the one that matters most: jobs chained by time carry on regardless of whether the previous one worked, and jobs chained by successor relationship do not.

Cancelled or delayed jobs are a common operational issue, a failed nightly job can leave the business without expected results in the morning. Administrators monitor SM37, investigate cancellations (often via the job log and any dump), and reschedule or fix as needed.

The practical discipline is filtering rather than scanning. SM37 with a status filter of cancelled, for the last day, across all users, is a ten-second check that finds the thing that matters. Scanning the full list finds nothing because there is too much of it.

The second check is long running: jobs still active far beyond their usual duration. Knowing what usual is comes from watching, which is why recording typical runtimes is worth the effort.

Worth knowing what the job log does and does not contain. It holds the job's own messages and the messages any program in it issued, and it does not hold the short dump if one occurred. So a job that ended in a dump shows an unhelpful log and the real information sits in the dump analysis, keyed by the same time and user. Checking one without the other is how a root cause gets recorded as unknown. See system logs.

Half an hour, and it covers what goes wrong in practice.

1. Create a job with SM36, one step running a simple report with a variant.
2. Schedule it periodically, every few minutes, and watch it in SM37.
3. Read the job log for a successful run. It shows start, the step, messages and end.
4. Now change the variant so the report selects nothing. The job still succeeds, and produces nothing. That is the failure mode nobody alerts on.
5. Change the step to a program the job's user has no authorisation for. Now it cancels, and the log names the missing authorisation.
6. Schedule a second job to start after the first, then make the first fail. The successor does not run, which is the dependency working.

Step four is the important one. A job that succeeds and does nothing is invisible to every standard check, and only a business person noticing missing output finds it.

A single job on a clock is the easy case. Real landscapes run sequences, and the interesting question is how the second job knows the first one finished.

Three mechanisms, in increasing order of reliability.

Start at a fixed time, later than the first job usually finishes. This is the most common arrangement in the wild and it is a guess. It works until the first job takes longer than usual, which is exactly the day it matters, and then the second job reads half updated data.

Start after job. The second job is defined to start when a named job ends. This is correct and it is free. The detail worth knowing is that it triggers on the job ending, not on it succeeding, so the successor also runs after a failure unless you say otherwise.

Start after event. A job waits for an event, and something raises that event when the work is genuinely done. This handles the cases the other two cannot: a file arriving, an external system signalling, a chain that spans systems.

The design rule that follows is simple to state and often ignored. If a downstream job would produce wrong output rather than no output when its predecessor fails, it must not be on a clock. Wrong output is worse than a late report, because somebody acts on it.

Background jobs need enough background work processes; too few and jobs queue and delay. Balancing dialog vs background work processes is part of keeping both interactive users and batch work healthy.

The planning consequence is that the nightly window is a resource with a limit. Jobs scheduled at the same time compete for background work processes, and a queue forms invisibly: each job runs correctly and finishes later than intended, until the batch overruns into the working day. Staggering start times and using job classes to prioritise is the answer, and it is easier before the window is full than after.

The distinction that decides most capacity questions is class versus type. The job class (A, B or C) sets priority, and class A jobs can reserve work processes so a queue of routine work cannot starve something critical. Reserving too many is the opposite failure: the reserved processes sit idle while everything else waits. A landscape where every job is class A has no priorities.

• Not monitoring SM37 for cancelled jobs.
• Too few background work processes, jobs queue.
• Ignoring job dependencies, running steps out of order.

• Jobs running under a personal account. The person leaves, the account is locked, and the job fails at two in the morning.
• Time-based chaining where a dependency was meant. The second job processes data the first never produced.
• No alert on cancellation. See transports, users, system logs and authorisations for the neighbouring areas.

Finally, a job left scheduled by somebody who has left the company, running a program nobody recognises, is a standing risk rather than a curiosity. An annual review of what is scheduled and why is short work and regularly finds jobs that have been failing quietly for months.

Scheduling a job is a few screens, and designing the nightly batch with its dependencies, priorities and alerting is the part you do in the course.