Lesson 4 of 6
Exception handling
10 min
Listen to this lesson
Every integration flow will fail eventually: a partner host is down, a certificate expires, a mapping meets data it has never seen. Exception handling decides what the failure looks like. A good design makes failures safe (no half-sent orders), visible (the right person knows), understandable (the error says what is wrong in business terms) and recoverable (the same message can be processed again after the fix).
The exception subprocess
Cloud Integration's main tool is the exception subprocess. You drop it from the palette into the integration process and do not connect it to the other steps; it runs when an error occurs in the process. Inside it you model what to do: capture the error text (for example from ${exception.message} in a Content Modifier), write a log entry, notify someone, and end the subprocess in a deliberate way.
- Error raisedThe SFTP receiver cannot reach Lakeside's host for order 4500002210.
- Exception subprocess startsThe main process stops; control does not return to the remaining main steps.
- Capture contextContent Modifier stores the error text, PO number and receiver in headers.
- NotifyA shared error-handling flow, called through ProcessDirect, raises the alert.
- End deliberatelyAn error end event keeps the message status Failed, so monitoring and alert rules see it.
Two behaviors surprise new developers. First, once control passes to the exception subprocess it does not return to the main flow, so any step you need on both paths belongs in a local integration process that both can call. Second, how the subprocess ends changes the message status the monitor shows. Ending with a normal end event can make a failed business message look completed. If the business message did not reach the partner, end so that it is reported as failed.
Retries and decoupling with JMS
For asynchronous flows, a common pattern is to split receipt from delivery with a JMS queue in the tenant. The first flow accepts the message from S/4HANA and writes it to a queue, so the sender gets a quick acknowledgment. A second flow reads from the queue and delivers to the partner. If delivery fails, the JMS sender adapter retries on its configured interval, optionally with exponential backoff, up to a maximum. After that, the message must land somewhere a person will see it.
- 09:00Order queuedReceipt flow writes PO 4500002210 to the JMS queue; S/4HANA gets its acknowledgment.
- 09:00First attempt failsLakeside's host is down; message status shows Retry.
- 09:01 to 09:30Retries with backoffIntervals grow; each attempt is logged.
- 09:45Host backNext retry succeeds; status Completed, one file at Lakeside.
- If neverRetries exhaustedMessage stops in a state the operations team monitors and an alert is raised.
Duplicates and idempotency
Retries and reprocessing can send the same message twice. Design for it. Cloud Integration offers an Idempotent Process Call step that remembers message IDs it has already processed and can skip duplicates. Use a business key, such as the IDoc number or the PO number plus a change counter, so a resend of the same order is recognized. Agree with the partner what they do with a duplicate, too.
- Transient errors (host down, timeout): retry automatically with backoff; alert only when retries are exhausted.
- Data errors (unknown unit, missing partner): do not retry; fail visibly and route to the business owner to correct the source.
- Configuration errors (expired certificate, wrong credential alias): fail visibly and route to the integration team.
- Unknown errors: fail visibly with the full error text and the business key.
What would you do?
During Contoso's integration test, Priya notices that the Lakeside flow never shows a failed message, even on the day Lakeside's test host was offline. The exception subprocess sends an email and ends with a normal end event. What should she raise?
- Good error handling is safe, visible, understandable and recoverable.
- The exception subprocess runs on error and does not return to the main flow.
- End error paths so the message shows as failed; never turn a failure green.
- Retry transient errors with backoff, fail data errors visibly, and guard against duplicates.
Check your understanding · not graded
Lesson check
1. How is an exception subprocess connected to the main integration process?
2. Why might a failed order show as Completed in the monitor?
3. Which kind of error should usually be retried automatically?
4. What does the Idempotent Process Call step help prevent?