Projects:ImproveFailsafeTicketSynchronisation

Contents 1 Introduction 2 Past problems with ticket synchronization 3 Concrete Actions to Improve the Failsafe Ticket Synchronization 3.1 Parts of the code to be changed 3.2 Components to be reviewed 4 Documentation

Introduction

The goal of this project is to improve the robustness of Web POS when synchronising tickets/sales orders with the backend.

The Web POS has a built in mechanism to ensure that tickets are not lost in case there is an error. This mechanism saves the raw JSON ticket information to a special table in case there is an error when saving it in the standard Openbravo tables.

However, in the past there have been some problems which in some circumstances have led to data lost. The goal of this project is to verify that these cases are fixed, and similar ones will not happen again.

Past problems with ticket synchronization

The main cause of problems with ticket synchronization in the past have been:

• Under some circumstances, the ticket was not saved to the local database, and therefore, the synchronization process didn't find it there, and nothing was synced
• Under some circumstances, it is possible that the Advanced Payables and Receivables executes a rollback of the current database transaction (it happened for example when the current period of the year is closed). This means that in practice, nothing related to the ticket is finally saved in the backend database.
• The OrderLoader task which is responsible of saving the ticket in the database has a built-in system to avoid duplication of tickets in case the request was sent more than once. This built-in duplicate detection system has been found to have some issues, and mistakenly detect two different tickets as the same, which meant that the second one was lost.
• When the server is under big stress due to some other part of Openbravo malfunctioning, it is possible that at some point the ConnectionProvider runs out of database connections. In the past, this caused some problems because the ticket information couldn't be saved as a standard OB ticket, but the failback system also failed because the process couldn't save the JSON information to the table (as it's part of the same database), and finally the ticket was lost.

Concrete Actions to Improve the Failsafe Ticket Synchronization

There are two main groups of tasks to improve this part of the Web POS: specific parts of the code to be fixed, and parts of the code to be reviewed to ensure that there is nothing wrong anymore (after having been fixed in the past)

Parts of the code to be changed

• The duplicated ticket detection code needs to be changed, to greatly simplify it, checking only the ids.
• The code in either the Payment API or in OrderLoader needs to be changed so that the rollback issue doesn't happen in the case of a closed period
• The mechanism that wipes the database when the terminal is changed needs to be refactored to ensure that no data loss happens in any case

Components to be reviewed

• The Payment API needs to be reviewed to ensure that there are no other cases of potential rollbacks without exception.
• The code in the client side regarding the saving of the order in the local database needs to be reviewed so check that the ticket is always saved to the local database.
• The OrderLoader needs to be reviewed to ensure that it handles correctly the case of no availability of the database

Documentation

• Feature request in mantis: https://issues.openbravo.com/view.php?id=26020