Most SAP users run reports interactively — they open a transaction, fill in parameters, press F8, and wait for results. This works fine for a 200-row report that finishes in ten seconds. It breaks down the moment the report takes ten minutes, or needs to run at 2 AM, or needs to run every single day.

Background jobs solve all three problems:

• Long-running reports — the job runs on a background work process. Your session stays free. You can log off completely.
• Scheduled execution — jobs run at a defined time without anyone logging in. Overnight batch runs, month-end jobs, daily payment runs — all scheduled.
• Recurring automation — a job scheduled to run every day at 6 AM just keeps running. No one needs to remember to trigger it.

Work processes in SAP

SAP's application server has a fixed pool of work processes — the parallel execution slots that handle user requests. There are different types:

• Dialog (DIA) — handle interactive user requests. Limited in number. If all are busy, the next user request waits.
• Background (BGD) — handle background jobs. Separate from dialog processes. Running a heavy report in background doesn't slow down interactive users.
• Update (UPD) — handle database write operations.
• Spool (SPO) — handle print and output requests.

When to use background instead of interactive

Use background whenever:

• The report or program takes more than a few minutes
• You need results at a specific time (e.g. before people arrive in the morning)
• You need the same job to run repeatedly (daily, weekly, monthly)
• You're running a data-modification program (payment run, depreciation run) — these should always run in background with a controlled, documented schedule

The golden rule: any program that touches lots of data or takes significant time belongs in background.

The three key transactions

• SM36 — Define and schedule a background job
• SM37 — Monitor and manage background jobs
• SP01 — View spool output (the "printed" results of a background job)