Just wondered is anyone had done anything for multi site customer/loyalty database.
With the new second property we would like to also do a local/loyalty setup but would be nice to keep both places and future places running in sync.
Not worried about a multi site system as they are on the whole indipendednt sites but would be nice to sync the loyalty side over the sites.
Am looking at it as two posible methods;
Shared cloud database accessed on request using RFID numbers - probably simpler solution given its just a if list and do not need accounts etc.
Synced customer/loyalty card setup - either using one site as master list or synced via a seperate database as above - advantage being not internet dependent, disadvantage being potential for duplicates if new entries entered locally and synced periodically.
Just wondered if anyone tried before or any thoughts/recommendations?
For multi site I would highly suggest internet have internet connectivity and have a cloud based db to sync . Until we implement a push sync system which causes system to work offline, then once configured and system online it will push all updates of loyalty points to main cloud based system. But that would be making your dB site connection points redirected to the public up address and port for updates
That was my plan
I am thinking of doing something like this for users and loyalty system so staff can move between locations with same RFID key etc.
Staff may be more interesting but loyalty side should be relatively straight forward LOL.
Beeing thinking more about this today and so far my thoughts are;
Create a mini API like I did for my hotspot radius server - I prefer this method as always found the MySQL framework for scripts very cumbersome. That way I can make my API return and accept JSON which I much prefer and am now quite familiar with after the PMS integration.
My plan would be to be less of a sync and more of a ‘share’.
Syncing implies direct copy of a database to me and this is less practical as what happens if new loyalty card is added on both local systems, who gets priority and then your compairing string fields rather than something more precice like a row key value.
On that basis I was thinking to store the ‘cloud key id’ which would be the row id of the cloud database which gives a strong reliable value to base the sync arround.
This would mean that there should not be any conflict as each site will call for a list and upload/update any it doesnt see on the cloud db or visa versa and it will submit its list, cloud will process updates, create new and return a list of amendments/new entities.
My thoughts on the staff would be to do similar using a staff entity which a second script then runs through and check/creates any users which has the option of ‘till access’ as a user.
Till access being as I hope to setup a staff discount system so it would want staff entities for all staff but not users for all.
This DB would be intergrated with wheatever HR system I end up choosing (timetrex still seems such overkill but havnt put much time in to it yet.
I also contemplated part of this uploading ticket total details for discounted tickets in such a way we can have a centeral report for staff/local loyalty system activity.
(Also maybe even have a sexy loyaty sign up form on the website rather than the printed cards we have at the moment )
This can probably be done with GQL and it would really simplify it. We can already get entities and their info via GQL all we need is a mutation to update Entities. We already have one to Add Entity… so just missing Update Entity.
Perhaps add Entity will work… let me test it.
Update: Ok addEntity wont work to update current Entities. So we need an updateEntity mutation.
Hmmm, my lack of involvement with graph is already making me miss thoughts…
Dam that could indeed really simplify it, both locations having static IPs if the website was treated as the update location for maintaining the loyalty list it could literally push the updates to all sites…
Hell a simple cron could start a daily read and update script from server side, would defiantly simplify.
Hell, even simpler just treat one site (probably the hotel) as the master and do away with the web server… Hmmm well that’s drastically changed the plan lol
The power of samba+ gql I tell ya haha. But much like jtr my involvement is lower than I’d want it to be, as it’s taking me long enough already to get fundamentals of coding down enough as it is. Endless possibilities
Ok, few more thoughts today, would be good to also sync in with my hotspot wifi as this would also want to be synced over locations.
at the minute am moving back towards having web based site as the master and sync either push to samba graph or pull with script, new graph functions obviously still very handy
I spent a fair amount of time setting up a forgot password system for the wifi and it could be better so thinking this could also become part of this new side.
Thinking maybe a joomla website (like joomla) which will then handle registration, password resets etc.
User profile plugin to allow custom user data fields for the additional info for user type (staff/user) staff details etc.
Then a radius plugin to handle the wifi side of things for the wifi.
Like the joomla idea as opens options for other interesting multi site stuff and it also reliability handles the registration, password reset etc.
Not sure if I’m expecting too much intergration…
Is all this sounding justifiable to you guys.
