Added two new behavioural configuration parameters:
- Amended code to allow input parameters to be set to the empty string without triggering an exception.
- Updated ftp upload script from https://github.com/statsbiblioteket/larm-doms-exporter/pull/1 .
Bugfix release. The config parameters controlling the initial export have been simplified and the documentation improved. There is now also a parameter to limit the number of exported files per run. For documentation, see the included file lde.behaviour.properties or the github version at https://github.com/statsbiblioteket/larm-doms-exporter/blob/47e2ef5e9be8e61b6a39cca389f107e6ddef1e7b/src/main/config/lde.behaviour.properties .
This is the first version actually mature enough to be a release candidate.
In this version the behaviour properties file looks like
Both seedTimestamp and earliestExportBroadcastTimestamp should be set values corresponding to 2012-03-01 (as above). inProductionTimestamp should be set to a value corresponding to the date when LDE is first set in production.
The other configuration files are as described below for version 1.0. The properties for the geckon ftp server are available via email from the developer.
There are now three application which should be run in order:
A daily run of each is probably fine.
The larm-doms-exporter (LDE) consists of a pair of command-line applications that generates a collection of xml files for export to the LARM/CHAOS platform. Each xml file represents a radio program in DOMS which has already been transcoded by BTA. LDE maintains its own persistent database to record which programs have been exported with which timestamps. In addition, it reads information from the BTA database. The deployment is structured as follows:
runProducer.sh script is executed to feed the database with new information from the BTA database, and then the
runConsumer.sh script is executed to generate the XML output.
The configuration is relatively straightforward. The two hibernate configuration files contain the credentials for connecting to the two databases. The connection the BTA database may be (and ideally should be) read-only.
The infrastructure configuration file contains credentials for reading from DOMS (read-only) and the location of the output directory.
The only real subtlety is the initialisation parameter
seedTimestamp in the behavioural configuration file. This parameter is interpreted such that any objects in DOMS with a last-updated timestamp prior to this are assumed to be already exported with this timestamp.