Multi-Site Synchronisation

EaseSuite can now be set up multi-site, meaning different physical locations are possible with data synchronised between each. We generally synchronise all sites every hour. One site is deemed as a primary site, which pulls in the data from all others before pushing it out to all others, meaning every site gets each others data (though user and building security can block off isolate areas so that site might not necessarily see it). Each site is set up as a separate building in the system. 

Some things to note with the synchronisation:

• Frequency. Synchronisation will occur every hour between sites, and it only pulls in the changed records since the last synchronisation, so will exchange any new, updated or deleted sales, purchase, jobs etc. This means it is quite fast to run, and the more frequently it is run, the less changes are exchanged.
• It is best to do synchonisation frequently for the following reasons:
  • If a synchonisation fails on one hour, the next might not (resilience through frequency).
  • If internet failure, the site can still progress, and it will resynchronise when up again (resilience through frequency again).
  • With every site carrying the same data, you get a backup and off-site resilience. For recovery, one site's data may be used to rebuild the rest.
  • The frequency ensures less chance of conflict (touched on next).
  • If synchronisation happened once per day, lots of changes would happen, but the window for conflict (described below) is much much wider.
• Conflict. When synchronising, the last updated record wins, no matter what site updates it. When synchronsation is hourly, no matter what changes are made in that hour when it is not-snycing, the last person's change will win. To keep it simple and prevent getting into complex conflict resolution (A/Bing records to pick and choose what is right), the last change will win out by whatever site has changed it. This can have consequence and isolation needs to be considered.
  • This means within the hour changes by different sites on the same record (whether product, sales order or purchase order) you want to largely avoid.
  • Some examples (say shop and office are two different sites):
    • Within an hour, say shop changes a record, office then goes in and changes, then shop changes again. Shop will win (last), and the office change will be complete lost when synchronisation occurs.
    • Often you will get away with it if only one site changes the record in the hour, but you want to thinking about isolation (below) to prevent any chance of this happening.
    • For a product, we hold stock and quantity levels in a different table from the core (cataloguing) details, so it can be OK for the core product to be updated by the office whilst the shop carries on making stock level changes, which is usually inadvertently through sales and purchase deliveries being received (and on purpose through stock taking). Note some details might get lost on the core product, like the last purchase or sale date, because these are at core level and an office update may overrule shop activity (save an earlier date). Depending on how important you consider these to be, it may not be an issue, and they will be recalculated later.
    • Quantity is the most important to keep correct and generally office would never want to update a quantity while shop activity is going on or it can quite easily throw things out or not stick due to other shop activity quickly superseding it within the non-sync window. So it is recommend all stock changes happen at the most prevalent location (Shop) where sales and purchases are happening (stock is listed in a tab of product with quantity).
• Isolation
  • Sales/purchase recommendations. In the example of shop and office for sales, purchase orders, jobs or hires, then you generally want the shop to start it and put it to Sent status when they're done with it. Office then knows to only pick up Sent to say progress for invoicing and to Complete, and importantly Shop knows not to change after Sent and Office knows not to change when only in Started. Isolating record activity like this per status per site prevents the possibility of synchronisation colliding with last win previously mentioned and for records to progress organically free of the chance of being overwritten by another site. Saved searches and the dashboard will feed employees on different sites to the correct records so they only see what is relevant to further eliminate this risk.
  • Office can of course add their own sales and purchasing and progress them. This will come under their building, and shop will get them too (but generally Shop will only be looking at their building and their orders), so these are isolated per building. That is a good approach as well as status progression. Office can see all buildings, but most other sites like Shop are only concerned with their own building and only see that.
  • Product update recommendations. Say office is responsible for updating core details like pricing, and shop updates photos. This can be best isolated by communicating timeslots to prevent the risk of records being overwritten by last wins. So it could be decided that Shop can only update photos in the morning, then Office can only update core details in the afternoon, so both sites know to keep clear of each other to prevent conflict and loss.
• Updates
  • We send out the application over the internet, but when synchronisation is in play, this changes things a bit.
  • Any site can receive the update, and without synchronisation, the first PC to get the update will also update the database. However, with cross site synchronisation enabled, the database changes need to be applied and filter down from the primary synchronisation database server through synchronisation before the application can be accessed on a non-primary site. So if Office is the primary site, they will update first, the main database gets updated, a synchronisation has to happen to for those database changes to reach other sites, and only after that can those sites re-access the system. Those sites can update the software, but they are blocked from getting into the system until their local database has been updated through synchronisation. This will make updates a bit more timely to happen and has greater complexity, but a path is in place to make it still work.
  • Another reason all sites get all data, is that if we have to deliver database data corrections or changes through updates, then the primary database gets the update, and that data flows down to the other sites through synchronisation and they are locked out until that happens (so they can't supersede it) for that reason. The primary database should be re-synchronised before an update for this reason, to gather the data of others, updated applied, send it back.
  • So prior and after update, synchronisation should happen as data is best to be up-to-date everywhere before applying updates.
  • Synchronisation, as well as occuring every hour, can be launched from the server as a Background Task. 
  • We will generally perform this update at the outset but it will be made more automatic.

This hopefully gives you an idea of synchronisation and also the possible pitfalls that can occur, though if managed correctly, issues can be rare or non-existant.