Error handling

This help topic looks at best practice for USoft error handling in an event processing context. See also:

•Best practice for USoft modelling in an event processing context.

•Best practice for USoft rules in an event processing context.

•Best practice for USoft logging in an event processing context.

In a system that processes events without user interaction, the system must be designed to be fault-tolerant. The level of fault tolerance differs per system. Error handling becomes part of the system design, since the potential impact on the system of each type of failure must be assessed design-time, and an appropriate failure action must be developed. In other words, business rules must define what is the desired conduct on failure.

Options for dealing with failure

You have several options for dealing with failure.

You can stop processing. Implement this as a restrictive constraint. The error message is visible only in the Rules Service log file.

You can stop processing with an error flag. You stop processing but in addition, an error flag in the model allows you to trace back to the initial event. The implementation is based on restrictive constraints. The processing of an event may start by calling a job with the Commit Type = Task and Abort Error = "Abort Task on Error" settings. Use the StartCatchingErrors and StopCatchingErrors methods of the Rules Service component to catch and save errors. If processing is implemented in a single job task, the processing task stops on error, and the error can be saved in a field. See example: Job that processes queued input events.

You can stop processing and retry later. The implementation is similar to the previous option. You stop processing and in addition, an error flag in the model allows you to trace back to the initial event. A retry mechanism will make sure that the processing of the event will happen later. It is usual to specify a retry count, that is the number of times the event will be re-offered for processing. This kind of error handling is used in the communication with external services as a solution to temporary non-availability of external systems. See also Queue services run-time properties.

You can continue processing and leave an error trace in the model. Implement this as a corrective constraint. On failure, set a status field or write a record to a log table.

Error types

Errors are of different types in different settings.

Business logic errors occur when the conditions laid down in business rules are checked. This type of error is best implemented by stopping processing without retry. One option is to set an error flag on the record that caused the failure and add an error description text.

External components availability errors occur when external systems are temporarily not available. A typical way of handling these errors is to stop processing and retry later.

Considerations

Consider the following when you are creating an event processing system:

•Use asynchronous processing patterns. Synchronous processing patterns propagate the failure. In the case of asynchronous communication, the retry mechanism of a queue service may be configured for dealing with failures.

•Implement a recovery-after-failure strategy. For example, on your production environment, set "Restart the service on failure" for Windows services that implement USoft Rules Services and USoft Service Framework servers.

•Create views in the default client/server application for the benefit of the administrator of the system. This way, it is easy to identify erroneous situations, for example, to get an overview of processed and unprocessed events.

•Move or delete transactional data from current transactional tables after a while. In event processing systems, transactional data quickly turns into history data. Do not keep data in transaction tables if it is no longer needed. If it is history data, archive it away from the transaction table. This strategy helps improve application performance.

•Design a log system that will log the events, errors, and violated business logic.

•Use an external tool for monitoring, for example to check for errors or warnings in Service Framework and Rule Service log files in real-time, or in near-real time.

•Monitor resources for your system, eg., memory and CPU, as a standard procedure.