= 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. That is, if a polling record has a code of "XYZ", the computer that it represents must also have a polling record called "XYZ". 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 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 personally 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 !! * / - Folder that represents the polling location * 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. == Commin Logic == * 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 retrieve and delete the file /u/cc/COMPANY/
/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/
/send/lastsend from the other computer. * If lastsend does not exist, do NOT send any files * Read what the latest 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/
/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/
/ 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/
/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/
/send/ on the local computer to /u/cc/COMPANY/
/receive on the remote computer * If any send files were sent, create /u/cc/manpoll.lck file on other 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 is transferred to * Update the value of “Next File Sequence (Receive)” * Place value of “Next File Sequence (Receive)” into /u/cc/COMPANY/
/receive/lastrecv * Process the data distributed to the local polling location * Use the {{{comaad}}}->“Process options” from the local polling location record == Polling programs == * {{{comaad}}} - Adjust the location specific parameters used by commin and the various programs commin calls * {{{pollcont}}} - Adjust global polling settings * {{{commin}}} - Performs all of the polling logic. ie. Send this file, retrieve that file, what files go where, etc. * commpost - A renamed copy of commin. Only processes received data and creates send files. Does NOT send/retrieve data. Used primarily at the store computers. * commbra - A renamed copy of commin. Has limited menus to be used by the store. === 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. 1. {{{logmin}}} reads entries from log.dat and only outputs certain record types into slog.dat. {{{logmin}}} simply acts as a filter. 1. {{{logmin}}} reads entries from slog.dat and only outputs certain record types into rslog.dat. 1. rslog.dat is sent to the other location 1. On the other computer, {{{logmin}}} reads certain entries from rslog.dat and outputs it to slog.dat 1. On the other computer, {{{XXaad}}} processes slog.dat and applies changes. ==== NB: To poll GL record changes, the receiving computer will need to set the pollcont option "Create GL codes via polling" to Y. Currently, blank defaults to N. ==== === Control Records === Similar to file maintenance records. 1. {{{XXcont}}} creates entry(s) in log.dat 1. {{{logmin}}} reads entries from log.dat and only outputs certain record types into slog.dat. {{{logmin}}} simply acts as a filter. 1. {{{logmin}}} reads entries from slog.dat and only outputs certain record types into rslog.dat. 1. rslog.dat is sent to the other location 1. On the other computer, {{{logmin}}} reads certain entries from rslog.dat and outputs it to slog.dat 1. On the other computer, {{{XXcont}}} processes slog.dat and applies changes. '''NB.''' Since the programs {{{sscont}}} and {{{stcont}}} use the record type, polling out {{{sscont}}} options will also poll out {{{stcont}}} options as well. Other cont programs will also have similar behaviour. === Transactions === 1. {{{XXeat}}} creates an entry in daytrn.dat 1. {{{sen2post}}} copies the entries from daytrn.dat, adds a bit of extra information and outputs it to sendtrn.dat 1. {{{sendpost}}} reads sendtrn.dat and outputs certain transactions to rsndtrn.dat 1. rsndtrn.dat is sent to other computer 1. On other computer, {{{sendpost}}} reads in rsndtrn.dat, filters transactions and outputs to sendtrn.dat 1. On other computer, {{{reclstr}}} converts sendtrn.dat to daycomm.dat, which just structurally the same as daytrn.dat 1. 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 1. {{{logmin}}} reads entries from log.dat and only outputs certain record types into slog.dat. {{{logmin}}} simply acts as a filter. 1. {{{logmin}}} reads entries from slog.dat and only outputs certain record types into rslog.dat. 1. rslog.dat is sent to the other location 1. On the other end, {{{logmin}}} reads certain entries from slog.dat and outputs it to another file 1. On the other end, {{{oqdel}}} (which is sieat, but renamed/symlink-ed) deletes the completed/deleted quotes and customer orders from tran.dat 1. On the other end, {{{podel}}} (which is steat, but renamed/symlink-ed) deletes the completed purchase orders from tran.dat === Debtor Balances === ==== NB: Stores do not always get list of all transactions. Therefore a debtor's balance may not match their movements. ==== 1. {{{sdbrep}}} reads entries from debtr.dat and dumps closing balance into debbal.dat 1. debbal.dat is sent to the other computer 1. On the other computer, {{{rdbmin}}} reads in debbal.dat and updates the closing balances for debtors === Stock Counts === ==== NB: Stock counts are usually sent from the store computer to HO. ==== 1. {{{spost}}} or {{{stpost}}} places updated stock counts into stcount.dat in accordance to the option in {{{pollcont}}} 1. {{{sscrep}}} reads in stcount.dat, filters the stock counts and outputs to rstcount.dat 1. rstcount.dat is sent to the other computer 1. 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 1. {{{stendmin}}} reads daytend.dat, performs some record pointer conversions and outputs to sendtend.dat 1. {{{stendmin}}} reads sendtend.dat, filters the tenders and outputs to rsendtend.dat 1. rsendtend.dat is sent to the other computer 1. On the other computer, {{{stendmin}}} reads rsendtend.dat, filters the tenders and outputs to sendtend.dat 1. On the other computer, {{{stendmin}}} reads in sendtend.dat and updates tender.dat == Polling Scripts == * Polling * Checks for a file called /u/cc/polling.lck. * If present, check if process that created the file is still running * If file is present and process is still running, EXIT * If file is present and process is no longer running, delete file and continue * Create file called /u/cc/polling.lck. It will contain the process ID of this script * Run {{{combra}}}->"Polling with Head Office" * Delete /u/cc/polling.lck * Search for old polling send files and delete them * Designed to be run at the store * Pollpost * A renamed copy of polling * Runs {{{commpost}}} instead of {{{combra}}} * Pollho * A renamed copy of polling * Runs {{{commin}}}->"Polling with all branches" * Usually launched by cron at HO * Pollbr * A renamed copy of polling * Runs {{{combra}}}->"Polling with Head Office", but with the store actively sending/retrieving send-files to/from HO * Not normally used * Designed to be launched by cron at the store * Manual_poll * Checks for /u/cc/manpoll.lck * If present, run {{{commpost}}} and delete /u/cc/manpoll.lck * Sleep for 60 seconds * Designed to be run by init at the store * Allows the store to check if any new data arrived from HO and process it within the minute == Diagnosing polling issues: == === How to check if polling has stopped. === Our generic procedure for testing if polling is to run: {{{ starep choose option 1 then 3 tick multiple locations, show locations department length 0 tick department totals only }}} If you run this on both sides, you should see which direction has potentially stopped. Another way is to check is to look at the $CCDIR/// send or receive directory. If there are numerous zip files there then it means polling has stopped. === What to do if polling has stopped. === First thing to check if polling has stopped is to check if there is network connectivity. Try to ping the IP stored in comaad under "modem no, wan path, address". If the remote address is accesible, ---- . CategoryPolling