View source | View content page | Page history | Printable version   
Main Page
Upload file
What links here
Recent changes

PDF Books
Show collection (0 pages)
Collections help





The goal of this project is to improve the robustness of Web POS in case of unstable network connections.

This project will improve the operation of Web POS in the following areas:

Changes in the Web POS

Refactor of the way offline detection works

Currently the Web POS uses a ping request to detect whether the backend server is still reachable or not. This mechanism has several problems:

Therefore, this mechanism is going to be removed. Instead of having a ping, each Ajax request will be responsible of having a correct fallback process in case the connection fails due to network error or timeout.

However, the ping will be preserved once the Web POS goes offline, to ensure that the synchronization is automatically initiated when the connection comes back.

The following tasks need to be done as part of this topic:

Refactor the way the terminal object is generated

During the login process, there are several requests to load the terminal object, which contains several configuration properties. During the first login, this is not avoidable. However, in subsequent logins this object can be retrieved from the local database, and refreshed asynchronously after the login is complete.

This has two main advantages:

The following tasks need to be done as part of this topic:

Implementation of a common framework for all data-sending processes

Currently there is a great deal of logic in the OrderLoader to handle special cases which might happen when there are connection problems:

This logic is currently in the OrderLoader, and some of it is likely as duplicated code in the other synchronization tasks (cash up, cash mgmt, customers). Some of it may even be missing in the other sync tasks.

As part of this project, we will create a common framework so that all these similar tasks (OrderLoader, cash up handling tasks, cash mgmt movement, ...) share this logic. This framework will also be used in any other new synchronization task.

The following tasks need to be done as part of this topic:

Besides this, also changes will be done to make this part of the Web POS extendable. To achieve this, the following changes need to be made:

Ability to persist the client-side log as a file

The client-side log will be used to monitor the requests of the system (as shown in the next section), so a new functionality will be added to persist this log in the client as a file, so that in the case the network synchronization fails, the log will still be there.

This functionality will use the FileSystem API present in the HTML5 standard.

Testing and monitoring

As part of this project, there will be extensive testing of the Web POS in different types of unstable networks, and also we will study the possibility of adding some monitoring functionality to ensure that we can monitor customer environments in such a way that we can find out why they fail in case the network has problems


The testing phase will involve both simulating slow networks using specialized tools, and testing with a local network which we know is both slow and unreliable.

During this testing phase, we will test the main flows of the Web POS with different kinds of networks and different amount of data, to ensure that it works correctly in all cases.

As part of testing, we will also analyze some tools to monitor the network status, to see if they can be used in the networks of real customers.


The main idea here is to try to see if it's possible to find out the specific part of the Web POS is failing in case of a problem with the network.

One way to solve this would be to use an external library/utility to try to monitor at request level, such as this:

However, this utility in particular seems to have some problems (would force us to inject their own code inside the Javascript Web POS code, and it's not clear if it works offline (most likely not)).

Therefore, we could also implement our own solution for this. One possible idea would be to use the client-side logging, in the following way:


Retrieved from ""

This page has been accessed 799 times. This page was last modified on 20 May 2014, at 13:18. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.