Store Server POS and Import Entry Error Handling
Introduction
 | Starting from RR17Q1 below functionality is available |
The Openbravo Store Server functionality also delivers a specific function to view and resolve functional transactional errors which occur in store servers from a central point of view.
When processing tickets and other transactions on the store server it is possible to encounter application errors. In a single server environment the error information can be viewed through the backoffice ERP in the POS Errors window.
In a multi-server environment with many store servers it is not practical to view/check/resolve errors directly in a store server backoffice. The 'POS Errors in Mobile Servers' window provides a single view on all POS errors which occur in the store servers. Through this window POS Errors can be resolved from the central server by changing the data content and resubmitting the changed content to the applicable store server.
Two types of errors are handled through the 'POS Errors in Mobile Servers' window:
- Import Entry Errors: these are normally low level errors related to database connections for example. When running in synchronized mode the import entry framework is mostly not used. So in that case the import entry errors will hardly occur.
- POS Errors: these are all the (functional) errors which occur when processing a transaction like a ticket or a new business partner.
Main Window
The main window is shown below. It shows the open errors with their origin store server.
The window shows the following information:
- the origin store server
- the type of error: import entry or pos error
- the type of data of the transaction which was tried
- the error shows the detailed error stack trace and information
- the json info contains the content of the transaction, for example the ticket content
- the pos terminal is the terminal from which the transaction originates
- the last column shows the number of attempts which have been done to try to resolve the error (each click on the process button counts as one attempt)
Resolving an error
Resolving an error is done by solving the cause and then processing the transaction again. If the cause is external (hard drive or database) then this should be resolved outside of the system. If the error is in the content of the transaction then you can open the error record and manually change the json. Note: this requires technical knowledge of the structure of json.
Processing a transaction is done by selecting a record in the POS Errors in Mobile Servers' window and clicking the process button. The error record in the central server will be remain. If the error is resolved then it will automatically be removed at the next synchronization from store to central, which should normally happen within a minute or so. If the error re-occurs then the attempt property of the error record is increased.
If there are multiple errors for one POS Terminal then these need to be resolved/handled in the order they were created. When you try to process error records (of one POS Terminal) in the wrong order then the system will throw an error, which will show up in the error window again.
When you process a POS Error the processing is the done right away and any success/errors are reported directly. An example of an error when processing a POS Error record:
The error record is not removed right away. When the processing was successful then the error record in the central server is removed at the next synchronization from symmetric ds.
When you process an Import Entry record then always a success message is shown initially. This because the import entry is processed asynchronously on the store server, so the result is not directly available.
To see the complete result of the error processing you need to manually refresh the grid/form.
Note, you can also remove the error record in the central server. This will also remove the error record in the store server. This step (forcefully removing) only makes sense in special cases when the error is resolved in other ways.