iBOLT Servers have their own error handling mechanism. During project development, you can specify error types and appropriate actions for each flow component in the iBOLT Studio.
The iBOLT Server Flow Manager checks for errors after each step (flow component or service) is executed. If the flow component produces an error message, the component will be exited. The only exceptions are the Data Mapper databases and SAP Business One components, which have an Error Behavior property.
In addition to the integral iBOLT Error Handler, you can create your own Error Handler component to meet your organization’s specific needs. When an iBOLT Server is running, the Server first checks in the user-defined Error Handler and then in the integral Error Handler. The Server performs the defined error policy required by the Error Handlers. The Server continues executing the flows unless the defined error policy is to abort or restart the flow.
See the following topics for further information on error handling:
When an error occurs, iBOLT carries out various actions according to the error policy defined. The actions are defined on the flow level. You define the behavior for an error based on the error number returned by iBOLT. The error policy is defined in the Flow Errors Repository. The policy is implemented for a specific error number or range of error numbers.
The following actions can be executed when an error occurs:
Abort
Ignore
Restart Flow
Jump
Retry
For more information about these actions, click here.
You can handle errors by calling a custom defined error flow. An error flow is used to handle an error according to the project's logic. It is called any time that an error occurs in a flow that has an error flow configured in the Flow Properties External tab. The iBOLT Server automatically sends the error code and error description to the error flow using the standard error system variables. By default, these variables are cleared when starting the Error Flow execution.
However, they can be updated at the end of the error flow to initiate the Flow Error policy. The C.sys.ErrorCode variable can be updated using the Flow Data and the Data Mapper. Updating the C.sys.ErrorCode and C.sys.LastErrorComponentType variable in this way causes an error condition, and the defined flow error behavior will be executed. If the value of the C.sys.ErrorCode and C.sys.LastErorComponentType variable is not zero, the server behaves as if there is an error and the error flow is executed after the step. If either of these variables has a value of zero, there is no error behavior.
Note: |
In previous versions, the error code and error description were sent in the UserCode, UserBlob and UserString. Starting with iBOLT V3 SP1, these variables are no longer updated automatically. |
When an error occurs in a Trigger, the error flow that was defined in the flow properties is called.
The sys.InvokingComponentName variable provides the Trigger name, and the sys.InvokingFlowName provides the name of the flow that should have been launched by the Trigger.
Error Handling Execution Order
For all components except SAPB1 and the Data Mapper:
Any error at the step level triggers the exit behavior.
The Error Flow, if it exists, is invoked for each method that causes an error. It is called at the end of the step.
The Flow Error Behavior is checked. It is called at the end of a step.
Flow variables are cleared before the flow step is executed. However, before this clearing occurs, the value still exists, and the user is able to add a condition to the C.sys.ErrorXXX variables. It is important to be aware that conditions are checked before the step begins.
You can set the policy for handling execution errors on remote servers. By default, iBOLT attempts to contact the remote server three times at three second intervals. You can change this by editing the ParallelExecutionFailure = flag in the IFS.ini file.
To edit this flag:
Open the IFS.ini file.
Find the [MAGIC_IBOLT] section.
Find ParallelExecutionFailure =
Change the first number to indicate the maximum Number of retries you want iBOLT to make. Enter -1 to retry for no limits on retries.
Change the second number to indicate the retry interval.
The iBOLT server uses five types of call remotes:
Invoke async flow
Start an async step
Remote services
Routing
Recovery
The ParallelExecutionFailure flag only applies to the Invoke async flow and the Start an async step call remotes.
When the maximum number of retries is reached, the server will do the following:
For Invoke async flow, the flow will not be invoked and an error message is sent to the iBOLT Monitor and the ifs.log.
For Start an async step, the flow is recovered according to the recovery policy. This includes Call Flow steps.
Related Topics