This document is provided “as is” and as such we are not responsible for loss of consciousness or sexual functionality, by engaging in something so blatantly irresponsible as actually reading it. The aforementioned clause is, and any participants therein, or future contributors are, in terms of reference, or attributed, deemed applicable to reference within the bounds of the license, and thereby allowed, within terms of the restrictions of the terms of the license, bound, but not strictly applicable to the concept of the idea, though not relinquishing the right of the individual, and certainly not restrictively set within the bounds of human experience, to fall asleep.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being list their titles, with the Front-Cover Texts being list, and with the Back-Cover Texts being list.
|
Versions, Revisions, Errata |
|||
|---|---|---|---|
|
What |
When |
Who |
Whatever |
|
v0.0.1 |
04/01/04 |
A.K. |
Initial Release. |
|
|
|
|
|
Copyright © 2004 BananaHead.
The DBI interface is probably the most widely used perl database interface around today. The very good reason for this is that DBI is a layer of abstraction providing a common interface to a DBD backend. This allows various databases to be interfaced while keeping the basic front end the same. Originally written by Tim Bunce for Oracle, it has found widespread acceptance due to the many available DBD backends available.
BhPos uses perl to allow some end database implementation independence. The perl scripts provided are intended to be run outside normal working, and cover administrative tasks that either are impractical to run when bhpos is in an operating environment (i.e. plu caching), and/or could take a long time (i.e. stock reconciliation).
In a single site installation these are the only two scripts you will need. When you span sites, more administrative tasks need to added, these include many tasks and depends on the end requirements, at minimum synchronization will be required.
Get the source, and unpack it,
tar -xvzf DBI-1.39.tar.gz
(or the most current version)
After actually reading the README, pseudo configure with:
[al@bhserv DBI-1.39 ]# perl Makefile.PL
And the usual (test is optional)
[al@bhserv DBI-1.39 ]# make test
[al@bhserv DBI-1.39 ]# make
[al@bhserv DBI-1.39 ]# make install
After the DBI installation, the backends can be installed.
Bag DBD-Pg-0.98.tar.gz, unpack and setup a few environmental variables (if not already set):
[al@bhserv DBD-Pg-1.31 ]# export POSTGRES_INCLUDE=/usr/include/postgres
[al@bhserv DBD-Pg-1.31 ]# export POSTGRES_INCLUDE=/usr/lib/postgres
If these were your default postgres installation directories. Then, as before,
[al@bhserv DBD-Pg-1.31 ]# make test
[al@bhserv DBD-Pg-1.31 ]# make
[al@bhserv DBD-Pg-1.31 ]# make install
Bag DBD-MySql-2.9.tar.gz , unpack it, follow instructions as per postgres.
The two most important scripts are the plucacheall.pl and reconcile_stock.pl. These scripts, as you can imagine, generate a plu cache, and reconcile stock respectfully. Both scripts are designed to be run after close of day, the plu caching script generating a new cache for the next day, and the reconcile stock updates the current stock situation based on the days sales.
The database holds synch records that hold information about when an operation last completed. Any script run will run from the time the last script was run. So if a machine is down for some period of time, the script will start its run from the last completed synch entry to the current run time.
The other purpose of the synch entry is to make sure an operation completes. While database transactions can handle most on the “in database” operations, there are some external operations it is not aware of. So when an operation starts it creates a synch entry with Implemented=N and a timestamp of when it started, and when it finishes it set Implemented=Y and records another timestamp of completion.
A fail safe mechanism in the scripts to stop possible corruption of data is that they will not run the given operation if a synch operation is outstanding.
In most cases it is a simple case of removing the synch entry from the db and invoking the script, but some mission critical operations require a little more prudence.
The bhpos scripts tend to bypass the environmental variables as there are several end database options, which will only increase, as more database conversions are completed. Instead all connection/auth parameters are set in the end scripts themselves. The most important of these are set at the beginning of the files involved.
Postgresql
$opt_db = "bananas";
$opt_db_engine = "Pg";
$opt_host = "localhost";
$opt_user = "root";
$opt_password = "bollocks";
MySql
$opt_db = "bananas";
$opt_db_engine = "mysql";
$opt_host = "localhost";
$opt_user = "root";
$opt_password = "bollocks";
The $opt_user and $opt_password should match the database permissions you set up for your system. These permissions need to have both table creation and destruction set (along with insert, delete, and update – but these usually come with db creation). The permissions should also allow the given host connect ability.
The $opt_host should be set to something other than localhost if the scripts will be run from a remote location. This is generally discouraged in multiple server/site environments as it could introduce errors in the synchronization system.
The default install is to /usr/share/bhpos/scripts and they can be invoked at any time by simply running the script. The usual way to run the scripts is to cron the job to some time outside working hours. Whilst a discussion of cron is beyond the scope of this document, a crontab entry along the lines of:
1 0 * * * /usr/share/bhpos/scripts/plucacheall_mysql.pl
or
1 0 * * * /usr/share/bhpos/scripts/plucacheall_pgsql.pl
will run the plu caching script 1 minute after midnight. BhPos provides some example crontab entries, which you will need to change dependant on your own end installation. It is recommended that a separate crontab is created for your own needs (default is /usr/share/bhpos/schedule/<period>), and these tabs are added to the cron configuration. The default install does all this, and using the defaults will allow you to edit the scheduling of these jobs via the BhMIS system.
BhMIS Scheduling Interface
<add more here>