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:
- Uninterrupted POS solution by full off-line operations and transparent synchronizations
- High-availability and high performance during peak transactions for example during special events such as Black Friday.
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:
- in case of large master data volumes, these can be loaded in the store server, WebPOS clients can then load (on-demand) the master data from the store server. This ensures operation of the store in case of high master data volumes in combination with offline situations
- performance and robustness in case of lesser-bandwith internet connections to the store. A store server helps to handle many requests from WebPOS clients on the local network instead of making use of the internet connection of the store.
- many WebPOS clients in a store: when there are many WebPOS clients in a store (hunderds or more) then it can make sense to let the WebPOS clients login on a dedicated store server to balance the load across several servers in the network.
The current solution supports the following architecture:
- One central server instance
- One or more store server instances: one store server can operate for one or more stores, a store is dedicated to one server..
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:
- database level syncing using Symmetric DS: this works best for master data where there is a clear lead which system manages the data. Normally the master data is synced from the central server to the store server.
- transactional messaging: transactional messaging is a good approach in case of syncing complex transactions, such as consuming a stock. This type of data often flows from the store servers to the central server.
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:
- Online: the store server is connected and can access the main server
- Transition to Offline: this status is reached when the (store) server notices that it can not reach the main server. In this status the store server will start pinging the main server. If within 3 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 main server.
- Transition to Online: the automatic/background ping process detects that the main 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.
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 multi-server environment synchronized transaction functionality will result in web service calls to be also executed on the central server in synchronized mode. For more information see this document: Synchronized_Transactions_in_Multi-Server_Environments.
- Synchronized mode only works for transactional data and master data (like business partner/address) which is handled remotely. So you need enable remote datasources for this data to work with it 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:
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:
- Multi-Server Process Calls Concept
- How to implement Multi-Server Process Calls
- Developing with Synchronized Transactions
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:
- transactional data is synced from store to central (normally) or vice versa if the store server was down
- master data is synced from central to store
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.
- How to Configure and Start the Synchronization Engine
- How to Configure the Synchronization of a Table
- How to Define a SymmetricDS Extension Point
- Monitoring and Managing Synchronization Errors
- Managing the Store Servers registered in the Main Server
- How to Reload the Contents of a Synchronized Table
- How the Purge Job Works
- How to Configure Custom Routers
- How to Update the Configuration Tables of SymmetricDS
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.
- Client Logging: all the webpos clients log client side events (info, warn, debug, error). All web pos client logs are send directly to the central server and are available through the Log Client window.
- Processing: processing errors occur when the WebPOS client sends a json message to the server and the server can not process it.
- Replication and Synchronization errors occur when data is replicated between servers: Monitoring and Managing Replication and Synchronization Errors