Polling

Polling allows for the exchange of data between multiple servers.

Each peer is represented by a “polling location”. Usually, the peer is a store computer or the head office computer.

The parameters associated with each polling location is stored in a “polling record” in comaad. These parameters determine how to interact with the other computer, what data to send, what data to receive, etc.

Usually a polling location represents Head Office or one store. As a result, the standard practice is to set the polling record code to the same code as the branch that it represents. While the polling record code does not have to match the branch code, the polling record codes on both servers MUST match.

There are some options that globally affects the way the polling behaves. These are accessed via pollcont. Two important options are “Local Location for Polling” and “Is this site HO/Store?”

The “Local Location for Polling” is the polling record that represents the local server.

Because there are some operational differences between HO and store computers, you will need to specify whether this computer is the HO computer. Valid input values are:

• Y – This computer is a HO computer
• N – This computer is a store computer
• S – This computer acts as a HO computer for some stores, but it also reports to a higher level HO computer. Not sure how well this option works. Have never tried it.

Polling consists of four actions:

• Generate - Creation of polling files from the transaction and file maintenance files
• Process - Reading data from polling files and using them to update the transaction and file maintenance files
• Distribute - Taking data from one polling file and copying it to another polling file. Data is not actually leaving the computer, just copied from one folder to another
• Send/Retrieve - Sending or retrieving files across the LAN/Internet

Topologies

There are three actively used topologies

• Two store topology
  • In this topology, there are only two computers: The store computer and the head office computer.
  • Each computer only has one polling location.
• Hub-and-spoke topology
  • In this topology, the are multiple stores and one head office server.
  • All data is passed to and from the HO server. Data to be transferred from one store to another, must first pass through the HO server.
  • Each of the store computers contains only one polling location
  • The HO server contains a polling location for itself and for each of the stores
• TJM Brisbane topology
  • The store computers perform polling to a different companies in the HO computer
  • The various companies on the HO computer then poll to a consolidated company on the HO computer
  • This allows users at HO to enter data into the consolidated company or into the individual companies
  • Each store computer has one polling location
  • Each of the second tier companies will have three polling locations: one for itself, one for the store and one for the consolidate company
  • The consolidated company will have one polling location to represent itself and one polling location for each of the second tier companies

Folders and files

The folder structure employed by polling:

• /u/cc/COMPANY/ - You should know what this does !!

  • <BR1>/ - Folder that represents the polling location <BR1>

    • send/ - Zip files waiting to be sent to the other computer
      • back/ - Backup copy of the send files sent
      • sendXXX.zip – Zip archives of files to be sent to other computer
      • lastsend – Text file that contains the number of the last send file that was tried to be sent
    • receive/ - Zip files received from the other computer
      • back/ - Backup copy of the send files received
      • stuffed/ - Files that were downloaded, but the zip file was corrupt
      • rsndXXX.zip – Files received from the other computer
      • lastrecv – Text file that contains the number of the last send file that we received.
    • reports/ - Not quite sure what this is used for. Error checking I think.

Polling process

• Check for any send files that have received since the last polling run
  • Unzip the packages
  • Distribute the downloaded data to all polling locations
• Process the data distributed to the local polling location
• Generate polling files that represent the latest changes made on the current host

  • Options used by sen2post, logmin, etc. are specified by comaad->”Process Options” for the local polling location record.

• Distribute the changes to the other polling locations
• For each polling location,

  • Check to see other computer is ready to exchange files via FTP Attempt to retrive and delete the file /u/cc/COMPANY/<BR>/send/allowftp from the other computer

  • If it does not exist, STOP trying to send/receive files to this peer
  • Retrieve the latest files from the store computers

    • Retrieve and delete the file /u/cc/COMPANY/<BR>/send/lastsend from the other computer.

    • If lastsend does not exist, do NOT send any files
    • Read what the lastest send file number is.

    • Look at the value of comaad->”Next File Sequence (Receive)”. It will tell you what the last send file number it process was.

    • Retrieve send files that lie between the values in the previous two steps and place them in /u/cc/COMPANY/<BR>/receive/ on the local computer

  • Send the newly created polling files to the stores (in the form of a ZIP archive)

    • Zip up the files under /u/cc/COMPANY/<BR>/ Call the ZIP file sendXXX, where XXX = the next number in the sequence

    • Increment the Next File Sequence (Send) field in the remote polling record

    • Send the files via FTP Retrieve and delete the file /u/cc/COMPANY/<BR>/receive/lastrecv from the other computer. This will tell us what the last file that the other computer processed was.

    • Look at the value of comaad->”Next File Sequence (Send)”. This will tell us what the last send file we created for location was

    • Send all send files from /u/cc/COMPANY/<BR>/send/ on the local computer to /u/cc/COMPANY/<BR>/receive on the remote computer

