Error Extension Points
Flow Error Extensions
Flow error extensions allow the customisation of what should happen if an unexpected error occurs during flow processing. They provide a hook into handling the thrown exception, and provide the developer with an option to implement a handling routine.
Error extensions are provided by implementing the 'FlowErrorExtensions' interface, and then supplying that to your domain via the extension provider. Please refer to the add extensions section for more details.
The functionality available on the error extensions interface is:
| MethodName | Description | Default Functionality |
|---|---|---|
shouldRaiseEventOnError |
Specifies whether the flow should raise a special 'Unexpected Error' event when an unexpected error occurs during processing and then use that event to transition to the special 'In Error' state. When a flow reaches the 'In Error' state, it can then be moved on by supplying the resume, abort or force complete functionality available on the model domain. |
Turned off, no events raised. |
handle |
Allows the implementation of any custom flow error handling that you wish to provide. A common use case for this functionality would be if you were integrating your flow with IPF’s Human Task Manager (HTM). For example, if an unexpected error occurs during processing, you can define a custom error handler to transition the flow to the error state and raise a HTM task. From here, the operator would have the ability to retry the transaction or to abort/force complete the transaction. More details on this implementation can be found here. |
No additional handling. |
The default error extensions are provided by the 'DefaultFlowErrorHandler' implementation.
Retries
By default, the error extensions will allow an infinite number of retries. This means that should an error occur and then the flow be resumed (for example through an HTM recovery action) and the failure remain unfixed, then the processing of the failure will reoccur and any appropriate handling replayed. However, it may be that in some circumstances you need to stop the processing from looping in this fashion. For this we can add the config item "errorRetries". This will specify the maximum number of retries that you wish to perform until the payment is aborted.
To set the retry limit, we simply add the maximum number of retries during build of the domain:
new ErrorHandlingDomain.Builder(actorSystem) .withConfigSettings(ConfigSettings.builder().errorRetries(3).build()) .build();
The above setting will ensure that if 3 failures occur, the error will be routed to the aborted state.
This setting can also be applied using the 'ipf.behaviour.config.error-retries' property.
Event Error Extensions
Event error extensions are invoked when an unexpected error occurs during the processing of an event. The main use case for this is to capture errors that occur during invocation of an aggregate mapping and particularly to prevent failure during recovery scenarios.
Similar to flow error extensions, event error extensions are provided by implementing the 'EventErrorExtensions' interface, and then supplying that to your domain via the extension provider. The default behaviour is to simply move the record to the "In Error" state and then passivate the flow (this prevents it from being infinitely retried by recovery). Optionally you are then able to implement the 'EventErrorExtensions' handle method to provide further functionality. One option here would be to use the HTM extensions to send these records to HTM for manual analysis.