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

PDF Books
Show collection (0 pages)
Collections help


Retail:Web POS Multi Server Architecture


Web POS Multi-Server Architecture

Bulbgraph.png   This document describes a possible future/target architecture envisioned for the Openbravo Commerce Suite. The concepts in this document should be considered as experimental. The functionality will be delivered in phases in the RR15Q4, RR16Q* and RR17Q* releases.
Bulbgraph.png   The functionality described in this section is optional, if no multi-server setup is done or the relevant preference is not set then the Openbravo Commerce suite operates as is.

In the RR15Q4 and subsequent releases the Openbravo Commerce suite takes a major step in supporting distributed multi-server architectures in which different retail business services are provided by different systems in the cloud.

The multi-server architecture serves two main purposes:

The main characteristics of the Openbravo Commerce suite multi-server architecture are:

The services and server architecture are defined in the back office system using several windows. These are described in the subsections below.

Common Architecture Examples

This section provides some examples of system architectural scenarios which are supported by the Openbravo Multi-Server architecture. There are many more variations which are supported, you can combine different examples given here to match it with your envisioned system landscape.

The Openbravo Commerce suite allows you to flexibly distribute the server roles in the cloud or at servers hosted in the store itself. It is a solution for unstable internet connectivity at store level as well as when load from many WebPOS clients needs to be distributed accross different servers.

For backend replication between servers in the network we have good experience with Symmetric DS. For replication of transactions one can focus on replicating the data import entries.

The multi-server setup can also be used to define failover servers in the cloud. WebPOS clients will automatically switch to an alternative server if a server is not available. If a server is offline then the WebPOS client will continuously check its online/offline status.

The multi-server solution includes an authentication solution which makes it possible to cluster servers behind a load balancer. So each server shown below in the illustration can be replaced by a cluster of servers with a load balancer in front.

Main and failover server, local and cloud hosted store servers for load distribution

In the first example a main server is defined with priority 10, and a fail over (non-main) server with priority 20. The WebPOS clients login on a store server and do master data queries against the store servers. This to distribute load. One store server is installed in the store itself, the other in the cloud. Installing a store server in the store makes sense for ensuring correct working of WebPOS clients with a high volume of products/customers in a store with intermittent/varying internet connection reliability.


The replication between central and store servers can be done using standard database replication tools such as Symmetric DS.

Large store with independent store server, smaller stores share central server

In this scenario a large store uses a dedicated store server installed locally. Other stores are smaller and do not warrant their own server, the smaller stores share one central server.


Note that this is just one variant, you can also let several stores operate on a shared store server, and have several of these shared-store-servers. In addition to having a central server as an aggregation server to collect all the transactional data.

Central Aggregation Server, dedicated independent store servers

This scenario has a central server mainly to aggregate transactions to one central point. The master data can be maintained centrally and is then distributed to the store servers using replication. The store servers each handle one or more stores. Store servers can be installed locally or on the cloud. As noted in the previous section a store server can also handle more than one store, so be assigned to several stores.


Base Setup: Enabling Preference & Multi-Server Authentication

This section describes 2 setup steps which need to be done before you can use Openbravo multi-server architecture functionality.

The first step is enabling the multi-server functionality by setting a preference.

The enablement of the multi-server functionality is controlled by a preference which by default is not set and therefore disables the multi-server logic.

So to enable multi-server behavior for your stores you need to define the preference 'Mobile Multi-Server Architecture Enablement' (see screenshot below) with the value Y. This preference needs to be defined on System level by the System Administrator.

The preference enables multi-server behavior for all WebPOS clients in the system across all clients/organizations/stores. But multi-server behavior will start only if there are Mobile Servers defined, so if you do not define mobile servers (see below) then the multi-server functionality is not operational and the WebPOS clients will work in the standard way. Also: you can assign servers to stores specifically, so it is possible to test multi-server behavior first for WebPOS systems of specific/selected stores.


Then as a second step, to use the Openbravo multi-server feature it is needed to enable specific authentication on each of the servers. This to support multi-server login. In each server which can be used from a WebPOS client the following authentication manager has to be set in

This section described the first-base setup. The next step is to define the mobile servers, specify which services they provide and assign them to stores/organizations.

Preferences: token age, offline ping

There are some additional preferences which can be set to control specific multi-server behaviors:

Mobile Services

The services definition is done by developers and provided by modules. They are available under the System Admin role and shown as a reference here.


A description of the meaning of the fields:

The service name uses 'contains' to match it with the requests from the client. So a service name of 'org.openbravo.retail.posterminal.master' will handle all the client side requests with 'org.openbravo.retail.posterminal.master' in the requested URL. In this way for example all the master data requests can be mapped to a server.

The following are examples of standard services, see the total list of services in the mobile core and webpos modules:

Mobile Server Definition

The Mobile Server Definition window allows you to define the servers which are available for WebPOS clients. Servers are used by WebPOS clients for logging in, retrieving master data, sending tickets/cashups and other transactional data.

A distinction is made between a store server and a main server. Store servers are mainly used for a specific store for logging in and querying. Main servers are used to store transactional data. Only transactions send to a Main Server are considered to be synchronized and are considered to be save. The 15Q4 release of the Commerce Suite assumes that a WebPOS system has one main server (which can be shared by many WebPOS clients). This main server receives the transactions. In addition there can be several store servers defined for logging in and providing querying services.

A store server can be used for system load distribution or if installed locally in the store can ensure store operation also when the store looses internet connection.

The setup for the rest allows a large degree of flexibility. It is perfectly fine to not have a store server and only main servers. Or to let smaller stores work on a single main server, while a large store has its own store server.

The image below illustrates the definition of a server:


A description of the meaning of the fields:


Mobile Server Organizations - Stores

A server can be linked to all organizations (stores), so it is available for all WebPOS clients, or a server can be assigned to a specific set of organizations (stores).

To flag a server to be available for all organizations, check the 'All Organizations' field in the server definition.

If you want to assign a server to a specific set of organizations/stores then you can use the sub tab 'Organizations by Server'. Make sure the 'All Organizations' checkbox is not checked in the server definition and then add records in the 'Organizations by Server'. Multiple servers can be assigned to multiple organizations and vice versa.

The Openbravo organization structure also plays a role here, so assigning a server to a parent organization automatically makes it available for all the child organizations of that parent organization.


Mobile Server Services

The information in this subtab is used when the 'All Services' checkbox in the Mobile Server definition is not checked.

'Defined services' value will define which services are available for the server. If Only those defined is selected then the information in the subtab 'Services by Server' is used to determine what services a server can provide. If All excluding defined is selected then the information in the subtab 'Services by Server' is used to determine what services a server cannot provide.

This subtab allows you to specify which services are provided by which server. There is a fair amount of freedom in assigning querying services. You can load products from one server and business partners from another server.

The thing to ensure though is that if users in WebPOS can create new customers and tickets that the tickets and customer are send to the same server. Or that the data between servers is synchronized in a different way. Also the cashup can only be send to a server which also receives or has all the WebPOS orders. This means that either the servers are synchronized in the backend or that all transactions are send to a server. All transactions can also be send to multiple servers.

The example below shows how all transactions services are assigned to a specific main server.


Retrieved from ""

This page has been accessed 3,027 times. This page was last modified on 7 February 2017, at 12:59. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.