View source | Discuss this page | Page history | Printable version   

Retail:Developers Guide/Offline Technologies


Web POS Offline Support

The Web POS has been designed from the beginning to be operable while being offline. This means that the user can log in the application, create transactions, and execute the cash up process while there is no connection to the backend server.

This feature can be achieved by using a combination of HTML5 technologies which will be described in this document.

Offline access to the Web POS code: the Application Cache

HTML5 brings, among several very clever improvements, the ability to define an "application cache" which contains the source code resources a web application needs to work while being offline. You can find out more about this technology here.

The Web POS supports the application cache, and uses it to ensure that all the required source code and other content files (such as images and css content) are available even without connection to the backend server.

Manifest definition

The application cache requires the definition of a manifest file, which is basically a plain text file containing all resources which should be cached by the browser. This file is automatically generated by the Web POS.

In the Web POS, all javascript static resources for the main posterminal module and all extension modules are placed in a minimized .js file. This file is added to the manifest file.

However, modules may want to add other resources apart from Javascript files. To do this, they can create a POSAppCacheResourceProvider. You can read the following document to find out how to do this.

Application Cache reset

The application cache needs to be reset every time an update of the Web POS is done, or a new module which extends the Web POS is installed or updated. This process is forced automatically, by the way the manifest file is generated.

The browser automatically refreshes all the contents of the application cache if it detects that the manifest file has changed. The Web POS uses this rule to refresh the application cache whenever it needs. The way this is done is by appending a hash code generated from the versions of the Web POS module, and all modules which depend on it.

This way, whenever the Web POS is updated, or a module extending the Web POS is installed or updated, this hash code will change, so the browser will detect that the manifest has been changed, and will refresh all the application cache resources.

Application cache on development mode

When Openbravo is on development mode (that is, when any module has its "Is in development" flag set to true), the manifest file is automatically set to an empty file. This means that the application cache is disabled when the system is in development.

Therefore, the offline login and other offline capabilities of the Web POS are disabled when the system is in development mode.

Offline access to data: the WebSQL database

The WebSQL local database is another HTML5 technology the WebPOS uses for offline operation. It's basically used both to store masterdata information (such as the product list, the price list, the list of available business partners, or the list of available discounts), and also to store the documents the user generates, before they are synchronized to the backend (such as the receipt information, new customers, cash management movements, or cash up information).

You can find more information about the WebSQL database here

The WebSQL database API: models

In the WebPOS, backbone models are defined to manage the WebSQL database. You can find more information about this [Offline_and_Online_Data_Access|here]

Customizating/Extending Offline Artifacts in your module

When your module contains artifacts (like images and css files) which need to be available offline then they need to be included in the appcache. Openbravo provides an api to accomplish this.

The adviced and most simple approach which works if your artifacts are located in the standard web folder (web/[module-package]) in your module: To register your artifacts you need to extend the BaseCoreAppCacheResourceProvider class. Your extension class can be completely empty as the abstract super class already contains logic to iterate over the files in your module. An example:

package org.openbravo.retail.orderpreparation;
public class OrderPreparationAppCacheProvider extends BaseCoreAppCacheResourceProvider {

Instead of extending the BaseCoreAppCacheResourceProvider you can also implement the logic yourselve. In this case you need to create a class which implements the CoreAppCacheResourceProvider interface. The single method (getResources) in this class should return a list of resource paths which should be added to the app cache. The resource path should be made relative to the root of the webapp, example of a relative path:


An example of a complete implementation can be found here.

Back to Concepts

Retrieved from ""

This page has been accessed 4,226 times. This page was last modified on 21 November 2016, at 13:49. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.