my $audit_trail = $ENV{AUDIT_LEVEL} || 0;
####
## LOG ##
Process: daily_upd started at 00:30:00 25 Mar 2000
Data source: /data/input/daily.dat
Data sink: database customer on server DATA_SERVER (using id 'maint')
Input record: D:CUS-00123
Action: Delete
Translation: CUS-00123 = database id 2364
Record 2364 deleted successfully
Input record: U:CUS-00124:Jones & Co| [etc …]
Action: Update
Translation: CUS-00124 = database id 2365
Record 2365 updated successfully
Input record: I:CUS-01000:Magnum Solutions Ltd| [etc …]
Action: Insert
Integrity Check: CUS-01000 does not exist on database
Record 3159 inserted successfully
End of file on data source
1037 records processed (60 ins, 964 upd, 13 del)
Process: daily_upd complete at 00:43:14 25 Mar 2000
####
At different points in the life of a program, different levels of auditing will be appropriate.
While the program is being developed and tested it is common practice to
have a much more detailed audit trail than when it is being used day to day in a production
environment. For this reason, it is often useful to write auditing code that
allows you to generate different levels of output depending on the value of a variable
that defines the audit level. This variable might be read from an environment
variable like this:
my $audit_level = $ENV{AUDIT_LEVEL} || 0;
In this example we set the value of $audit_level from the environment variable
AUDIT_LEVEL. If this level is not set then we default to 0, the minimum level. Later
in the script we can write code like:
print LOG 'Starting processing at ', scalar localtime, "\n"
if $audit_level > 0;
to print audit information to the previously opened file handle, LOG.
Standards for audit trails will typically vary from company to company, but some
things that you might consider auditing are:
start and end times of the process
source and sink parameters (filenames, database connection parameters, etc.)
ID of every record processed
results of each data translation
final count of records processed