Retail:Web POS Multi Server Architecture
Contents |
Web POS Multi-Server Architecture
 | This document describes a possible future/target architecture envisioned for the Openbravo Commerce Suite. The concepts in this document should be considered as experimental. The functionality will be delivered in phases in the RR15Q4, RR16Q* and RR17Q* releases. |
| | The functionality described in this section is optional, if no multi-server setup is done or the relevant preference is not set then the Openbravo Commerce suite operates as is. |
In the RR15Q4 and subsequent releases the Openbravo Commerce suite takes a major step in supporting distributed multi-server architectures in which different retail business services are provided by different systems in the cloud.
The multi-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 characteristics of the Openbravo Commerce suite multi-server architecture are:
- robustness through redundancy: the same service can be provided by different systems in the network, the OB Commerce client will automatically keep track which systems are available and can switch from one system to another to perform a business task.
- robustness through duplication: the OB Commerce suite supports sending transactions to multiple backend servers, thus giving extra robustness/ensuring that tickets and transactions in general are always saved on a server.
- performance: the Web POS systems can be configured by store to use different systems for the same business task, so load can be distributed across the system landscape. This include transactional load, master data queries as well as load when the users log in to the Web POS application.
- logical division of work across systems: the solution provides a lot of flexibility when designing the overall system architecture. For example, product and business partner queries can be directed to one server, while transactions are send to the transaction server(s).
The services and server architecture are defined in the back office system using several windows. These are described in the subsections below.
Common Architecture Examples
This section provides some examples of system architectural scenarios which are supported by the Openbravo Multi-Server architecture. There are many more variations which are supported, you can combine different examples given here to match it with your envisioned system landscape.
The Openbravo Commerce suite allows you to flexibly distribute the server roles in the cloud or at servers hosted in the store itself. It is a solution for unstable internet connectivity at store level as well as when load from many WebPOS clients needs to be distributed accross different servers.
For backend replication between servers in the network we have good experience with Symmetric DS. For replication of transactions one can focus on replicating the data import entries.
The multi-server setup can also be used to define failover servers in the cloud. WebPOS clients will automatically switch to an alternative server if a server is not available. If a server is offline then the WebPOS client will continuously check its online/offline status.
The multi-server solution includes an authentication solution which makes it possible to cluster servers behind a load balancer. So each server shown below in the illustration can be replaced by a cluster of servers with a load balancer in front.
Main and failover server, local and cloud hosted store servers for load distribution
In the first example a main server is defined with priority 10, and a fail over (non-main) server with priority 20. The WebPOS clients login on a store server and do master data queries against the store servers. This to distribute load. One store server is installed in the store itself, the other in the cloud. Installing a store server in the store makes sense for ensuring correct working of WebPOS clients with a high volume of products/customers in a store with intermittent/varying internet connection reliability.
The replication between central and store servers can be done using standard database replication tools such as Symmetric DS.
In this scenario a large store uses a dedicated store server installed locally. Other stores are smaller and do not warrant their own server, the smaller stores share one central server.
Note that this is just one variant, you can also let several stores operate on a shared store server, and have several of these shared-store-servers. In addition to having a central server as an aggregation server to collect all the transactional data.
Central Aggregation Server, dedicated independent store servers
This scenario has a central server mainly to aggregate transactions to one central point. The master data can be maintained centrally and is then distributed to the store servers using replication. The store servers each handle one or more stores. Store servers can be installed locally or on the cloud. As noted in the previous section a store server can also handle more than one store, so be assigned to several stores.
Base Setup: Enabling Preference & Multi-Server Authentication
This section describes 2 setup steps which need to be done before you can use Openbravo multi-server architecture functionality.
The first step is enabling the multi-server functionality by setting a preference.
The enablement of the multi-server functionality is controlled by a preference which by default is not set and therefore disables the multi-server logic.
So to enable multi-server behavior for your stores you need to define the preference 'Mobile Multi-Server Architecture Enablement' (see screenshot below) with the value Y. This preference needs to be defined on System level by the System Administrator.
The preference enables multi-server behavior for all WebPOS clients in the system across all clients/organizations/stores. But multi-server behavior will start only if there are Mobile Servers defined, so if you do not define mobile servers (see below) then the multi-server functionality is not operational and the WebPOS clients will work in the standard way. Also: you can assign servers to stores specifically, so it is possible to test multi-server behavior first for WebPOS systems of specific/selected stores.
Then as a second step, to use the Openbravo multi-server feature it is needed to enable specific authentication on each of the servers. This to support multi-server login. In each server which can be used from a WebPOS client the following authentication manager has to be set in Openbravo.properties:
authentication.class=org.openbravo.mobile.core.authenticate.MobileKeyAuthenticationManager
This section described the first-base setup. The next step is to define the mobile servers, specify which services they provide and assign them to stores/organizations.
Preferences: token age, offline ping
There are some additional preferences which can be set to control specific multi-server behaviors:
- Authentication Token Max Age (milliseconds, default: 43200000, is 12 hours): controls the max age of a token, tokens which are older are rejected. When this preference is set the system must be restarted.
- Request Router Refresh Token Interval (milliseconds, default: 1800000, is 30 minutes): defines how often the system will request a new authentication token from the server. Should be less than the authentication token max age. Is refreshed in the client at login.
- Request Router Ping Time Interval (milliseconds, default: 300000, is 5 minutes): interval by which an offline server is pinged.
Mobile Services
The services definition is done by developers and provided by modules. They are available under the System Admin role and shown as a reference here.
A description of the meaning of the fields:
- Module: services are provided by and implemented in modules
- Service: the service name, currently uniqueness of service names is not checked, the service name is used in client side code to call a service
- Routing Type: defines how the transport layer in the Web POS client should call the service:
- Fail Over: mostly used for querying services, if a call to a server fails for this service then Web POS will automatically try another server which provides the same service
- Broadcast: mostly used for transactions (such as new tickets/customers), when a service with this routing type is called then the service request is automatically send (broadcasted) to all servers providing this service. This is usefull in some cases for transactions as it can make sense to send them to all available transactional servers (for robustness and security)
- Ping: a special service used to detect when a server is back online. Is used in the scenario that a server is offline (detected because another service request fails). In that case the Web POS client will ping the offline server to detect when it is back online
The service name uses 'contains' to match it with the requests from the client. So a service name of 'org.openbravo.retail.posterminal.master' will handle all the client side requests with 'org.openbravo.retail.posterminal.master' in the requested URL. In this way for example all the master data requests can be mapped to a server.
The following are examples of standard services, see the total list of services in the mobile core and webpos modules:
- org.openbravo.mobile.core.login.ContextInformation: retrieval, provides the current client/organization of the current user (after logging in)
- org.openbravo.retail.posterminal.CustomerAddrLoader: transactional, stores updated and new addresses in the database on the server
- org.openbravo.retail.posterminal.CustomerLoader: transactional, stores updated and new customers in the database on the server
- org.openbravo.retail.posterminal.master.BPLocation: retrieval, retrieves the business partner address from the server
- org.openbravo.retail.posterminal.master.BusinessPartner: retrieval, retrieves the business partners from the server
- org.openbravo.retail.posterminal.master.DiscountFilterBusinessPartner: retrieval, reads the discounts by business partner from the server
- org.openbravo.retail.posterminal.master.Product: retrieval, reads product data from the server
- org.openbravo.retail.posterminal.OrderLoader: transactional, stores new and updated tickets in the database on the server
- org.openbravo.retail.posterminal.PaidReceiptsHeader: retrieval, reads tickets (and layaways and quotations) from the server
- org.openbravo.retail.posterminal.POSLoginHandler: retrieval, login service
- org.openbravo.retail.posterminal.ProcessCashClose: transactional, stores the cashup on the server
- org.openbravo.retail.posterminal.ProcessCashMgmt: transactional, stores the cashup on the server
Mobile Server Definition
The Mobile Server Definition window allows you to define the servers which are available for WebPOS clients. Servers are used by WebPOS clients for logging in, retrieving master data, sending tickets/cashups and other transactional data.
A distinction is made between a store server and a main server. Store servers are mainly used for a specific store for logging in and querying. Main servers are used to store transactional data. Only transactions send to a Main Server are considered to be synchronized and are considered to be save. The 15Q4 release of the Commerce Suite assumes that a WebPOS system has one main server (which can be shared by many WebPOS clients). This main server receives the transactions. In addition there can be several store servers defined for logging in and providing querying services.
A store server can be used for system load distribution or if installed locally in the store can ensure store operation also when the store looses internet connection.
The setup for the rest allows a large degree of flexibility. It is perfectly fine to not have a store server and only main servers. Or to let smaller stores work on a single main server, while a large store has its own store server.
The image below illustrates the definition of a server:
A description of the meaning of the fields:
- Name: any unique name is allowed
- Description: additional description for describing the purpose of the server
- Server Type: there are two types:
- Main Server: a main server is often used to store transactional data such as new tickets/updated business partners etc. Only transactions send to a main server are considered to be synchronized and save.
- Store Server: a store server is mainly used for load distribution and if locally maintained to ensure store operations when the store looses internet connection.
- URL: the main url by which the server can be reached, see the examples above/below, should include the webapp context path (openbravo in the examples here)
- Priority: if multiple servers can provide the same service then they are tried in order of priority. This is relevant for failover services which are will be called on the first available server. If a server is not available then the next in line is tried (in increasing order of priority number).
- All Organizations: if this checkbox is checked then the server is made available to all WebPOS systems and the organizations defined in the 'Organizations by Server' are ignored. If unchecked then the 'Organizations by Server' information is used to determine if a server is to be used by a WebPOS client.
- All Services: if this field is checked then the server is assumed to provide all services. If unchecked then the information in the subtab 'Services by Server' is used to determine what services a server can provide.
- Defined services (from 16Q2): if All Services field is unchecked then we will see this field and we can select All excluding defined or Only those defined. If Only those defined is selected then the information in the subtab 'Services by Server' is used to determine what services a server can provide. If All excluding defined is selected then the information in the subtab 'Services by Server' is used to determine what services a server cannot provide.
- Mobile Server Key (from 16Q1): is the unique key for the server, should be set in each server in Openbravo.properties, for example as: mobile.server.key=Central
- Server Status (from 16Q1): gives the current status of the server (offline, online, transitioning). See the Store Server page for more information on server status handling.
Mobile Server Organizations - Stores
A server can be linked to all organizations (stores), so it is available for all WebPOS clients, or a server can be assigned to a specific set of organizations (stores).
To flag a server to be available for all organizations, check the 'All Organizations' field in the server definition.
If you want to assign a server to a specific set of organizations/stores then you can use the sub tab 'Organizations by Server'. Make sure the 'All Organizations' checkbox is not checked in the server definition and then add records in the 'Organizations by Server'. Multiple servers can be assigned to multiple organizations and vice versa.
The Openbravo organization structure also plays a role here, so assigning a server to a parent organization automatically makes it available for all the child organizations of that parent organization.
Mobile Server Services
The information in this subtab is used when the 'All Services' checkbox in the Mobile Server definition is not checked.
'Defined services' value will define which services are available for the server. If Only those defined is selected then the information in the subtab 'Services by Server' is used to determine what services a server can provide. If All excluding defined is selected then the information in the subtab 'Services by Server' is used to determine what services a server cannot provide.
This subtab allows you to specify which services are provided by which server. There is a fair amount of freedom in assigning querying services. You can load products from one server and business partners from another server.
The thing to ensure though is that if users in WebPOS can create new customers and tickets that the tickets and customer are send to the same server. Or that the data between servers is synchronized in a different way. Also the cashup can only be send to a server which also receives or has all the WebPOS orders. This means that either the servers are synchronized in the backend or that all transactions are send to a server. All transactions can also be send to multiple servers.
The example below shows how all transactions services are assigned to a specific main server.
