Error Handling for Micro-Integration Flows
Error handling protects against data loss when a Micro-Integration successfully receives a message from the source but the message fails during processing or publishing. Error handling is optional and configured per Flow. Retry and Dead Message Queue (DMQ) are independent features that can be enabled in any combination (both are disabled by default):
-
Retry—When retry is enabled, the Micro-Integration retries a failed publish using exponential backoff. Each successive retry waits longer than the previous one, up to the configured maximum backoff interval.
-
The
This feature is intended for sources that lack built-in error handling, such as CDC and polling-based sources. If your source system has its own error handling mechanism, we recommend using that instead.
How Failed Messages Are Resolved
The Micro-Integration distinguishes between two categories of errors:
- Processing errors
-
Errors that occur during message transformation, such as validation failures, type mismatches, or missing required fields. These errors are considered unrecoverable because retrying the same message would produce the same result.
If a processing error occurs, the Micro-Integration forwards the message directly to the
- Publishing errors
-
Errors that occur when the Micro-Integration is publishing the message to the target, such as network issues, rate limiting, or a temporarily unavailable target system. These errors may be transient.
If a publishing error occurs and retry is enabled, the Micro-Integration attempts to re-publish the message. When all retry attempts are exhausted (or if retry is not enabled), the Micro-Integration forwards the message to the
If your source system is an event broker service, a queue-based system, or another system with built-in error handling, we recommend that you choose between using the source system's error handling or the Flow-level error handling—avoid enabling both at the same time.
Configuring Error Handling
You configure error handling in the Error Handling step when you create or edit a Flow. For more information, see Creating Micro-Integrations in Solace Cloud.
Retry Settings
The following table describes the retry settings.
| Field | Description |
|---|---|
| Enable Retry | If selected, retry is enabled for this Flow. When enabled, the retry settings below become available. The default is not selected (disabled). |
| Max Attempts | The maximum number of retry attempts to make before treating the message as failed. The minimum value is 1. The default is 5. |
| Initial Backoff Interval | The initial delay in milliseconds before the first retry attempt. Subsequent retries use this value as the starting point for the exponential backoff calculation. The minimum value is 1. The default is 1000 ms. |
| Max Backoff Interval | The maximum delay in milliseconds between retry attempts. Once the calculated backoff interval reaches this value, it stops increasing. Must be greater than the Initial Backoff Interval. The minimum value is 1. The default is 30000 ms. |
| Backoff Multiplier | The multiplier applied to the previous backoff interval to calculate the next retry delay. For example, a value of 2.0 doubles the delay with each attempt. The minimum value is 1.0. The default is 1.0. |
Dead Message Queue Settings
The following table describes the DMQ settings.
| Field | Description |
|---|---|
| Enable Flow DMQ | If selected, the Dead Message Queue is enabled for this Flow. When enabled, the DMQ Destination field becomes available. The default is not selected (disabled). |
| DMQ Destination |
The name of the queue to use as the DMQ for this Flow. The queue must exist on the same event broker service and VPN as the Micro-Integration. The maximum length is 200 characters. |