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 Update Strategy


Bulbgraph.png   This functionality is available from RR17Q2.1.


This document describes the update strategy for installing new features and (hot) fixes in an Openbravo multi-server environment. It presents the main steps and also the consequences and operational guidelines for special situations which might arise during the update.

This document does not describe the organization of the update process itself, still some general comments can be made:

This document should be read together with the overview of the main windows/settings which play a role in updating store servers.

Environment & Versions - Main Aspects

The following points summarize the main characteristics of multi-server version handling and updating:

The system provides several windows in the Openbravo backoffice to check version status, data pending to be synchronized and the list of modules installed in a store server:

WebPOS Client Mode

WebPOS clients can work in 2 modes:

StoreServerUpdateStrategy WebPOS ClientMode.png

The default mode for WebPOS clients should be Central-Mode. The Store-Mode is only used in special situations.

Openbravo does not provide an automatic mechanism to switch from central to store mode. The exact navigation depends very much on the custom situation, it is only needed rarely and can be solved easily on-site by for example adding a short-cut for store-mode on the users desktop.

Main (Happy Path) Approach: CS first, SS next

This section describes the update steps in the standard case:

The update steps:

  1. Stop all reachable (network connection) store servers. Although we can support an update with all store servers running it would mean that they would go to offline when the central is being updated. It seems more efficient to stop the store servers before.
  2. Stop the central server.
  3. Update the central server.
  4. Start the central server.
  5. Update the store servers, this can be done in parallel in sets of stores.
  6. Start each store server after they are updated.

If the update takes more time than anticipated and not all store servers could be updated and started (and which have no data to replicate to central):

StoreServerUpdateStrategy StoreServer NotUpdated.png

The WebPOS clients will automatically obtain the update (from central) when the user opens the WebPOS and logs in.

Special Cases and solution strategies

Central Server Update Fails

In case the central server update fails the central server update should be rolled back and the update should be rescheduled for a later date (after analyzing and fixing the issue).

Store Server Update Fails - No data pending to replicate

This is the case that the store server has no data pending to replicate. The store server is down and being updated, but the update fails:

StoreServerUpdateStrategy StoreServer NoDataToReplicate.png

Store Server Update Fails - data pending to replicate

StoreServerUpdateStrategy StoreServer NotUpdatedDataToReplicate.png

Store Server not reachable - still in previous version

In this scenario most of the complete environment (central/stores) has been updated, except for (a few) stores which are not reachable due to network issues. There are several sub-cases which are discussed separately below.

Store internet connection down

If the store can not reach the central server (no internet connection) then the store continues to operate offline. Both the store server and the WebPOS clients in the store remain in the previous (store) version. When the internet connection is restored one of the next cases applies.

Store internet connection restored outside opening hours

In this case the store server can be updated before opening hours.

Store internet connection restored during opening hours

This is the case that the store and central are in different versions during operating hours. The webpos systems continue to work with the store server until the end of business day. After which the store server can be updated.

Store Server and Central Different Version - Store to Central Data Pending to be synchronized - operational internet connection

This is a special case:

The following will happen in this case:

To summarize, in this scenario the store server is in a different version than the central server. This means that:

The next step is to analyze why the store can not replicate data. When that is resolved the update procedure can continue as described in other scenarios above.

Overview of states after update

To provide additional clarification. Assume an update from V1 to V2 for the environment then the following cases can exist:

Hot Fix Update

A hot fix update is a special update which needs to be applied quickly to solve an urgent problem in the production environment. These types of updates are normally backward compatible. So no need to deny requests of a different version which is compatible with the version you have.

The hot fix process can then be summarized as follows:

Retrieved from ""

This page has been accessed 1,340 times. This page was last modified on 9 May 2017, at 15:25. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.