Configuring bursts for error recovery
Errors that occur during burst processing might be recoverable, or they can cause only a burst to fail, or they can be severe enough to cause the entire map to fail. Your card and map settings control many of these failure points.
| If the following error occurs... | Card fails | Burst fails | Map fails |
|---|---|---|---|
| Any source connection fails | ✓ | ✓ | ✓ |
| The FAIL function causes a component rule to fail | ✓ | ✓ | ✓ |
| The type of an input is invalid | ✓ | If stop on first error is set, input validation fails, causing the
burst to fail. If stop on first error is not set, input validation continues until all inputs are validated. Input validation as a whole causes a burst failure if any input type is invalid. |
If the error limit is reached and a burst fails because one or more inputs are invalid, the map fails. |
| The FAIL function causes a transformation rule to fail | ✓ | ✓ | ✓ |
| If an output audit fails If output audit is used, it is recommended that Scope is set to burst or map. |
✓ | ✓ | |
| If fail is set for an input or output Warnings. | ✓ | ✓ | ✓ |
| Any target connection fails. | ✓ | ✓ | ✓ |
If an adapter is referenced as a function argument and no FAIL function is used, all operations rollback when a burst fails. When a burst is successful, any successful operations are committed.