Handling Scenario Execution Errors
Default error handling
When run-time scenario error occur, the error message is logged to the Errors topic. If you use self-managed type of installation, you can configure some aspects of the exception handling - read more here
Manual error handling
Not every failure has to end up in the error topic. An enricher, a processor and a Variable / Record variable node have an additional output edge - the error-recovery output, labelled on error - which leads to another branch of the scenario.
When such a node fails at runtime (e.g. the enricher call throws an exception, or the SpEL expression cannot be evaluated),
the record is routed down that branch instead of being passed to the exception handling described above. Nothing is sent
to the errors topic for such a failure and the scenario keeps processing the next records, as usual.
The record enters the recovery branch with the variables it had before the failing node - the output variable of that node is not set,
because it was never computed. On top of that, the #error variable describing the failure is available on the branch:
| Name | Type | Description |
|---|---|---|
#error.message | String | Message of the failure (the exception class name if it has no message) |
#error.nodeId | String | Id of the node which failed |
If the scenario defines its own variable named error, it is shadowed on the recovery branch by the one above.
The recovery branch is an ordinary branch of the scenario - you can filter it, enrich it, write the failed records
to a dedicated sink (e.g. to a separate Kafka topic together with #error.message), or end it with a Dead-End sink
to drop them silently.
This mechanism is engine-independent - it works the same way in the Streaming and Request-Response processing modes.
In the Designer, the error-recovery output is drawn as an additional output port of the node (not in the legacy graph
view, which the debug.newGraph user setting switches back to).
Limitations:
- a node can have at most one error-recovery output,
- only enrichers, processors and variable nodes can have one; failures of filters, choices, custom nodes (e.g. aggregations), sources and sinks are always passed to the exception handling described above,
- a node without the error-recovery output behaves exactly as before - its failures go to the exception handling,
- only the failure of the node the edge starts from is routed this way - a node placed on the recovery branch needs its own error-recovery output to have its failures caught.