Accounting Tables
UsageRecords are stored in database tables. It is possible to have multiple tables of UsageRecords. This allows different types of accounting data to be held in the same system (for example data from different types of batch system). It also allows system administrators to organise the data into different tables, for example keeping current and historical data in different tables or keeping data from different machines in different tables. Report generation can automatically combine data from a set of multiple tables. The sets of tables (called a UsageProducer) need to be defined as Java properties: e.g.
[set-name].tables=table1,table2.....
By default report generation will use a set of tables called accounting so the accounting.tables property needs to be defined.
The producer_info.jsp page will generate a table describing all the properties supported by a set of tables and how these properties map onto the underlying database. By default this page shows information for the default accounting set but other sets can be viewed by adding the producer parameter to the page url e.g. producer_info.jsp?producer=test.
There is a administration web form which can be used to create new accounting tables, but this can also be done by setting the following configuration parameters.
Every accounting table requires a handler class (defined using the class.table-name property). The default handler class for Accounting Tables is ConfigUsageRecordFactory. This class requires a number of additional Java properties
- class.parser.[table-name] defines the AccountingParser class
- policices.[table-name] defines a comma seperated list of AccountingPolicy classes.
- unique-properties.[table-name] is a list property names that can be used to uniquely identify a record.
The AccountingParser and AccountingPolicy objects are used to parse the raw accounting data and populate the database tables. Together with the table schema they also control which AccountingProperty values are available from the table. The unique properties list is only used when uploading accounting data. For each uploaded record the system will look for an existing record with the same set of unique properties. If such a record already exists then the uploaded record is assumed to be a duplicate and is not stored in the database.
To make it easier to implement "rolled" tables (where old accounting data copied to separate database tables) if the parameter config.table-name is set this is taken as the name of a master table and the policy and parser configuration uses the configuration parameters of the master table. The class.table-name property is still required however.
