ABAP Developmentadvanced

Debugging Part 10: Production Debugging — Evidence First

Key takeaway

Handle production issues safely: evidence collection without debugging, read-only analysis tools (ST22, SM37, SLG1, SM13, ST05, STAD, SAT), when debugging in production is justified, risks (locks, changed values, commits), approvals and firefighter access, and closing incidents with root cause and prevention.

Explanation

📌 KEY POINTS
✅ In production, collect evidence first with read-only tools: ST22, SM37 logs, SLG1, SM13, SM21, STAD, WE02/BD87, table data (SE16N display).
✅ Reproduce in QA with production-like data whenever possible — most issues can be solved there.
✅ If debugging production is unavoidable: approved access (e.g. firefighter), read-only (no value changes), no stepping through COMMIT paths, short sessions.
⚠️ The debugger in production can hold locks and database cursors, block users and — if values are changed — create inconsistent documents. Many companies log and audit every production debug session.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–9 taught techniques. This final lesson applies them where mistakes are most expensive.

━━━━━━━━━━━━━━━━━━━━
▶ 1. EVIDENCE WITHOUT DEBUGGING

Error message ID/number, user, time, transaction (from user or STAD).
Dumps (ST22), job logs (SM37), application logs (SLG1), update errors (SM13), system log (SM21).
Data state: SE16N display, change documents (CDHDR/CDPOS), document flow.
Performance: STAD, ST05 in a controlled window.

━━━━━━━━━━━━━━━━━━━━
▶ 2. REPRODUCE OUTSIDE PRODUCTION

Copy relevant data to QA (or use a recent system copy).
Same customizing and transport level? Compare versions (SE38 version management, transport logs).

━━━━━━━━━━━━━━━━━━━━
▶ 3. WHEN PRODUCTION DEBUGGING IS JUSTIFIED
Only if the issue depends on production-only data/state and read-only tools are exhausted — with approval, limited scope, and a second person informed.

━━━━━━━━━━━━━━━━━━━━
▶ 4. RULES DURING PRODUCTION DEBUGGING

Read-only: no variable changes, no "Go to statement", no skipping checks.
Avoid long pauses inside locked sections or open cursors.
Don't debug posting programs through the commit; stop before.
Document the session (firefighter log, ticket).

━━━━━━━━━━━━━━━━━━━━
▶ 5. CLOSING THE INCIDENT

Root cause (code, data, customizing, authorization, infrastructure).
Fix via transport with test evidence; data correction with approved programs.
Prevention: monitoring, validation, ATC checks, regression tests, knowledge article.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Write an evidence checklist for your team's top incident type.
Practise reproducing a production issue in QA with copied data.
Review your company's firefighter/debug approval process.

✅ CHECKPOINT: you handle production issues with evidence first and minimal risk.

Code example

ABAP Code

* ===== Production incident checklist =====* 1 Evidence    : message ID/number, user, time, transaction (STAD), screenshots* 2 Logs        : ST22, SM37, SLG1, SM13, SM21, WE02/BD87, /IWFND/ERROR_LOG* 3 Data        : SE16N (display), change documents CDHDR/CDPOS, document flow* 4 Versions    : transport logs, SE38 version management (what changed recently?)* 5 Reproduce   : QA with copied data; debugger there* 6 Prod debug  : only if needed, approved (firefighter), read-only, no commit paths* 7 Close       : root cause, fix + test evidence, data correction, prevention * ===== Read-only helper: recent changes of a document (change documents) =====REPORT zprod_change_docs. PARAMETERS: p_class TYPE cdobjectcl DEFAULT 'VERKBELEG',            p_objid TYPE cdobjectv  OBLIGATORY. DATA: lt_cdhdr TYPE STANDARD TABLE OF cdhdr,      ls_cdhdr TYPE cdhdr. START-OF-SELECTION.  SELECT * FROM cdhdr INTO TABLE lt_cdhdr    WHERE objectclas = p_class AND objectid = p_objid    ORDER BY udate DESCENDING utime DESCENDING.  LOOP AT lt_cdhdr INTO ls_cdhdr.    WRITE: / ls_cdhdr-udate, ls_cdhdr-utime, ls_cdhdr-username, ls_cdhdr-tcode, ls_cdhdr-changenr.  ENDLOOP.

Real project scenario

During month-end, invoices for one company code failed. A developer debugged production and changed a variable to "test a fix"; the document posted with a wrong account and had to be reversed by finance, extending the close.
The post-mortem introduced a rule: evidence and QA reproduction first, firefighter access only for read-only debugging, and change documents plus SLG1 as standard evidence. The original issue was a missing account determination entry found from the application log.

Common mistakes

Debugging production as the first step.
Changing values or jumping statements in production.
Holding locks during long debug sessions.
No documentation or approval.
Closing incidents without prevention.

Best practices

Evidence and read-only tools first.
Reproduce in QA.
Approved, read-only production debugging only.
Document every session.
Root cause and prevention for every incident.

Interview angle

Questions: "How do you handle a production issue?", "Would you debug in production?", "What are the risks?"
Strong answer: evidence first (message, user, logs ST22/SM37/SLG1/SM13/SM21, STAD, data and change documents, recent transports), reproduce in QA; production debugging only when justified, approved (firefighter), read-only, no commit paths, short; risks: locks, inconsistent data, commits; close with root cause, fix, data correction, prevention.

Practice this lesson

Quick check

1. What should be the first step for a production-only billing failure?

2. Which action is most dangerous when debugging in production?

3. What should you avoid during production debugging?

Interview questions

1. A production LUW committed partial data — how do you investigate and recover?

Answer it in your own words first, then compare.

2. You need to debug a live production issue affecting real customer data, but you must not risk changing any data during the investigation. What precautions and techniques would you use?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.