Lesson 7 of 7
Testing error paths
16 min
Listen to this lesson
Error handling is the code that runs least and matters most. A happy-path test cycle never enters the exception subprocess, so a broken classification Router, a wrong AIF namespace or a parking queue nobody can read stays hidden until the first bad night in production. Error paths have to be forced, on purpose, in the test tenant, with expected results written down before the test runs.
Design one test per error class
| Test | How to force it in CMC_TEST | Expected result |
|---|---|---|
| Functional error | Send an order with the unmapped part GLF-ALT-24X | Parked with custom status Parked; error in AIF in CMQ with the PO number; no retry |
| Transient error, recovers | Point the IDoc receiver at an unreachable address via an externalized parameter, then restore it | Status Retry, SAPJMSRetries rising, no alert; Completed after restore; one sales order |
| Transient error, retries spent | Keep the receiver unreachable; lower the threshold through an externalized parameter for the test | Parked after the threshold; Cloud ALM alert to Theo |
| Permanent error | Deploy wrong credentials in the test tenant's security material | Failed fast, alert to the integration team |
| Duplicate | Send the same PO twice, then replay a parked order whose order already exists | Second call skipped by the Idempotent Process Call; CMQ duplicate check flags a repeat |
| Bad request to the receive flow | Post malformed JSON and a missing PO number | HTTP 400 with a clear message; nothing written to the queue |
Contoso's error-path test set for the Great Lakes order interface.
Externalize what you need to break. If the receiver address, the retry threshold and the AIF interface name are externalized parameters, Priya's testers can force each path by configuration in CMC_TEST without changing the flow, and the same design is forwarded unchanged to CMC_PROD. SAP's design-guideline flows use the same trick: a header such as error set to true makes the flow call a bad path on purpose.
Check more than the status
A test that only checks "message Failed" proves little. For each error-path test, check the message status and custom status, the queue entry (or its absence), the MPL content (business key present, no personal data in attachments), the AIF entry or Cloud ALM alert, and the business result in CMQ: exactly one sales order for the PO, or none. Record the message IDs and the PO number with the test result in SAP Cloud ALM, as sap-int-205 describes for interface evidence.
Use Trace in the test tenant to see which route the exception subprocess took. Remember that it expires after about 10 minutes and the content after about an hour, so read it right after the run.
Status-code checks against an HTTP endpoint
The receive flow is an HTTP endpoint, so many of its error paths are status-code checks: a valid order returns 202, a malformed one returns 400 from the flow's own validation, and a wrong path returns 404 before the flow is even reached. Testers can automate these with any tool that sends HTTP requests and checks status codes and JSON fields. Practice the technique on a public service first, then point the same checks at the Contoso endpoint in CMC_TEST.
| Request | Expected status | What it proves |
|---|---|---|
| Valid order JSON to the receive flow | 202 Accepted | Order persisted to the queue |
| Malformed JSON | 400 Bad Request | Validation rejects it before the queue |
| Wrong endpoint path | 404 Not Found | Routing and the address are as designed |
| Valid order, CMP down | 202 Accepted | The partner is shielded from receiver outages |
What would you do?
Two days before the final integration test sign-off, Priya reviews the evidence for the Great Lakes order interface. Every happy-path test passed. The only error-path evidence is a screenshot of one message in status Failed, taken when CMP happened to be down. What should she ask for?
- Force every error class on purpose in the test tenant; happy-path tests never enter the exception subprocess.
- Externalize what you need to break: receiver address, retry threshold, AIF interface name.
- Check status, custom status, queue, MPL content, AIF or Cloud ALM, and the business result.
- HTTP endpoints are tested with status-code checks; learn the real codes of the service, such as 204 for a missing entity.
Check your understanding · not graded
Lesson check
1. Why must error paths be tested deliberately rather than waiting for failures?
2. What makes it possible to force a receiver outage in CMC_TEST without changing the flow?
3. In the transient-recovery test, what business result proves the retry design works?
4. A TripPin request for a missing person returns 204. What is the lesson for error-path tests?