SAP Error Handling Strategies

Every integration fails eventually. A receiver system goes offline for maintenance. A message arrives with a field value that does not match the expected format. A network timeout occurs during a long API call. The question is not whether errors will happen — it is whether your iFlow handles them gracefully or lets them cause data loss and business disruption.

A well-designed error handling strategy means that when something fails, the right people are notified, the failed message is preserved, and the system recovers automatically where possible. Poor error handling means silent failures, lost data, and frantic manual investigation at 2 AM.

Types of Errors in CPI

Technical Errors

Caused by infrastructure or connectivity problems. Examples: receiver system unreachable, authentication failure, network timeout, TLS certificate expired. These are typically temporary and resolve themselves — the receiver comes back online, the network recovers. Retry strategies work well for technical errors.

Business Errors

Caused by data problems. Examples: required field missing in the message, a value does not match an allowed list, a referenced object does not exist in SAP (unknown customer ID). These do not resolve with retries — the data must be corrected at the source before reprocessing. Retry strategies do not help with business errors.

Mapping Errors

Caused by logic problems in your iFlow or mapping. Examples: XPath expression does not match the actual XML structure, a Groovy script throws a NullPointerException, date format conversion fails. These require developer intervention — fix the mapping and redeploy.

Error Handling Approaches

Approach 1: Stop and Alert

The simplest strategy. When an error occurs, stop processing, log the error details, and send an alert notification to the operations team.

[Processing Step] → ERROR
        ↓
[Exception Sub-Process fires]
        ↓
[Content Modifier: capture error details]
        ↓
[Mail Adapter: send alert email]
        ↓
[End with Error status in MPL]

Use this for business errors where the message cannot be reprocessed without manual correction.

Approach 2: Retry

For technical errors, configure the receiver adapter to retry automatically. CPI adapter retry settings allow you to specify how many times to retry and how long to wait between attempts.

ADAPTER RETRY CONFIGURATION:
  Max Retry Interval: 60 minutes
  Max Retry Count: 3
  Exponential Backoff: enabled

RETRY TIMELINE:
  Attempt 1:  Fails immediately (receiver down)
  Wait 5 min
  Attempt 2:  Fails (still down)
  Wait 10 min
  Attempt 3:  Succeeds (receiver came back up)

Exponential backoff increases wait time between each retry. This prevents CPI from hammering a struggling receiver system with rapid repeated calls.

Approach 3: Dead Letter Queue

After all retries are exhausted, move the failed message to a Dead Letter Queue — a Data Store in CPI where failed messages are preserved for later manual review and reprocessing.

[All retries exhausted]
        ↓
[Write message body to Data Store entry]
  Key: ErrorID + Timestamp
  Body: Original failed message payload
        ↓
[Write error details to Data Store]
  Key: same ErrorID
  Body: Error message, iFlow name, step where failure occurred
        ↓
[Send alert with ErrorID]
        ↓
[Operations team reviews Data Store]
        ↓
[After fix: trigger reprocessing iFlow with stored payload]

Approach 4: Fallback Processing

When the primary receiver fails, route the message to a fallback system or process. For example, if the SAP OData endpoint is unavailable, write the message to a file on SFTP for batch processing when SAP is back online.

[Try: Send to SAP OData]
        ↓ fails
[Catch: Write to SFTP fallback folder]
        ↓
[Alert operations team]
        ↓
[Batch pickup iFlow runs when SAP recovers]

The Exception Sub-Process

CPI's built-in error handling mechanism is the Exception Sub-Process. It is a separate pool in your iFlow that activates automatically when an unhandled exception occurs in the main process.

MAIN PROCESS:
[Start] → [Step A] → [Step B] → ERROR IN STEP B → [End]
                                       ↓
                         ┌─────────────────────────┐
                         │  EXCEPTION SUB-PROCESS  │
                         │  [Error End Event fires]│
                         │  [Capture error message]│
                         │  [Send alert email]     │
                         │  [Write to Data Store]  │
                         └─────────────────────────┘

Without an Exception Sub-Process, a failure in the main process ends with no notification and no preserved payload. With it, every failure is caught, logged, and escalated automatically.

Capturing Error Information

Inside the Exception Sub-Process, use a Content Modifier to extract error details using CPI's built-in error properties:

Exchange Properties to extract in Exception Sub-Process:
  ${exception.message}     – The error message text
  ${exception.stacktrace}  – Full technical stack trace (for developers)
  ${header.SAP_Sender}     – Which system sent the failed message
  ${property.SalesOrderID} – Business context you stored earlier in iFlow
  ${date:now:yyyy-MM-dd HH:mm:ss} – When the error occurred

Include all relevant context in your alert notification. An alert saying "Integration failed" is useless. An alert saying "Sales order SO-12345 from Salesforce failed posting to SAP at 14:32 — error: Material M-9999 not found in SAP plant 1000" gives the operations team everything they need to fix the problem immediately.

Idempotency: Handling Duplicate Messages

When a retry mechanism retries a message that actually succeeded (perhaps the network failed only when returning the response), the receiving SAP system processes it twice. This creates duplicate orders, duplicate invoices, or duplicate payments — serious business problems.

Idempotency means designing your integration so that processing the same message twice produces the same result as processing it once. CPI supports this through the Idempotent Process Call step, which records message IDs it has already processed and skips duplicates automatically.

Message arrives with ID = "MSG-456"
      ↓
[Idempotent Process Call]
  Check: Has "MSG-456" been processed before?
  YES → Skip processing, mark as Discarded
  NO  → Process normally, record "MSG-456" as processed

Error Handling in Batch vs Real-Time Integrations

Batch integrations process thousands of records at once. When one record fails, you must decide: stop the entire batch, or skip the failed record and continue with the rest.

• Stop on first error – No partial processing. All records succeed or none do. Good when records are interdependent.
• Skip and continue – Process as many records as possible. Write failed records to a separate error queue. Good for independent records like bulk price updates.

Implement skip-and-continue in CPI using a Splitter to process each record separately. An exception in one Splitter branch does not stop the other branches.