Store Server Online and Offline Concepts
Contents |
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 central server) controls the 'online status' of a store server. If a central server can be reached a store server is online, if it can't be reached a store server is offline. If the central 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.
Online & Offline State Transitions
An Openbravo Commerce store server can go through several states:
- Online: the store server is connected and can access the central server
- Transition to Offline: this status is reached when the (store) server notices that it can not reach the central server. In this status the store server will start pinging the central server. If within 5 minutes no connection is established the store server moves to the next status: offline.
- Offline: the store server is offline, only offline actions are executed. The store server continues pinging the offline central server.
- Transition to Online: the automatic/background ping process detects that the central server is accessible, the online transition handlers are called so that specific functional code can executed to for example send data to the central server. On of the default transition handlers makes sure that all transactions are synced to the backoffice and vice versa before going online. When the online transition handlers are done the store server moves to Online mode.
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.
At startup: offline to online
Just for your information: when a store server starts it is automatically set to offline state and then to transition to online. If all the checks pass then the server automatically transitions to online. If one or more of the online checks fail then the server remains (correctly) in offline state and the standard periodical check is done for transitioning to online.
This approach is taken to ensure that the store server at startup is in the correct state (either offline or online).
Causes for staying offline
There can be several reasons that a store server is and remains offline:
- no connection to central server from the store server: this can have several causes, network failure or the central server is not running
- local data is not processed: if the store server still needs to process some data from the import entries table then the server will not go online
- data can not be replicated: the store server will only go online if all its data has been and can be replicated. If there are replication errors then the store server will remain offline.
- the store is in the offline-wait time: there is a new property (Failed Transition to Online Wait Time (seconds), available from 17Q1) which sets this wait time. See this document and check the Failed Transition to Online Wait Time (seconds) property (default is one hour wait time).
The reason for a store server remaining offline can be found in the 'Offline Log/Cause' field in its mobile server window.
If there is a connection between central and store then this field is replicated from the store to the central server and can be checked there. If no connection between central and store then you can check this field in the relevant Mobile Server Definition record in the store server.
Currently 2 types of messages are shown in the offline log field:
- Transition to online failed: the field shows a list of one or more transition handlers with a specific message. For example: SyncStatusOnlineTransitionHandler this server has 1 waiting importentries/synchronization-batches. This last message means that there is 1 import entry to process or 1 batch to be replicated.
- Offline Servers/Checks: shows the central server key which is offline or shows any specific offline-check-handler class.
Transitioning Triggers - Send Transition to Online
Transition to online and offline is triggered by different events.
An online server communicates with the central server frequently for example when creating tickets (in synchronized mode). When the communication fails or the server responds with a server error then the server is assumed to be offline. For transition to offline the main trigger is the un-availability of the central server.
An offline server will test the connection to the central server at regular intervals (using the request router ping time). If the central the server reacts to the ping then the store server will move to transition to online. If the transition to online fails then the store server will move back to offline. As the transition to online failed the store server will now wait a longer time, defined by the Failed Transition to Online Wait Time preference (default one hour).
Another way to trigger a server to transition to online is to send it a transition to online trigger. This can be done from the central server by going to the mobile server window, selecting the offline server and then clicking the 'Send Transition to Online' button.
Clicking this button will trigger a transition to online, depending on the situation the store server transitions to online after a few minutes.