The Multi Retailer functionality allows multiple different retailer systems to be joined to a single database. A common application is a franchise server controlling franchisees.
Individual Retailers
- On startup, each POS writes to the servers Mesh Queue providing details of how it can be contacted
- If a command arrives from the multi retailer server, it is obeyed. Typically this will be product updates.
- If a product update (or other data) is received, it is stored as an inbound file and passed to SyncHidden to load. These update packets typically contain instructions to only update a slice of products rather than replacing all products
- As sales (etc) are created they are placed in the Servers inbound Queue.\
- Replication verification (eg table checking/alignment) is handled using normal SyncHidden and Peering techniques
Master Server
- A master server defines it's queue address in gds.ctl f151
- Maintains an inbound mesh queue for commands /rma/fri/[f151]
- Maintains an outbound mesh queue for commands /rma/fro/[f151]
- As records are received on /rma/fri these are applied to the database if they pass security/authorisation
- Periodically, table data to be sent to client systems is published to MeshMemory using the same techniques as normal retailers use to replicate their Head Office Servers. eg A call to retailmax.elink.sync.query with "peermesh" parameters.