Skip to content

Multi Store Architecture

Andy Theuninck edited this page Aug 25, 2016 · 1 revision

This topic is also discussed under HQ Data Model. The intent here is to provide a higher level picture for administrators planning or maintaining a deployment.

HQ

One SQL database instance must be designated HQ. This could be an instance at one of the stores or it could be at a literal separate headquarters building. One webserver instance running Office and using this database is required. This could be two separate servers or a single machine. Finally, one instance of Redis is recommended. This almost certainly does not require a separate server.

All editing of items, members, etc happens via HQ's instance of Office. This means network connectivity between sites is mandatory.

Non-HQ Stores

One webserver instance running Office and using HQ's database is required. This instance is primarily responsible for running scheduled tasks and pushing updates out to its lanes when HQ notifies it that an update is needed. In theory this is a fully functional instance of Office, but in practice using the HQ Office instance that's physically closer to the database will give better performance.

One SQL database instance is recommended. This database should be a copy of HQ's database via MySQL master-slave replication. It should also have one special schema that does not exist on the HQ database. The primary reason for this arrangement is lane performance. While you can configure lanes to interact with the remote HQ database, those operations will be slower than interacting with a database on the same LAN. This is particularly noticeable when the lane uploads data at the end of a transaction. A secondary benefit is it's a very bandwidth efficient way to get offsite copies of your data.

With this setup the non-HQ stores will periodically submit transaction data to the HQ Redis instance. With the default task timings there's approximately a five minute delay before remote store transaction data appears at HQ.

Configuration Considerations

The store configuration in Office has some odd legacy cruft but the important settings are:

  • Description
  • Own Items
    • This effectively means that the entry is an actual retail establishment. If HQ is a separate, non-retail location, it doesn't need to have or maintain its own copy of items
  • Web Services URL
    • This is used for Office instances to communicate with one another. It should be http://hostOrIP/path/to/fannie/ws/.

The store networks are IP ranges in use at each location. Office uses these to change default selections on forms based on where the user is connecting from.

Lane configuration can vary by store but you likely have to abandon the user interfaces and work directly in the parameters table. The UI doesn't really support multiple values for the same setting with different priorities. They stack thusly:

  • A record with store_id=0, lane_id=$THAT_LANE is the highest priority. This setting always applies.
  • A record with store_id=$THAT_STORE, lane_id=0 is the next priority. This setting applies unless a lane-specific value exists.
  • A record with store_id=0, lane_id=0 is the lowest priority. This setting applies if neither of the above exists.

For centralized management it's best to have mostly low priority records with overriding ones added as needed. One current issue is you can't re-use lane numbers across stores without giving up some central configuration management.

Clone this wiki locally
You can’t perform that action at this time.