Library
PosGreen Network Mode
Reliability
With PosGreen Network Mode, the network stability between the store and the central database becomes critical. To allow the Pos to continue to operate smoothly in the face of errors a number of options exist.
Primary Server On starting the Pos connects to the primary server using normal HTTP/S protocols. A primary server may be more than one server behind a load balancer, although if you are running multi master mode it might be better to list the servers individually to PosGreen as additional servers
Additional Server If the primary server is not available, the Pos can connect to a number of additional servers that you have predefined. While these are generally full-service servers, they can be smaller lightweight machines with access to the primary database
Fieldpine.com You can configure PosGreen to use Fieldpine.com as either your primary server or an additional server. When configured fieldpine.com holds replicated copies of the relevant data so that it can be available in case of primary failure.
Local Database The Pos automatically builds a local database and this database can be reused if all communication is down.
Piggyback With piggy back mode, PosGreen will use another PosGreen on the same network to provide database access.
Internet Storage If no application servers are available, PosGreen can be directed to read reference data from internet storage, such as:
- BackBlaze B2 Storage
- FTP servers
- Any webserver that can deliver compressed binary files.
- more...
When PosGreen network mode is configured, you create a definition saying which of the above options you wish to use and what order they apply.
Failure Scenario - Store Internet Down
When the store has no internet connection, then none of the online servers will be reachable. This leaves only Local Database as the option. The store will operate using the most recent copy of the data it has until the internet is restored. The best protection against this scenario is redundant network links into the store.
Failure Scenario - Single Server Down
If the primary server is offline, then PosGreen will hunt for an operational server from it's list of servers.
Failure Scenario - Computer blocked from network
Rarely, a single computer in a store may not be able to use the internet while other computers on the same LAN can. Surprisingly, this really does happen. When this happens the blocked computer can use a combination of local database and piggyback mode. NB This failure mode has not been widely tested and piggyback mode may not be invoked.
Failure Scenario - Local LAN failure
If no computer can communicate on the LAN, each computer will switch to local database mode and use the last good copy of data it received.
When failure is detected, the transistion to alternative hosts should be seamless to the user, although brief hangs may be observed as various network timers expire.
Data Security
When PosGreen network requires site specific encryption files. Once connected, all communication is encrypted at both the request/response body and the URL. This encrypted message is then sent over SSL as well if enabled.
Here is an example of a real database request sent to a server
GET /OpenApi2_5,9,1,2/Proxya/a2V5IDVlYTMzZTMwMDhmZjU1ZjBjZGE0MmQyMzNmZWQxNzVjO1IyNmFjOGNiMztxR2M9*csiLyRo2OMwWNj-5JwH2nEF25P79rKgKGECXVz-rKRyn4vtCyhmzZvFhoceY
This request URL is encrypted using a site specific key that changes periodically. Specifically the site specific initial key uses key derivation to generate a current key that is used to encrypt both the request and response.
As the request and response are both encrypted, the server can, if permitted, mark some responses as cacheable for a period of time. (eg, "public, maxage=N") which means that requests might be resolved from a CDN for a larger retailer.
PosGreen network is typically communicating to the main database controlling your entire retail operation. This means that it technically has access to all data, including all historical data. While users are restricted by the application, you might like to use a transactional subset database and hide the main accounting database from lanes. A subset database contains only the superset of all data a lane could potentially need, such as products, active accounts, sales history for up to 2 years.
Performance
Achieved performance depends on confgiuration and data encryption in use.
- Most read queries can be satisfied from the local database
- Queries to remote servers can use CDN style caching to share responses over multiple lanes. A common query is "list product with plucode starting with A", and if CDN caching is enabled, the first user of the day goes to the server, and subsequent users are then resolved from cache.