Lesson 3 of 5
Reprocessing
9 min
Listen to this lesson
Reprocessing means processing a failed message again, usually after fixing what made it fail. Done well, it recovers the business transaction with no resend from the partner and a clean audit trail. Done badly, it fails again for the same reason, or worse, creates a duplicate order, a double payment or a second shipment. Every critical interface needs a written, tested reprocessing procedure.
Fix first, then reprocess
- DiagnoseRead the error, classify it as transient, data, configuration or code.
- Check for copiesWas the message already delivered or re-sent by someone? Check the receiver and the monitors.
- Fix the causeCorrect the master data, renew the certificate, transport the mapping fix.
- Reprocess the originalRestart the same message, not a new copy, using the monitor's reprocess function.
- Verify the outcomeSuccess status plus the business result at the receiver; record it in the ticket.
The second step matters more than it looks. Under pressure, people resend: a buyer re-outputs the PO, the partner resends the file, someone restarts a queue. If two people fix the same failure in different ways, the receiver gets it twice. Before reprocessing, always check whether the business result already exists.
Where and how to reprocess
| Where it failed | How to reprocess | Watch out for |
|---|---|---|
| Inbound IDoc in status 51 | Fix the data, then reprocess the same IDoc in BD87 | Editing IDoc segments directly; restricted in production and audited |
| qRFC queue blocked | Fix the cause of the first failed entry, then restart the queue in SMQ1 or SMQ2 | Deleting the blocking entry loses that transaction |
| tRFC call failed | Execute the call again from SM58 once the target is reachable | Calls that already partly ran in the target |
| AIF message in error | Correct the value in the AIF monitor if permitted, then restart | Correction rights must match the role; changes are logged |
| Integration Suite flow with JMS retry | Let retries complete after the fix, or trigger reprocessing per the flow's design | Retries exhausted; messages need a defined restart path |
| Synchronous API call failed | The caller retries; nothing is stored in between | The caller must handle idempotency, or a retry may create a second document |
Reprocessing by failure point. Exact options depend on release and on how each flow is designed.
Idempotency protects you
A receiver that recognizes a duplicate turns a risky reprocess into a safe one. In Integration Suite, an Idempotent Process Call step can skip a message ID it has already processed. In S/4HANA, many inbound processes can check a reference such as the customer's purchase order number against existing orders. Where neither exists, the reprocessing procedure must include a manual duplicate check, and the interface is a candidate for a design fix.
- Has the root cause been fixed and verified?Yes → next question · No → do not reprocess; it will fail again
- Does the business result already exist at the receiver?Yes → do not reprocess; close the failed message with a note · No → next question
- Is the receiver idempotent for this message?Yes → reprocess the original message · No → reprocess with a second person checking for duplicates afterwards
- Does reprocessing need payload changes?Yes → follow the controlled correction procedure with approval and logging · No → reprocess and verify
What would you do?
On Monday morning, 37 inbound customer order IDocs from Great Lakes Fleet Services are in status 51 because a new ship-to address was not set up. Maria has created the ship-to. Ana asks whether she can simply ask the customer to resend all 37 orders. What is the right approach?
- Fix and verify the cause before reprocessing, or the message fails again.
- Check whether the business result already exists before reprocessing anything.
- Reprocess the original message where it failed; avoid resends and manual re-entry.
- Idempotent receivers make reprocessing safe; deletion needs owner approval.
Check your understanding · not graded
Lesson check
1. What should happen before reprocessing a failed message?
2. What is the risk of deleting the entry that blocks a qRFC queue?
3. Which property of a receiver makes reprocessing safe against duplicates?
4. A synchronous API call fails. Where does a retry come from?