SAP Retry Mechanisms

Most integration failures are temporary. A receiver system restarts for a patch update. A network switch reboots. A database connection pool is momentarily exhausted. If your iFlow retries the same message a few minutes later, it succeeds. Without retries, these temporary conditions cause permanent data loss — the message is gone, the business transaction never completes, and someone must intervene manually.

Retries turn temporary problems into small delays. They are one of the most valuable reliability mechanisms in integration design.

Where Retries Happen in CPI

CPI supports retries at two levels:

Adapter-Level Retries

The receiver adapter retries the delivery attempt automatically without the message leaving CPI. Configure retry count and interval directly in the adapter settings. This is the simplest form of retry — the iFlow processes the message once, and only the delivery to the receiver retries.

JMS Queue Retries

Messages stored in a JMS (Java Message Service) queue retry automatically when processing fails. The message stays in the queue and is picked up again after a configured delay. JMS queues provide more sophisticated retry control including dead letter handling after max retries are exhausted.

Adapter Retry Configuration

In receiver adapters (HTTP, SOAP, OData), find the Processing tab and configure:

HTTP Adapter — Retry Settings:
  Maximum Retry Interval: 60 minutes
  (How long to keep retrying before giving up)

SOAP Adapter — Connection:
  Connect Timeout: 30000 ms
  Response Timeout: 60000 ms

JMS Adapter — Error Handling:
  Dead Letter Queue: DLQ_OrderProcessing
  Max Redeliveries: 5
  Redelivery Delay: 30000 ms (30 seconds)

Retry Patterns

Fixed Interval Retry

Wait the same amount of time between every retry attempt. Simple to reason about, but can create load spikes if many messages fail simultaneously and all retry at the same moment.

Attempt 1: 14:00:00 → FAIL
Attempt 2: 14:01:00 → FAIL  (wait 1 minute)
Attempt 3: 14:02:00 → FAIL  (wait 1 minute)
Attempt 4: 14:03:00 → SUCCESS

Exponential Backoff

Each retry waits longer than the previous one. This prevents hammering a struggling system and gives it increasing time to recover. The most common retry pattern for production integrations.

Attempt 1: 14:00:00 → FAIL
Attempt 2: 14:00:30 → FAIL  (wait 30 seconds)
Attempt 3: 14:02:00 → FAIL  (wait 90 seconds)
Attempt 4: 14:07:00 → FAIL  (wait 5 minutes)
Attempt 5: 14:22:00 → SUCCESS (wait 15 minutes)

Exponential Backoff with Jitter

Adds a random delay variation to exponential backoff. When thousands of messages fail at the same moment — for example, when a system comes back online after downtime — pure exponential backoff causes all of them to retry simultaneously, creating a thundering herd problem. Jitter staggers the retries so they spread out over time.

Without jitter: 1000 messages all retry at 14:05:00 → overwhelms system
With jitter:    1000 messages retry between 14:04:45 and 14:05:15 → managed load

Implementing Retries with JMS in CPI

The most reliable retry pattern in CPI uses JMS queues. The iFlow publishes the message to a JMS queue. A separate subscriber iFlow picks up messages from the queue and processes them. If processing fails, the JMS broker returns the message to the queue for retry.

SENDER iFlow:
[Receive message] → [Basic validation] → [Write to JMS Queue] → [Acknowledge to sender]

PROCESSOR iFlow:
[Read from JMS Queue] → [Transform] → [Send to SAP]
                              ↓ FAIL
                    [JMS Queue: return message for retry]
                    [Wait redelivery delay]
                    [Pick up and retry]
                              ↓ MAX RETRIES REACHED
                    [Move to Dead Letter Queue]
                    [Send alert]

This pattern decouples receiving from processing. The sender gets an immediate acknowledgment (the message was accepted into the queue). Processing happens asynchronously and retries independently without the sender waiting.

Dead Letter Queues

After a message exhausts all retry attempts, it moves to a Dead Letter Queue (DLQ). The DLQ is a special JMS queue that holds messages that could not be processed after maximum retries. Operations teams review the DLQ daily.

DLQ WORKFLOW:
[Message in DLQ]
      ↓
[Operations team investigates root cause]
      ↓
[Root cause fixed: receiver system patched, data corrected]
      ↓
[Reprocess message from DLQ]
  Option A: Move message back to processing queue manually
  Option B: Use a reprocessing iFlow that reads DLQ and resubmits

Retry for Different Failure Types

Apply retry only to errors that retrying can fix. Retrying a business error wastes time:

TECHNICAL ERRORS (RETRY HELPS):
  HTTP 503 Service Unavailable   → System temporarily down, retry
  HTTP 429 Too Many Requests     → Rate limited, retry after delay
  Network timeout                → Network blip, retry
  Connection refused             → Port temporarily closed, retry

BUSINESS ERRORS (RETRY DOES NOT HELP):
  HTTP 400 Bad Request           → Message data is wrong, fix source
  HTTP 404 Not Found             → Referenced object does not exist in SAP
  SAP BAPI return: "E" (Error)   → Business rule violated, fix data
  Mapping exception              → Mapping bug, fix and redeploy

Detect the error type in your Exception Sub-Process using the HTTP response code or error message content. Route technical errors to a retry queue. Route business errors directly to the DLQ with a detailed alert for manual intervention.

Retry Timeouts and Maximum Attempts

Define clear boundaries for retry behavior:

• Max retry attempts: How many times to try before giving up. Three to five attempts covers most temporary outages.
• Max retry duration: How long to keep retrying in total. Set this to match your business SLA. If an order must be in SAP within four hours of placement, set max retry duration to three hours — leaving one hour for manual intervention if retries are exhausted.
• Retry expiry action: What happens when retries are exhausted. Always move to DLQ and send an alert. Never silently discard.

Testing Retry Behavior

Test your retry configuration explicitly during development:

• Deploy the iFlow pointing at an invalid receiver URL. Confirm retries happen at the configured intervals. Confirm the DLQ receives the message after max retries.
• Deploy with the real receiver URL but the receiver system switched off. Confirm retries happen. Switch the receiver back on partway through. Confirm a subsequent retry succeeds and the message processes correctly.
• Send a message with bad data. Confirm the error routes to DLQ immediately without retrying.

Retry logic that has never been tested under failure conditions is retry logic that will surprise you in production. Test it deliberately before go-live.