BTP & Integrationadvanced

BTP CPI iFlows Part 6: JMS Queues, Data Store and Asynchronous Retry Patterns

Key takeaway

Build reliable asynchronous integrations: decouple sender and processing with JMS queues, configure retries with exponential backoff and maximum attempts, handle dead letters, use data stores for temporary persistence and variables, and respect tenant JMS limits.

Explanation

📌 KEY POINTS
✅ JMS receiver in one iFlow + JMS sender in another decouples intake from processing.
✅ The JMS sender adapter retries failed processing with configurable intervals and exponential backoff.
✅ After max retries, route messages to an error/dead-letter handling path.
✅ Data stores persist messages or context temporarily; variables store small values across runs.
⚠️ JMS queues and storage are limited per tenant — unbounded queues or forgotten data store entries cause outages.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 5 covered patterns. Now reliability.

━━━━━━━━━━━━━━━━━━━━
▶ 1. DECOUPLING

Intake iFlow → JMS → processing iFlow.

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

Interval, exponential backoff, max retries.

━━━━━━━━━━━━━━━━━━━━
▶ 3. DEAD LETTERS

Escalation after max attempts; alerting.

━━━━━━━━━━━━━━━━━━━━
▶ 4. DATA STORE & VARIABLES

Write/Get/Delete; expiry.

━━━━━━━━━━━━━━━━━━━━
▶ 5. CAPACITY

Queue limits; monitoring.

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

Split a sync flow into intake + JMS + processing.
Configure retry with backoff and max retries.
Route final failures to an alert/dead-letter path.

✅ CHECKPOINT: temporary receiver outage recovers automatically without data loss.

Code example

ABAP Code

===== DECOUPLED DESIGN =====iFlow A (intake): HTTPS sender → validate → JMS receiver (queue ORDERS_IN) → 202 AcceptediFlow B (processing): JMS sender (queue ORDERS_IN, retry interval 1 min, exponential backoff, max interval 60 min) → process → receiver  if ${header.SAPJMSRetries} > 5 → move to ORDERS_DLQ / alert ===== DATA STORE =====Write (store "PendingOrders", entry ID ${property.p_orderId}, expiration 30 days) | Get | Delete after success

Real project scenario

A supplier API went down for two hours; synchronous iFlows failed and orders were lost. Decoupling with JMS and retries with backoff let all orders flow once the supplier recovered.

Common mistakes

Synchronous where async fits.
Unlimited retries.
No dead-letter path.
Data store without expiry.
Ignoring queue limits.

Best practices

JMS decoupling.
Backoff and max retries.
Dead-letter handling.
Expiry and cleanup.
Monitor queues.

Interview angle

Questions: "Why use JMS in CPI?", "How do retries work?", "What is a data store for?"
Strong answer: decoupling, retries, dead letters, data store, capacity.

Practice this lesson

Quick check

1. A CPI iFlow needs to temporarily persist message payloads across multiple, independently triggered message exchanges so that a later iFlow run can retrieve data written by an earlier run. Which integration flow element is designed for this purpose?

2. What happens to a JMS message after the maximum number of retries is exceeded in a good design?

3. Why would an integration developer introduce a JMS adapter pair (JMS sender/receiver queue) within a single CPI iFlow rather than connecting steps directly?

Interview questions

1. A supplier API is unreliable and synchronous iFlows lose orders during outages. How do you make processing reliable?

Answer it in your own words first, then compare.

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