Different Geographic Locations

ASherbuck

Registered User.
Local time
Today, 15:29
Joined
Feb 25, 2008
Messages
194
Something that I've always wondered about are the ways to sync up locations outside of the home office.

I assume in the retail industry a point of sale system is setup at each location with their own backend. At some point, (Daily, weekly, Monthly) those stores sync up with the home office where are database is housed with the most recent data entry concerning new products, prices, etc. I assume these systems are complex, but I am wondering what the basic gist, or standard is within the industry (If one exists?)

A store completes sales, returns, exchanges and stores it within their backend, at the set time interval it sends the information to a central location and recieves the new data. Is this done through a VPN, a leased line, FTP, a combination, or is the sky the limit?

I would think VPN would be too slow, a leased line would be too expensive, FTP a bit hokey and around-a-bought so what is this solution or what would options be?
 
I'm sorry but I don't know what are the 'standard' and I'd venture to guess that standards may differ between different classes of applications. Some may be content to send data at a set interval but other may demand real-time updates/inserts. So that will also depend on what your objectives are.

Likewise, they usually use what is available to them; ethernet cables, T1 lines, satelites. This is not always in control (e.g. not all services are available in all area, so we may have to adopt different method of delivery). However, we can control what protocol we want to use, be it VPN, FTP, SSL, and so forth.

Now, VPN is more useful for interactive session- something like user actually browsing a directory. For a data entry application, it would be overkill and thus expensive than if a simple TCP/IP connection was used.

In my case, I had considered three options; replication, terminal server and direct connection. Given the available resources I had, I ruled out the first two because they both were expensive and I only had a relatively old server hardware and did not want to tax it with extra overhread. Thus I decided to use TCP/IP with SSH connection.

The solution was quite simple, robust and I found the performance to be fast and I've not even yet optimized the application!

I hope that helped...
 
A few years ago I was the project lead for a national company that franchised its stores out accross the UK. About 56 at the time. Each store had the EPOS system in and at the end of each day each store created extract files in txt format. Transactions, Stock Levels. I point out at this juncture that we were not responsible for the EPOS system. these two files were then zipped up into one file and given the store code as the fiel name.

Each store a specific transfer time and during the night each stores data was electronically despatched via FTP / ISDN to the Head office server via 5 remote raid boxes.

Then each morning these files were automatcially unzipped and appended to a SQL server database. This was so the head office could monitor what was going on at each outlet. Mainly for stock distriblution.

If you imagine that each store had approx 500 sales tranactions a day, then six day a week, 52 weeks ayear and there were 56 stores. This works out to 8.7m records a year and they wanted to retain three years data for comparison on the server. All because they wanted to know how many videos did Kilcaldy sell last Wednesday.

This was a ball ache of a system to write but it worked.

CodeMaster::cool:
 
Hey thanks for the Answers, I appreciate it.

Sounds hefty and impressive.

The Text File and FTP was actually something I was thinking about for a solution for small business situations, as it's not really that expensive.

Thanks again.
 

Users who are viewing this thread

Back
Top Bottom