SAP Exception Sub-Processes

An Exception Sub-Process is a dedicated area inside an iFlow that handles errors. It runs automatically when an unhandled exception occurs in the main integration process. Without it, errors end processing silently. With it, every failure triggers a controlled response — logging, alerting, and payload preservation.

Think of an Exception Sub-Process like the emergency procedures on an airplane. The pilots follow normal procedure during a regular flight. But if something goes wrong, a completely separate set of emergency procedures activates. The crew does not improvise — they follow the documented emergency steps. Your Exception Sub-Process is that documented emergency plan for your iFlow.

Where Exception Sub-Processes Live in an iFlow

The iFlow canvas has two areas: the main Integration Process pool at the top, and any additional sub-process pools below it. You add an Exception Sub-Process by dragging it from the palette onto the canvas below the main process.

┌─────────────────────────────────────────────────────────────┐
│  MAIN INTEGRATION PROCESS                                   │
│  [Start] → [Step A] → [Step B] → [Error!] → [End Event]     │
│                                      │                      │
└──────────────────────────────────────│──────────────────────┘
                                       │ Exception triggers
┌──────────────────────────────────────▼──────────────────────┐
│  EXCEPTION SUB-PROCESS                                      │
│  [Error Start] → [Capture] → [Alert] → [Store] → [Error End]│
└─────────────────────────────────────────────────────────────┘

The Exception Sub-Process Lifecycle

Step 1: Exception Thrown in Main Process

Any unhandled error in the main process — a failed HTTP call, a mapping exception, a script error — triggers the exception mechanism. Processing in the main process stops at the point of failure.

Step 2: Exception Sub-Process Starts

CPI transfers control to the Exception Sub-Process. The error details are available as properties accessible within the sub-process scope:

${exception.message} – The human-readable error message
${exception.cause} – The root cause of the exception
${exception.stacktrace} – The full technical stack trace

Step 3: Error Handling Logic Executes

Whatever steps you put inside the Exception Sub-Process run now. Common actions include capturing error details, saving the failed payload, and sending notifications.

Step 4: Sub-Process Ends

The Exception Sub-Process ends with an Error End Event. This marks the overall MPL status as FAILED, making it visible in the monitor with the correct status.

Building a Standard Exception Sub-Process

Every production iFlow should include at least this basic Exception Sub-Process structure:

Step 1: Content Modifier — Capture Error Context

Exchange Properties:
  ErrorMessage  = ${exception.message}
  ErrorTime     = ${date:now:yyyy-MM-dd HH:mm:ss}
  FailedIFlow   = YourIFlowName
  BusinessContext = ${property.SalesOrderID}  (or relevant ID)

Step 2: Content Modifier — Build Alert Body

Message Body (Expression):
Integration Alert - Processing Failure

iFlow: ${property.FailedIFlow}
Time: ${property.ErrorTime}
Order: ${property.BusinessContext}
Error: ${property.ErrorMessage}

Action required: Review message in CPI Monitor.

Step 3: Mail Adapter — Send Alert

Receiver Channel:
  Adapter Type: Mail
  To: integration-ops@yourcompany.com
  Subject: [CPI ALERT] Integration failure in ${property.FailedIFlow}
  Credential: SMTP_CREDENTIALS

Step 4 (Optional): Data Store Write — Preserve Payload

Data Store Name: FAILED_MESSAGES
Entry ID: ${property.ErrorTime}_${property.BusinessContext}
Retention Threshold: 30 days
Body: The original failed message payload

Step 5: Error End Event

Drag an Error End Event from the palette and connect it as the last step. This sets the MPL status to FAILED.

Multiple Exception Sub-Processes

A single iFlow can contain multiple Exception Sub-Processes, each attached to a different scope. By default, the main Exception Sub-Process handles errors from the entire Integration Process. But you can add local Exception Sub-Processes inside specific scopes:

Main Integration Process:
  [Step A] → [Scope 1: Try calling Salesforce]
                  ↓ Error
             [Local Exception: write Salesforce error to queue]
             [Continue to Step B with fallback data]
  [Step B] → [Scope 2: Try posting to SAP]
                  ↓ Error
             [Local Exception: send critical alert, stop processing]

Main Exception Sub-Process:
  Catches any errors not caught by local scopes

Using local exception handling allows partial recovery. If calling Salesforce fails, the iFlow falls back to cached data and continues. If posting to SAP fails, the entire transaction is flagged as critical.

Using the Error Boundary Event

An alternative to the Exception Sub-Process is the Error Boundary Event — a catch marker attached directly to a specific step. When that step throws an error, the boundary event activates and routes the flow to an error handling path without stopping the main process entirely.

[Main flow continues]
[Call External API] ──── Error Boundary Event ──→ [Error Path: use fallback]
       ↓ success
[Continue with API result]

Use Error Boundary Events for expected, recoverable errors on specific steps. Use Exception Sub-Processes for unexpected, unrecoverable failures at the iFlow level.

Testing Your Exception Sub-Process

Never assume your exception handling works without testing it. Deliberately trigger failures during development to verify the Exception Sub-Process activates correctly:

Point the receiver adapter to an invalid URL to trigger a connection error
Send a message with a missing required field to trigger a mapping error
Throw a manual exception in a Groovy script using throw new Exception("Test error")

After each test, verify in the monitor that the MPL shows FAILED status, confirm the alert email arrived, and check that the Data Store contains the preserved payload. Only when all three checks pass is your exception handling truly complete.

Exception Sub-Process Anti-Patterns

Avoid these common mistakes:

Empty Exception Sub-Process – Adding the sub-process but leaving it empty provides no value. Always include at minimum an alert step.
Swallowing errors – Ending the Exception Sub-Process with a Message End Event (success) instead of an Error End Event hides failures from monitoring. Always use Error End Event.
Vague alerts – Sending "An error occurred" with no context forces the operations team to dig through logs. Include the iFlow name, the business document ID, the error message, and the timestamp in every alert.
No payload preservation – Losing the original failed message means you cannot reprocess it. Always write the payload to the Data Store.

Previous lesson

Back to course

Next lesson