Directives for Error Handling

Review the below table for a list of the common directives for error handling.

Rollback		This directive immediately stops the scenario from executing. A rollback phase will then be started on all modules and shall attempt to revert all modules to their initial state. The subsequent modules will not be processed.  Barring a few error types, the scenario will be deactivated based on the number of consecutive errors specified under Scenario settings. The scenario execution status will then be marked as an error. Rollback is the default behaviour if no error handler route is attached to the module, and if the Allow Storing Incomplete Executions setting under Scenario settings is not checked.
Commit		This directive immediately stops the scenario from executing. A commit phase will then be started on all modules. The subsequent modules will not be processed, and all unprocessed bundles will be ignored.  The scenario execution status will then be marked as success.
Resume		This directive specifies a substitute output and supplies it to the module that encounters an error. The subsequent modules will be processed. The scenario execution status will then be marked as success.
Ignore		This directive ignores the error. The subsequent modules will not be processed. If there are unprocessed bundles, the scenario execution will continue as normal. The scenario execution status will then be marked as success.
Break		This directive stores the state of the scenario execution in the queue of incomplete executions, where the error can be resolved manually. Some exceptions to this manual resolution are noted; more instructional articles will soon be available. The subsequent modules will not be processed. If there are unprocessed bundles, the scenario execution will continue as normal. Please note that the scenario execution status will be marked as a warning, when the "Automatically complete execution" option is disabled. Refer to the Break section below for more information.
Retry		Sometimes, users may wish to re-execute a failing module when there is a chance that the reason for the failure may self-resolve over time. Alaya Connector does not have a directive for this workflow, but this article offers several workaround options which can mimic this functionality.

Sometimes, users may want to forcibly stop a scenario from execution after the rollback or commit phase has occurred, or they wish to stop processing a route and store the route in the incomplete executions queue instead. To "throw" an error is therefore a workaround where users can then use these error handling directives conditionally. Refer to this article for more information. 

Break

When an error is handled by the Break directive, a record is created in the Incomplete Executions folder. The folder tores the state of the scenario execution along with data from prior modules. For each bundle of data that causes the error, a separate record is created. The record references the module, offer more information on where the error came from, and shows what the module received as data for input. Users may wish to resolve the error manually by updating the scenario and running it once. 

Alternatively, users can enable the option called "Automatically complete execution" under the Break directive. This allows users to automatically process an incomplete execution by re-executing the scenario after a specified number of minutes. 

When Break is enabled, the incomplete execution is retrieved when an error takes place. This is based on the time specified in the field "Interval between attempts", and will be executed using the original input data. This will repeat until the execution of the module completes without an error, or until the numeric value specified in "Number of attempts" is reached.

Currently, there are some exceptions to this directive. We will soon be providing more instructional articles to this directive.