BTP & Integrationintermediate

BTP CPI iFlows Part 3: Exception Handling and Error Subprocesses

Key takeaway

Handle failures deliberately: Exception Subprocess with Error Start and End events, reading error details (${exception. message}), returning meaningful responses to senders, escalation vs error end, alerts, and designing for synchronous vs asynchronous error behavior.

Explanation

📌 KEY POINTS
✅ An Exception Subprocess catches errors in its integration process.
✅ Access error details via ${exception.message} or the CamelExceptionCaught property.
✅ Synchronous flows should return a clear error response; asynchronous flows should hand errors to retry/alert logic.
✅ End events: End (message completes), Error End (marks failed), Escalation End (escalated status).
⚠️ Catching every error and ending with a normal End marks failed messages as Completed — errors become invisible.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 2 configured adapters. Now error handling.

━━━━━━━━━━━━━━━━━━━━
▶ 1. EXCEPTION SUBPROCESS

Error Start; steps; end event.

━━━━━━━━━━━━━━━━━━━━
▶ 2. ERROR DETAILS

exception.message; properties.

━━━━━━━━━━━━━━━━━━━━
▶ 3. SYNC RESPONSES

HTTP status + message body.

━━━━━━━━━━━━━━━━━━━━
▶ 4. ASYNC HANDLING

JMS retry, dead letter, alerts.

━━━━━━━━━━━━━━━━━━━━
▶ 5. MONITORING STATUS

Failed vs Escalated vs Completed.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Add an exception subprocess.
Build an error response with status and message.
Test with a failing receiver.

✅ CHECKPOINT: MPL shows Failed/Escalated and sender gets a meaningful error.

Code example

ABAP Code

===== EXCEPTION SUBPROCESS =====Error Start → Content Modifier:  header CamelHttpResponseCode = 502  body = {"error":"Receiver failed","detail":"${exception.message}","orderId":"${property.p_orderId}"}→ (optional) send alert → Error End ===== STATUS =====End → Completed | Error End → Failed | Escalation End → Escalated

Real project scenario

A team's exception subprocess ended with a normal End event; failed orders appeared Completed and weren't retried. Switching to Error End and alerting surfaced failures immediately.

Common mistakes

Swallowing errors.
Generic error texts.
No alerts.
Same handling for sync/async.
No business key in errors.

Best practices

Error End for failures.
Detailed messages.
Alerts.
Pattern-specific handling.
Business keys in errors.

Interview angle

Questions: "How do you handle exceptions in CPI?", "Error End vs End?", "How do you return errors to a sync sender?"
Strong answer: subprocess, details, sync/async behavior, end events, monitoring.

Practice this lesson

Quick check

1. Failed orders appear as Completed in monitoring. What is the likely design error?

2. How can you read the error message inside an exception subprocess?

3. What is the primary purpose of adding an Exception Subprocess to a CPI integration flow?

Interview questions

1. A production issue is reported in CPI iFlows. What would you check first, and how would you troubleshoot it systematically?

Answer it in your own words first, then compare.

2. Failures in iFlows go unnoticed or return unclear errors. How do you design exception handling?