Statelake needs to be monitored on a daily basis to ensure the successful operation of its processes.

Due to Statelake Service being a background application, it is quite easy to forget that it is there and doing work for you, and therefore when errors occur they often go unnoticed causing even greater problems.

The correct configuration of Statelake and implementation of robust monitoring policy for staff will ensure that when errors do occur, they are handled quickly.

Program Errors vs Exceptions

This section uses the term error broadly to encompass all the problems you may experience with your Statelake system. Errors generally fall into one of two groups -

• Program errors

• Exceptions

Errors and exceptions are both saved into the Log that is created when an Action executes. These may also be sent as an Email Notification depending on your Statelake configuration.

Program Errors

Program errors are where either the Statelake configuration or the Statelake application itself is failing.

These types of errors generally need to be resolved by your system or network administrator.

An example of a program error is a failure to connect to a SQL database because the login credentials have changed.

Another example is the failure to send a file to a Trading Partner because the internet connection has gone down.

Persistent program errors

A persistent program error requires the involvement of the system administrator to resolve an issue that is considered to be persistent because it will continue to occur until someone resolves it.

An example of a persistent error is where the SQL database login credentials have changed, so the error will only be resolved once the system administrator updates the Statelake configuration with the latest login credentials.

Non-persistent program errors

A non-persistent program error is one that will resolve itself in time. These errors can generally be ignored safely, but should be monitored to ensure that they do actually resolve themselves.

A non-persistent error for example, is where there is a failure error due to the internet going down - if the Internet has gone down due to external reasons. In this case, the Action will process successfully the next time it executes, so long as the internet has come back up.

Over time, you will come to recognise the type of errors that occur for your particular Statelake system that are considered to be non-persistent.

Generally, if the error notification is received repeatedly, then it is a persistent error.

If you are in doubt you should contact your system administrator.

Exceptions

Your Statelake configuration is performing tests of the data as it processes, and if a test fails, this is known as an exception.

An exception will generally be reported in an easy to understand manner, allowing the operator to resolve the issue and resume or restart the processing. The operator should have appropriate training and understanding of the system to be able to deal with exceptions themselves.

An example of an exception is where an order is received that contains a stock code that does not exist in your system.

This error may be reported with an error message such as "Stock item ABC does not exist in your financial system - please either add the stock code or contact the provider to correct the stock code they are sending you".

Once the exception is resolved in line with the company processes, the Statelake system can reprocess the order.