BTP & Integrationadvanced

BTP Integration Suite Part 7: Monitoring, Alerting and Operations

Key takeaway

Operate integrations: message processing monitor and statuses, log levels, retries with JMS queues and exception subprocesses, idempotency, data stores, alerting (e. g. via SAP Cloud ALM or Alert Notification), and business-level success checks — not just technical success.

Explanation

📌 KEY POINTS
✅ Monitor message processing logs (Completed, Failed, Retry, Escalated) and keep log levels appropriate.
✅ Use JMS queues for reliable asynchronous processing and controlled retries.
✅ Exception subprocesses handle errors; idempotency prevents duplicate postings on retry.
✅ Alerts should reach the right team (e.g. via Cloud ALM / Alert Notification).
⚠️ "Technical success" (HTTP 200) can hide business failures (e.g. an error in the response body) — check business status.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 6 covered lifecycle. Now operations.

━━━━━━━━━━━━━━━━━━━━
▶ 1. MONITORING

MPL statuses, custom headers for search.

━━━━━━━━━━━━━━━━━━━━
▶ 2. RETRIES

JMS, retry intervals, max retries; dead letter handling.

━━━━━━━━━━━━━━━━━━━━
▶ 3. ERROR HANDLING

Exception subprocess; meaningful errors.

━━━━━━━━━━━━━━━━━━━━
▶ 4. IDEMPOTENCY

Idempotent process call; duplicate checks.

━━━━━━━━━━━━━━━━━━━━
▶ 5. ALERTING & RUNBOOKS

Routing alerts; operations playbooks.

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

Add JMS with retry to an async flow.
Add exception subprocess with alert.
Check business status in responses.

✅ CHECKPOINT: failures alert the owner; retries don't duplicate data.

Code example

ABAP Code

===== RELIABLE ASYNC PATTERN =====Sender → JMS queue (retry: interval 1 min, exponential, max 5) → iFlow → idempotent process call (key = orderId) → receiverException subprocess → set status → alert (Cloud ALM / Alert Notification) ===== BUSINESS CHECK =====Router: if response contains error node → raise exception (not "Completed") ===== SEARCH =====Content Modifier: SAP_ApplicationID = ${header.orderNumber}

Real project scenario

An iFlow showed technical success because the receiver returned HTTP 200 with an error message in the body. Orders silently failed for days. A business-status check raising exceptions and alerts made failures visible.

Common mistakes

Trusting HTTP 200.
Unlimited retries.
No idempotency.
No business keys in MPL.
Alerts to nobody.

Best practices

Business status checks.
Bounded retries.
Idempotent calls.
Custom headers.
Routed alerts.

Interview angle

Questions: "How do you monitor iFlows?", "How do you design retries?", "What is idempotency?"
Strong answer: MPL, JMS retries, exception handling, idempotency, alerting.

Practice this lesson

Quick check

1. An iFlow shows Completed but orders weren't created because the receiver returned an error in a 200 response. What should be added?

2. Why should automatic retries be designed carefully for receiver calls?

3. What is the best place to confirm whether a deployed iFlow processed a test message successfully?

Interview questions

1. Orders silently fail while iFlows show Completed, and retries create duplicates. How do you redesign operations?

Answer it in your own words first, then compare.

2. A production issue is reported in Integration Suite. What would you check first, and how would you troubleshoot it systematically?