Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 3 of 5

Background processing

10 min

Listen to this lesson

0:00 / 8:10

Much of an SAP system's work happens without anyone watching: billing runs, MRP, payment runs, interface processing, housekeeping. These run as background jobs in background work processes. Basis owns the job infrastructure; application teams own most of the jobs. Both need to read a job overview fluently.

Defining a job

A job is defined in SM36 (or with a wizard) and consists of one or more steps. A step is an ABAP program, usually with a variant that fixes its selection parameters; an external command predefined in SM69; or an external program (administrators only). Each step runs under a step user, whose authorizations apply. Technical background users should be of user type System, which cannot log on in dialog.

Start conditionExample at Contoso
ImmediateRe-run a failed interface job now
Date/time, optionally periodicBilling due list every night at 01:00 for sales area 1710 / 10 / 00
After jobPrint delivery notes only after the delivery creation job finishes successfully
After eventStart inbound processing when an interface raises a user event
At operation modeStart when the system switches to night operation

Start conditions in SM36. Any time-based start can be made periodic, and a "no start after" time can be set.

Jobs have a job class: A (highest priority), B or C (normal and the default). Class only matters when jobs compete for background work processes at the same moment. SAP training recommends that around 90% of jobs run as class C without a fixed target server, so the system can balance them across instances.

Statuses and monitoring

  1. ScheduledSteps defined but no start condition; the job will not run
  2. ReleasedStart condition set and authorized; waiting for its time or event
  3. ReadyStart condition met; queued for a free background work process
  4. ActiveRunning; cannot be changed or deleted
  5. Finished or CanceledFinished: all steps succeeded. Canceled: a step failed or an administrator stopped it
The life of a background job as seen in SM37.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-201

The job overview, SM37, filters jobs by name, user, status and date, and gives access to the job log (every message the program wrote), the step list and any spool output. A job that stays Ready for a long time usually means no free background work process; one that is Canceled needs its log read before anyone restarts it.

Where a job runs matters too. A job without a target server can start on any instance that has background work processes, and the scheduler balances jobs across instances; the time-based scheduler checks for due jobs at an interval set by profile parameter rdisp/btctime (SAP training gives 60 seconds as the default). Pin a job to a server or server group only when it needs specific resources, such as the Contoso MRP run for plants 1710 and 1720. Every pinned job is one more thing that breaks when an instance is down.

From Released to Finished: the time-based scheduler finds due jobs, and the job waits as Ready until a background work process is free.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-201

Events and job chains

Events let jobs react to things that happen. SM62 lists events and SM64 triggers them; programs and external tools can also raise events. Chaining jobs with "after job" start conditions builds simple job chains: a successor can be set to start only if its predecessor finished successfully. Long, business-critical chains, such as the nightly order-to-cash batch, deserve a diagram, an owner and a defined restart point for each step.

An 'after job' chain with the success condition: if the inbound job is canceled, delivery creation never starts, and the restart point is the failed step.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-201

SAP technical jobs in SAP S/4HANA

In SAP S/4HANA, SAP's own periodic housekeeping jobs are scheduled automatically by the technical job repository (transaction SJOBREPO), which replaces the old "standard jobs" function in SM36. Administrators can review the delivered job definitions, change some attributes within limits, or deactivate a job, but should not schedule duplicates by hand. Application teams schedule business jobs, such as billing or MRP runs, through job templates in the Fiori app Application Jobs or through SM36, depending on the process.

  1. 22:00Interface inbound jobLoads orders received from Great Lakes Fleet Services
  2. 23:00Delivery creationStarts after the inbound job finishes successfully
  3. 01:00Billing due listPeriodic job for sales area 1710 / 10 / 00
  4. 02:30MRP runPlants 1710 and 1720, pinned to instances with spare background capacity
  5. 06:00Morning checkBasis reviews SM37 for canceled or long-running jobs before users arrive
A simplified Contoso night batch. Each step has an owner and a restart rule.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-201

What would you do?

The billing due list job in CMP was Canceled at 01:12. Maria's team needs invoices out by 08:00. What should Sam do first?

Key points
  • Jobs are defined in SM36 and monitored in SM37; steps run programs with variants under a step user.
  • Start conditions: immediate, date/time (periodic), after job, after event, at operation mode.
  • Statuses: scheduled, released, ready, active, finished, canceled. Read the job log before restarting.
  • In SAP S/4HANA, SJOBREPO schedules SAP technical jobs automatically.

Check your understanding · not graded

Lesson check

  1. 1. Which transaction monitors background jobs?

  2. 2. What does status Ready mean?

  3. 3. Which job class is the default?

  4. 4. What schedules SAP's technical housekeeping jobs in SAP S/4HANA?