Lesson 5 of 6
Localizing failures
8 min
Listen to this lesson
When a long chain fails, the instinct is to rerun it or to open a defect against the team that owns the last step. Both waste time. The symptom usually appears at the end of the chain; the cause is often several boundaries earlier. Localizing a failure means narrowing it down to one boundary and one component before anyone starts fixing.
- Last good checkpointFind the latest step whose checkpoint you can prove. The fault lies after it.
- Document flowFrom that document, look forward: which successor is missing, blocked or wrong?
- Interface monitorsIf the next step depends on a message, check its status in WE02 / BD87, AIF, SAP Integration Suite or Cloud ALM.
- LogsOnly then read application logs, job logs and short dumps for the exact error.
- Hand overRaise the defect against the boundary with the evidence attached.
Start from the last good checkpoint. If the checkpoints from lesson 3 were recorded, this step takes a minute: read the shared data sheet and find the last row marked passed. If they were not, you rebuild it by working backwards from the symptom. Either way, the question is the same: what is the latest point at which I can prove the process was correct? Before going further, rule out the cheap causes that affect everything: was a transport imported since the last good step, is a batch job that the next step depends on scheduled and finished, is the external test endpoint up? Asking those three questions at the stand-up saves many hours of individual analysis, because one environment problem often shows up as five unrelated-looking defects.
- Was a transport imported since the last good step?Yes → suspect the change first · No → next
- Is the batch job the next step depends on scheduled and finished?No → run or fix the job, then recheck · Yes → next
- Is the external test endpoint up?No → environment issue affecting many scenarios · Yes → localize this scenario on its own
Read the document flow
Document flow tells you which successor documents exist and what status they have. In sales, display the order (for example with VA03) and open its document flow to see deliveries, goods issue, billing and accounting documents. In purchasing, the purchase order history on the PO item (for example in ME23N) lists goods receipts and invoice receipts. From a supplier invoice, MIR4 shows follow-on documents. Fiori apps for these objects offer equivalent related-document or process-flow views; names vary by release, so check your launchpad.
You are looking for one of three patterns. A missing successor (the order has a delivery, but no billing document) points at the step that should have created it. A blocked successor (the billing document exists, but its accounting status shows it was not posted) points at a check or block. A wrong successor (the invoice exists, but for the wrong quantity or amount) points at copied data, so walk back to find where the value first went wrong.
| Pattern | What you see | Points to |
|---|---|---|
| Missing successor | The order has a delivery but no billing document | The step that should have created it |
| Blocked successor | The billing document exists but was not posted to accounting | A check or block on that document |
| Wrong successor | The invoice exists with the wrong quantity or amount | Copied data; walk back to where the value first went wrong |
Then the interface monitors
| Symptom | Look here first |
|---|---|
| Inbound document never created in SAP S/4HANA | WE02 / WE05 for the inbound IDoc and its status; BD87 to see errors grouped by status |
| Interface uses AIF | /AIF/ERR for the interface: message status and log messages |
| Message never reached SAP S/4HANA | SAP Integration Suite Monitor for the integration flow: failed or retrying messages |
| Unsure which component dropped it | SAP Cloud ALM Integration & Exception Monitoring: search across components |
| Outbound never left SAP S/4HANA | Output status on the source document, then the outbound IDoc |
Match the symptom to the monitor before reading logs.
Logs last
Logs answer "what exactly went wrong" once you know where to look. The application log (SLG1), job logs for the batch job that should have processed the step, and short dumps (ST22) are typical sources. Reading logs first, without a boundary in mind, means reading thousands of unrelated entries. Filter by the user, the time window and the object you identified in the earlier steps, then copy the exact message text and number into the defect. If the error is in a custom enhancement, the developer will need the document number to reproduce it; if it is in a mapping, the integration team will need the message ID. Resist the temptation to fix while you localize. A tester who changes master data to get past an error destroys the evidence, and the same defect returns in the next cycle. Localize, record, hand over, and let the owning team decide the fix.
What would you do?
Dan, the finance process owner, reports that in P2P-02 the supplier invoice from Lakeside Components "disappeared." The goods receipt is posted and recorded on the data sheet. What should the tester do first?
- Localize to one boundary and one component before anyone fixes anything.
- Order: last good checkpoint, document flow, interface monitors, then logs.
- Document flow shows missing, blocked or wrong successors; each pattern points somewhere different.
- Raise the defect against the boundary, with document numbers, statuses and log extracts attached.
Check your understanding · not graded
Lesson check
1. A sales order has a delivery and goods issue, but no billing document. What pattern is this?
2. Where do you see goods receipts and invoice receipts for a purchase order item?
3. Why are logs the last step in the top-down approach?
4. An outbound IDoc shows it passed to the port, but the customer received nothing. Where should you look next?