Retail:Store Server Update User Documentation
Openbravo provides several windows/tools for the application administrator to follow the update process and enable hot fixing. Only in exceptional cases will the end user be notified of any version incompatibilities.
Store Server Version Overview Window
This is the main window which you can use during the update process to check the status of each store server. You operate this window from the central server. It gives version details for each server and also related information like server status and version differences between the store and central server.
The window retrieves its information by calling the store servers directly so it shows real-time information. It will also signal if a store server can not be reached (it will show version status Unknown in that case).
The meaning of the different fields:
- Server Status: gives the current status of the server (offline, online, transitioning). See the Store Server page for more information on server status handling.
- Reload Status: defines the status of the initial data reload logic. For more information see this page.
- Version Status: the version status shows if the store and central server have different versions. The following values can be shown:
- Same as Central: store and central server have the same version for the modules which they have in common
- Different from Central: store and central server have different versions for the modules they have in common
- Unknown: the store server can not be reached or another error occurs. The error is shown in the 'Differences' field.
- Version: the version is computed from the versions of all the modules installed on the store server. So store servers with different module (versions) will show different overall version numbers. A higher version number means a newer server, this because version numbers can only increase over time.
- Data Pending to sync: this is the number of batches of store data (orders, products etc.) pending to be synchronized from the store server to the central server. It plays a role in determining if a webpos client can connect to the store server and use it.
- Differences: the differences field lists the modules which have a different version in the central server compared to the store server. It also displays the version number in central and the version number in that store server. If an error occurred trying to retrieve the server status information then this field will contain the error message.
The version status field is also shown in the Mobile Server Window.
Modules by Server
To provide complete visibility of what is installed in your environment you can check the Modules by Server sub tab in the Mobile Server window. It shows the modules installed on the store server with their respective version numbers.
Incompatible Versions and Data Pending to Sync - User Message
There is one special case in which a user will get notified of a version incompatibility:
- the WebPOS client is loaded using the central server url (the standard approach)
- the store server and central server are in different versions (because the update process failed or could not be finished on time). This means that the WebPOS client is also in a different version than the store server.
- there is data pending to be synchronized from the store to the central server.
If this situation occurs the user will see a message like this and is logged out automatically:
In this case the user can not continue on the central server as the WebPOS client is in a newer version than the store server and would try to create data in the data would be created in the central server while there is also data pending to sync from the store server to central.
The solution is that the user uses the store-mode, so uses the store server url to load the WebPOS. The assumption is that the user has a short cut on the desktop to switch to store-mode, or another easy accessible way to accomplish this.
Installing hot fixes - the ignore-version-check preference
Hot fixes are updates which fix urgent issues in a production environment. These types of updates need to be installed quickly and are most of the time backward compatible.
If the hot fix is applied without a module version change then the version checking will not detect differences and work can continue as if there was no update.
If your hot fix also included a module version change then to prevent version-compatibility checks from failing you need to set the ignore-version-check preference before installing the hot fix. The preference should not be set on system level (client/org 0) but in your specific client and without filtering fields (like user/organization etc.).
The value should be set to 'Y' to enable the preference and to 'N' to disable the preference.