Lesson 3 of 6
Batch window testing
9 min
Listen to this lesson
Many SAP failures after go-live are not slow screens. They are a billing run that finishes at 09:30 instead of 05:00, an MRP run still going when the plant starts, or a close step that waits for a job that waits for an interface. Batch window testing proves that the job chain, with production volumes, finishes before the business needs the results.
How SAP background processing works
A background job is defined (transaction SM36 or the job wizard) with one or more steps, a job class and a start condition, and monitored in SM37. Each job runs without interruption in one background work process. Start conditions are time-based or event-based; event-based starts include starting after another job finishes, which is how job chains are built inside SAP. Job classes A, B and C set priority when jobs compete, and Basis can reserve work processes for class A jobs. Programs can also spread work across dialog work processes in parallel, controlled by server groups. In SAP S/4HANA, many technical housekeeping jobs are scheduled automatically by the Technical Job Repository.
- 22:00Order intake cut-offEDI and web orders received; deliveries created
- 22:30Goods issue completeShipping points 1710 and 1720 finish posting
- 23:00Billing runInvoices for all goods-issued deliveries, then output
- 01:00MRPPlants 1710 and 1720 planning run
- 03:00Interfaces outInvoices to EDI, planned orders to suppliers
- 05:00Business deadlinePlanners and customer service start work
Designing the test
- Map the chain: every job, its predecessor, its variant, its volume driver and the business deadline it serves. Include external schedulers and interfaces.
- Load realistic data: a day's volume (or a month-end day's) of open deliveries, orders and documents in the test system.
- Run the real chain with production variants and start conditions, not jobs started by hand one by one.
- Measure start, end and elapsed time per job, waits between jobs, and work process usage during the run.
- Compare with the deadline and with ECC baselines from EP1, and record the critical path.
- Test recovery: cancel a job mid-chain and rehearse the restart procedure the operators will use.
- Does the chain finish before the business deadline with peak volume?Yes → check margin · No → find the critical path
- Is the margin at least the agreed buffer (for example 25%)?Yes → pass · No → treat as at risk
- Is the longest job limited by parallelization or by work processes?Yes → tune job design or server groups with Basis · No → analyze SQL and custom code
- Can a failed job be restarted within the remaining window?Yes → document restart · No → redesign or move the deadline with the business
Typical findings
- A job that ran in 20 minutes in ECC takes two hours because adapted custom code now reads a much larger table.
- Two heavy jobs scheduled at the same minute compete for background work processes while others sit idle.
- The critical path runs through an interface job whose start depends on a file from a partner that arrives late.
- The chain finishes on time, but only when nothing fails; a restart pushes it past the deadline.
What would you do?
In the batch test, MRP finishes at 04:40 against a 05:00 deadline. Everything passed. What should Priya report?
- Batch window tests prove that the real job chain finishes before the business deadline with real volumes.
- Map jobs, predecessors, variants, volume drivers and deadlines; run the chain with real start conditions.
- Measure each job and the critical path, compare with ECC baselines, and keep a margin.
- Rehearse restarts; a chain that only works when nothing fails is at risk.
Check your understanding · not graded
Lesson check
1. How are SAP jobs chained so one starts after another finishes?
2. Which transaction monitors background jobs?
3. Why rehearse a restart in a batch window test?
4. What is the critical path of a batch window?