Directives for error handling

The Directives are explained in detail below:

Rollback		ScenarioA specific connection between applications in which data can be transferred. Two types of scenarios: active/inactive. 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		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		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		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		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		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 IntegratorPart of the Boost.space system, where you can create your connections and automate your processes. currently does not offer the Retry directive, though several workarounds can be employed to mimic its functionality.

	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.

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 bundleA bundle is a chunk of data and the basic unit for use with modules. A bundle consists of items, similar to how a bag may contain separate, individual items. 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 ExecutionsSometimes Boost.space Integrator cannot successfully finalize a scenario execution due to an error. Boost.space Integrator stores incomplete executions in a folder named Incomplete Executions. Each stored incomplete execution can be resolved either manually or automatically. 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 executionSometimes Boost.space Integrator cannot successfully finalize a scenario execution due to an error. Boost.space Integrator stores incomplete executions in a folder named Incomplete Executions. Each stored incomplete execution can be resolved either manually or automatically. 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.