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:Store Server


With the Store Server solution the Openbravo Commerce Suite takes a major step in supporting retail environments which need in-store server capabilities because of high volume of transactions and master data or varying store-internet connectivity. The Store Server functionality is delivered as part of generic multi-server capabilities of OB Commerce.

The OB Commerce store server architecture serves two main purposes:

The main characteristic of the Store Server solution is that it allows a OB-Commerce server to be installed in the store itself (or in the cloud) serving the specific store. The store server operates together with a central server. The central server can act as a backup/fail-over server if the store server is not available and vice versa.

A store server installed locally in the store can provide several benefits:

The current solution supports the following architecture:

The illustration below demonstrates a possible architecture with store servers hosted in the stores and a central server hosted in the cloud.


For backend replication between servers in the network we have good experience with Symmetric DS. The SymmetricDS setup in the Openbravo Commerce suite is discussed separately further down in this document.

Store Server - Central Server - Openbravo Commerce

The Store Server is a newer solution within the Openbravo Commerce Suite. A store server or central server is in essence a standard Openbravo Commerce instance. All our solutions use the same technology and platform. Different functionality for store or central is implemented by installing different modules or developing different code for the instance.

The common technology/platform provides many benefits for users, developers and system admins. This because the same development, usage and maintenance practices apply to the store server as well as the central server. They are all Openbravo servers.

Still there is a clear focus on the Store Server being a more minimal Openbravo server, providing only the functionality and api's relevant for in-store operations. A main reason for targeting a focused solution is that then only specific data and transactions need to be synchronized between servers. This should be done in a controlled manner.

The main entry point for a user of the store server will be a mobile front end.

In a multi-server environment it is critical that data in different servers is synced. Openbravo provides two different methods for data syncing:

The advantage of the first (database level) approach is that it is very easy to setup. You only need to add an entry in the application dictionary to define a synced table. This type of replication can be used to handle master data and straightforward transactional updates (bidirectional even).

Each of the two methods is explained in more detail further down in this document.

Online & Offline concepts of Store Servers

An important feature of the store and central server management is keeping track of the connection status to other servers. The connection status to other servers (most importantly the main server) controls the 'online status' of a store server. If a main server can be reached a store server is online, if it can't be reached a store server is offline. If the main server itself is offline all store servers are offline also.

So only specific servers in the mobile server definition are of importance for the connection status of a store server. These are the servers which have the 'trigger' flag checked and which are accessible for the organization of the store.

An Openbravo Commerce store server can go through several states:


When the store server is transitioning to online or offline the WebPOS clients are not allowed to perform any transactions. In this case the user is notified and can relog in. Normally the transition period should be short, minutes. This 'blocking' behavior is by default switched of. To enable it you have to set the preference Multi Server Architecture Enablement to 'Y'. After changing this preference the system should be restarted as it caches the current value.


Synchronized Transactions

Bulbgraph.png   Starting from RR16Q3 below functionality is available

Synchronous transactions supports the idea that a WebPOS user should wait for the transaction (new ticket/updated business partner etc.) to be completely processed on the server. This to ensure that the user is notified instantly if processing fails for some reason. Also if processing on the server fails nothing is to be stored on the server. The user can execute the same transaction again to retry.

In contrast, asynchronous transactions (the WebPOS default) work differently: user transactions are executed on the client and then send to the server in the background. The user can continue with the next ticket while the server processes the transaction at the same time. The advantage of this approach is that it performs very well in high volume situations. For the user the system is very fast and he/she can continue performing the next task immediately. The asynchronous approach also supports the idea that it is important to continue selling and any processing issues on the server should be solved by the backoffice.

Therefore by default OB Commerce works in asynchronous mode. You can enable synchronous transaction mode by setting the preference WebPOS Synchronized Mode to Y. When set to Y then all WebPOS transactions (ticket, business partner, cashup, cash management, etc.) will run in synchronized mode.


For WebPOS, in synchronized mode the user sees a popup like shown below while the transaction is being processed.


As you can see the ticket is still available in the background. The ticket is removed only when the transaction successfully processes on the server.

For more details specifically for this page, see the 'Developing_with_Synchronized_Transactions' page.

Store Server Creation Procedure

Creating a store server consists of system admin tasks as well as exporting and importing store server data. The details are described in this howto:

Developer Guide

The store and central server uses the same technology as the standard Openbravo Commerce solution. They are the same as any Openbravo server, possibly only with different modules and logic. So all the developer documentation available for ERP and Retail is also relevant when developing specific functionality for multi-server environments:

This section therefore focuses mainly on the specifics related to developing multi-server functionality. We provide several howtos which guide you as a developer through defining and setting up a development environment and writing store or central server specific functionality:

A good starting point for multi-server development is to start with this checklist. It helps you to understand specific details which you should consider when developing for multi-server environments and synchronized mode.

Then next take a look at the other relevant HowTos for store server development:

Adding table/entities/columns to the store server solution

It is quite common when developing to extend the db schema (add new tables or columns) which are to be used on the store server. Often the information in these new db schema elements has to be synced to the central server (and back).

A general statement is:

Both type of synchronizations can be handled through replication. For this we use Symmetric DS. When you add a new table or column you need to make sure that the data is read/used when creating a new store server and also later when it changes. This is discussed in more detail in the howto here:

Data Sync & Replication

In a multi-server environment running multiple instances of Openbravo Commerce it is critical to ensure data consistency. One of the techniques we use for this is data replication using Symmetric DS. This section contains guides and howtos on how to set up and work with Symmetric DS.

Technical Documentation

User Documentation

Store Server Configuration, Status Handling

To work with store servers it is important to configure specific preferences and a process request. This is described in this section.

For the set of store specific preferences please check this page.

Store Server Operational Maintenance

This section of the store server landing page discusses different topics which are relevant when running a store server solution.

The main idea is that the system/application admin should be able to control the complete environment from the central server backoffice. Only in very specific exceptional cases it should be needed for an admin to visit the store server backoffice to perform maintenance activities.

Data - BP Segmentation

A specific store server topic is data segmentation: which data is replicated to which stores. In some regions in the world there are privacy considerations to only share customer data to stores in which the customer has executed a transaction.

To support these environments the OB Commerce suite supports the concept of BP Segmentation. With BP Segmentation controls are in place to only distribute customer information to stores in which the customer has performed a transaction.

The details of this concept are described in this page.

Multi-server Process Request Handling

In a multi-server environment the idea is to manage the store servers from the central server backoffice. The system/application admin should preferably not need to visit the store server backoffice. One of the topics which the application admin can manage from the central server is the scheduling of process requests at the store server. The admin can perform this task from the central server, scheduling and unscheduling process requests on one or more store servers. Also the runtime log of the process requests is aggregated to the central server.

For more information visit the specific page on this topic.

Monitoring and Managing (Error) logs

The system admin can monitor the store servers from the central server.

There are different types of logs which can be monitored.


Retrieved from ""

This page has been accessed 2,130 times. This page was last modified on 8 August 2016, at 05:48. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.