Directives for error handling

The Directives are explained in detail below:

 

Rollback
directives_for_error_1.png
Scenario execution is stopped immediately and a rollback phase is started on all the modules in an attempt to revert them all to their initial state.

The subsequent modules are not processed.

Barring a few error types, the scenario is deactivated after the “number of consecutive errors” specified under Scenario settings.

The scenario execution status is marked as “error”.

Note: This is the default behavior if no error handler route is attached to the module and the “Allow Storing Incomplete Executions” setting under Scenario settings is not checked.

Commit
directives_for_error_2.png
Scenario execution is stopped immediately and a commit phase is started on all modules. The subsequent modules are not processed.

All unprocessed bundles are ignored.

The scenario execution status is marked as “success”.

Resume
directives_for_error_3.png
A substitute output is specified and supplied to the module that encounters an error.

The subsequent modules are processed.

The scenario execution status is marked as “success”.

Ignore
directives_for_error_4.png
The error is ignored and the subsequent modules are not processed.

If there are unprocessed bundles, the scenario execution continues normally.

The scenario execution status is marked as “success”.

Break
directives_for_error_5.png
The state of the scenario execution is stored in the queue of incomplete executions where the error can be resolved manually. There are, however, some exceptions that are mentioned here.

The subsequent modules are not processed.

If there are unprocessed bundles, the scenario execution continues normally.

The scenario execution status is marked as “warning” when the Automatically complete execution is disabled.

See the Break section below for further information.

Retry
directives_for_error_6.png
In some cases, it could be useful to re-execute a failing module for a couple of times when there is a chance that the reason for the failure might pass over time.

Boost.space Integrator currently does not offer the Retry directive, though several workarounds can be employed to mimic its functionality.

[Note] Note
Information: Currently, the error handling directives can not be used out of the scope of an error-handling route and Boost.space Integrator currently does not offer a Throw module that would enable you to easily conditionally generate (throw) errors, though a workaround can be employed to mimic its functionality.
directives_for_error_7.png

Break

When an error is handled by the Break directive, a record is created in the Incomplete Executions folder which stores the state of the scenario execution along with data from the prior modules. For each bundle of data that causes the error, a separate record is created.

The record references the module where the error originated and contains information regarding what data was received by the module as input. Read on about Incomplete Executions here.

Here, you may resolve the error manually by updating the scenario (if needed) and running it once

On the other hand, by enabling the Automatically complete execution option under the Break directive settings, it can be configured to automatically process an incomplete execution by re-executing the scenario after the specified number of minutes.

With this option enabled, when an error takes place, the incomplete execution is retrieved (after the time specified in the Interval between attempts field) and executed with the original input data. This will repeat until the execution of the module completes without an error or until the Number of attempts specified is reached.

However, there are some exceptions to executions being stored under Incomplete Executions , and with some error types, the auto-retry of a scenario execution is not possible. They are mentioned here, under Allow Storing Incomplete Executions.

Check out this article to learn about advanced error handling.