Lesson 4 of 5
Traces
11 min
Listen to this lesson
When dumps and logs do not explain a problem, traces record what a program actually did: which SQL it sent, which authorizations it checked, where it spent its time. Traces are precise but expensive, so the skill is choosing the right one, limiting it to the right user and time, and switching it off afterwards.
| Trace | Transaction | Records | Use for |
|---|---|---|---|
| Performance trace (SQL) | ST05 | SQL statements with duration and records; also buffer, enqueue, RFC and HTTP traces | Slow transactions; expensive or repeated database access |
| Authorization trace | STAUTHTRACE (and ST01) | Authorization checks with object, values and result | Missing authorizations; designing test roles |
| System trace | ST01 | Kernel-level activity: authorization checks, database, buffers, RFC, HTTP, locks | Broad technical analysis |
| ABAP runtime analysis | SAT | Time spent per ABAP statement, method and function | Slow programs where the time is in ABAP, not the database |
| Last failed check | SU53 | The user's most recent failed authorization check | Quick first look at an authorization error |
Tracing a slow transaction
- PrepareAgree the scenario, user and time; warm up once so first-time loading does not distort the trace
- ActivateIn ST05, switch on the SQL trace for the tester's user only
- ReproduceThe tester runs the slow step once, exactly as in the test case
- DeactivateSwitch the trace off immediately
- AnalyzeDisplay the trace; sort by duration; look for slow statements, many identical statements and large record counts
In the trace display, three patterns deserve attention. A few slow statements suggest missing selection criteria or an unsuitable access path. The same statement executed hundreds of times (a "SELECT in a loop") suggests the program should read data in one go. Statements returning huge record counts suggest the program reads far more than it needs. If the database time is small but the step is still slow, the time is in ABAP processing or waiting, and an ABAP runtime analysis with SAT is the next tool.
Tracing authorization problems
For a "you are not authorized" error, SU53 shows the user's last failed check and is often enough. For a whole process, use the authorization trace (STAUTHTRACE), which records every check with the object, field values and result. That is also how to design realistic test roles: trace a business user performing the process, then compare with what the role grants. Remember that a missing authorization can also hide as a missing tile or an empty list rather than an error.
When the failure is in a Fiori app
A Fiori app that shows "an error occurred" or simply an empty list rarely leaves a dump the user can see. Its requests are OData calls over HTTP, so the evidence sits in different places. The SAP Gateway error log, /IWFND/ERROR_LOG, records failed OData requests with the service, the HTTP status and the error text; /IWBEP/ERROR_LOG holds the back-end side of the same failure. In Contoso's embedded deployment both logs live in the same system. For authorization problems in Fiori, run STAUTHTRACE for the user while they repeat the step, because SU53 in a separate SAP GUI session does not reliably show the check the app's request failed on. The browser's developer tools (network tab) show which OData request failed and with which status, which is often the fastest first look for a tester.
| Symptom in the app | First place to look | What it usually means |
|---|---|---|
| Error dialog when saving | /IWFND/ERROR_LOG, then ST22 for a dump | Back-end logic or data error behind the OData call |
| Empty list, no error | STAUTHTRACE for the user | Missing authorization on the app's data, often an organizational value such as sales area |
| Tile missing from the launchpad | The user's business roles and catalogs | Launchpad content, not the back end |
| HTTP 403 or 404 on every call | Service activation and the ICF node (/IWFND/MAINT_SERVICE, SICF) | Service not activated or path blocked in this system |
First looks for Fiori failures. Transaction names apply to SAP S/4HANA with an embedded front-end server.
The other ST05 traces
The performance trace in ST05 can record more than SQL. The enqueue trace shows which locks a step requests and releases, useful when two processes keep blocking each other. The RFC trace shows calls to other systems and how long they took, which separates a slow partner from a slow local program. The buffer trace shows table buffer access, and an HTTP trace covers web requests. Switch on only the traces you need: a step that waits on a remote system is diagnosed with the RFC trace, not by reading pages of SQL.
What would you do?
Contoso's stock overview for plant 1910 Monterrey takes 90 seconds in CMQ after the Wave 2 test load. An ST05 trace shows the same SELECT on the material document table executed 2,300 times, once per material. What is the best conclusion?
- ST05 traces SQL (and buffer, enqueue, RFC, HTTP); SAT analyzes ABAP runtime.
- STAUTHTRACE records authorization checks; SU53 shows the last failed one.
- Trace one user, one reproduction, then switch off and save the result.
- Look for slow statements, repeated statements and huge record counts.
Check your understanding · not graded
Lesson check
1. Which transaction runs an SQL performance trace?
2. Database time in the trace is small but the step is still slow. What next?
3. Which tool records every authorization check during a whole process?
4. What is a "SELECT in a loop" signature in ST05?