• For each polling location,
  • For each newly downloaded send file
    • Unzip the send file
    • Distribute newly downloaded data to all other polling locations

      • Options used for logmin, sendpost, etc. are based on those set in comaad->”Distribute Options” for the remote polling location.

    • This is where data from polling location <BR01> is transferred to <BR02>

    • Update the value of “Next File Sequence (Receive)”

    • Place value of “Next File Sequence (Receive)” into /u/cc/COMPANY/<BR>/receive/lastrecv

• Process the data distributed to the local polling location

  • Use the comaad->“Process options” from the local polling location record

Polling programs

• commin - Performs all of the polling logic. ie. Send this file, retrieve that file, what files go where, etc.

• comaad - Adjust the location specific parameters used by commin and the various programs commin calls

• pollcont - Adjust global polling settings

File Maintenance Records

When a new file maintenance record is added, a copy of the record (along with some extra information) will be placed in the "logfile" (log.dat). When you delete a record, an entry in the logfile will also be created. Altering a file maintenance record will create two entries in log.dat. One will be a snapshot of the record before the change and the other will be a copy of the record after the change.

1. XXaad creates entry(s) in log.dat.

2. logmin reads entries from log.dat and only outputs certain record types into slog.dat. logmin simply acts as a filter.

3. logmin reads entries from slog.dat and only outputs certain record types into rslog.dat.

4. rslog.dat is sent to the other location

5. On the other computer, logmin reads certain entries from rslog.dat and outputs it to slog.dat

6. On the other computer, XXaad processes slog.dat and applies changes.

Transactions

1. XXeat creates an entry in daytrn.dat

2. sen2post copies the entries from daytrn.dat, adds a bit of extra information and outputs it to sendtrn.dat

3. sendpost reads sendtrn.dat and outputs certain transactions to rsndtrn.dat

4. rsndtrn.dat is sent to other computer

5. On other computer, sendpost reads in rsndtrn.dat, filters transactions and outputs to sendtrn.dat

6. On other computer, reclstr converts sendtrn.dat to daycomm.dat, which just structurally the same as daytrn.dat

7. On other computer, XXpost will now add transactions to its transaction history file

Order Deletions and Completions

1. XXeat adds entry in log.dat to denote that a Quote, Customer Order or Purchase Order has been completed

2. logmin reads entries from log.dat and only outputs certain record types into slog.dat. logmin simply acts as a filter.

3. logmin reads entries from slog.dat and only outputs certain record types into rslog.dat.

4. rslog.dat is sent to the other location

5. On the other end, logmin reads certain entries from slog.dat and outputs it to another file

6. On the other end, oqdel (which is sieat, but renamed/symlink-ed) deletes the completed/deleted quotes and customer orders from tran.dat

7. On the other end, podel (which is steat, but renamed/symlink-ed) deletes the completed purchase orders from tran.dat

Debtor Balances

1. sdbrep reads entries from debtr.dat and dumps closing balance into debbal.dat

2. debbal.dat is sent to the other computer

3. On the other computer, rdbmin reads in debbal.dat and updates the closing balances for debtors

Stock Counts

1. spost or stpost places updated stock counts into stcount.dat in accordance to the option in pollcont

2. sscrep reads in stcount.dat, filters the stock counts and outputs to rstcount.dat

3. rstcount.dat is sent to the other computer

4. On the other computer, rscmin reads in stcount.dat and updates the stock counts in the stock file

Tenders

1. XXeat adds entry in daytend.dat

2. stendmin reads daytend.dat, performs some record pointer conversions and outputs to sendtend.dat

3. stendmin reads sendtend.dat, filters the tenders and outputs to rsendtend.dat

4. rsendtend.dat is sent to the other computer

5. On the other computer, stendmin reads rsendtend.dat, filters the tenders and outputs to stendtend.dat

6. On the other computer, stendmin reads in sendtend.dat and updates tender.dat

• CategoryPolling