SAP operations guide
Before You Rerun a Canceled SAP Background Job: Collect This Evidence
A canceled background job tells you that execution did not finish normally. It does not tell you whether nothing happened, some work completed, or another attempt is already processing the same input.
Before rerunning it, assemble enough evidence to answer three questions:
- Which execution failed, and where?
- What work may already have completed?
- What recovery action does the application support?
This guide covers classic SAP AS ABAP background jobs inspected through SM37, as commonly encountered in ECC and S/4HANA on-premise or private-edition environments. Check your system release, permissions and application runbook before applying it. It is an evidence-gathering guide, not a universal restart procedure.
1. Identify the exact execution
Start in SM37 and find the affected run. Record:
- SAP system and client.
- Job name and job count or ID.
- Scheduled and actual execution times, where available.
- Execution user, server and relevant step.
- Current status and the timestamp of your observation.
Preserve the displayed timezone or offset separately. When correlating records from different systems, keep the original timestamps as well as any converted values.
Job names repeat. A screenshot showing only the name and a red status may leave the next engineer investigating the wrong execution. SAP's job status analysis describes the job attributes and execution details available for diagnosis.
2. Preserve the job log and message details
Open the job log and retain the relevant sequence of messages, including the context before the failure. Where available, capture message identifiers and long text.
SAP documents displaying a job log in SM37. Preserve the evidence in the approved incident record before cleanup or retention processes remove it. Restrict access because logs may contain business information or identifiers. See SAP's current Displaying a Job Log documentation.
If the log is unavailable, record that explicitly. “No log could be retrieved” is an evidence limitation, not proof that the program produced no effects.
Also determine whether someone deliberately canceled the job. SAP lists intentional administrative termination as one possible explanation for the Canceled status. A deliberate cancellation may have a business or operational reason that still applies; see Possible Status of Background Jobs.
3. Establish which steps completed
Inspect the step list and available outputs. Identify the failing step and any earlier completed steps.
SAP's classic Jobs and Job Steps Explained documentation notes that abnormal termination of a later job step does not roll back work committed by an earlier completed step. A canceled job must therefore not be treated as an all-or-nothing business transaction.
Ask the application owner what completion means for this program:
- Were business documents created?
- Was input marked as processed?
- Were files or messages sent downstream?
- Does the program support repeat execution without duplicating effects?
- Is there an application-specific recovery procedure?
These questions require application evidence. A technical status alone cannot answer them.
4. Correlate the failure with the right supporting records
Use the job's time window, execution context and error text to choose the next check.
| Evidence | When it helps |
|---|---|
| ST22 dump | The job indicates an ABAP runtime error, or a matching dump exists. |
| SM21 system log | The failure suggests a system-level event; inspect the relevant execution server and time window. |
| SLG1 application log | The application writes a relevant log and its object or run identifier is known. |
| Job spool/output | The step produced output that can clarify progress or the error. |
| Application records | The owner needs to establish what was actually committed, sent or processed. |
SAP's ATC troubleshooting guide gives one example of correlating a job log with ST22 and SM21 evidence. That is an investigation pattern, not proof that every canceled job creates a dump or system-log error. SAP's application-log documentation covers SLG1; its usefulness depends on the application's logging.
Treat a nearby error as a lead until the identifiers and execution context support the connection.
5. Check the next attempt and dependencies
Before proposing a rerun, inspect periodicity, linked jobs and any external scheduler involved. SM37 job details can show repetition information and linked jobs; see SAP's Managing Jobs from the Job Overview documentation.
The operational question is whether a new attempt would overlap with another execution or conflict with downstream processing. Ask who owns the schedule and whether recovery requires coordination.
Inspect first. Changing schedules, canceling another run or releasing a copied job are separate operational actions that need the appropriate procedure and authorization.
6. Record the recovery decision
A useful handover separates facts, interpretation and unresolved questions.
| Item | Record |
|---|---|
| Observed failure | Exact execution and supporting error evidence |
| Partial completion | What is confirmed, what is uncertain, and who can verify it |
| Cause | Confirmed cause, or clearly labeled working hypothesis |
| Recovery prerequisite | What must be corrected or checked first |
| Proposed action | Approved retry, application-specific recovery, or escalation |
| Ownership | Decision owner and execution owner |
| Verification | Expected technical result and business reconciliation |
Fictional example: a two-step custom job records a successful first step and a failed second step. The correct next action cannot be inferred from those statuses alone. The application owner needs to establish what the first step committed and whether repeating the full job would repeat that work.
If the error disappears on another attempt, record that outcome without automatically declaring the root cause resolved.
How this relates to BasisPilot
BasisPilot is being developed around operational signals, incidents, evidence, and human-controlled investigation.
The public Interactive Demo illustrates that investigation approach using fictional deterministic data. It does not connect to a live SAP system or AI service.
Real-environment access is opening gradually through the BasisPilot Private Pilot.
Further reading
- SAP: Possible Status of Background Jobs
- SAP: Jobs and Job Steps Explained
- SAP: Analyzing the Job Status
- SAP: Displaying a Job Log
- SAP Help: Troubleshooting a Failed ATC Quality Check
- SAP Help: Application Logging
- SAP: Managing Jobs from the Job Overview
The evidence checklist and recovery decision structure are editorial operational recommendations. Recovery steps must follow the documentation and ownership arrangements for the affected application.