src/sitespecificfolder contains materials specific to your site. You can use the environment variable
ARCHAPPL_SITEIDto control which set of sitespecific files are included in the generated WARS.
archappl_vx.x.x.tar.gzavailable in the Downloads is also built to the
src/sitespecific/YourSite/classpathfilesare added to the
WEB-INF/classesof the generated WAR files and should be accessible in the code using
ARCHAPPL_POLICIESenvironment variable, the
policies.pyfor your site is discovered this way
policies.pyspecific to your site by setting the
policies.pywith your own during deployment.
ARCHAPPL_APPLIANCESenvironment variable, the
appliances.xmlis discovered in a similar fashion.
archappl.propertiesthat is discovered in a similar fashion. The properties in this file are used to control some of the other customizations of the archiver appliance.
[ epicsarchiverap ]$ ls -ltr src/sitespecific/ total 0 drwxr-xr-x 3 mshankar cd 28 Jun 21 10:40 tests drwxr-xr-x 3 mshankar cd 45 Sep 9 16:03 slacdev [ epicsarchiverap ]$ export ARCHAPPL_SITEID=slacdev [ epicsarchiverap ]$ ant Buildfile: /workspace/epicsarchiverap/build.xml [echo] Building the archiver appliance for the site slacdev
src/sitespecificis called (if it exists) after the compile and staging tasks and before the WAR is packed. This lets you replace default collateral (like images, phone numbers in messages etc) with your own collateral in the generated WAR file(s).
As outlined in the details page, the archiver appliance support a wide variety of configurations.
Not only that, we also support configuration on a per PV basis.
We avoid exposing all of this complexity to the end user (the one who is requesting PVs to be archived) by using policies to provide intelligent defaults.
Policies are contained in a python/jython script called
policies.py that is typically located in the
WEB-INF/classes of the
mgmt webapp or by using the environment variable
.RTYPetc are also determined. All of these parameters are passed to the
policies.pypython script as a dictionary argument to a method in
determinePolicy; see the javadoc for more details. This method is expected to use all of this information to make decisions on various archiving parameters including storage locations, storage technologies used etc and return these decisions as another dictionary. For example, the resulting dictionary contains a field called
dataStoreswhich is an array of StoragePlugin URL's that can be parsed by the StoragePluginURLParser. This is converted into a sequence of StoragePlugin's that is used like so
Optionally, as part of a policy, we can also archive fields in addition to the VAL field.
That is, one can establish a blanket policy that says something like For all
ai's, in addition to the
.VAL field, also archive the
.HIHI, .LOLO etc
These fields are stored as part of the data for .VAL field.
src/sitespecific/tests/policies.pythat is shipped as part of the
testssite. In addition to the
determinePolicymethod, there are a few more methods that need to be defined. These include
getPolicyList-- This returns a list of available policy names.
getFieldsArchivedAsPartOfStream-- This returns a list of fields that are to be archived as part of the stream.
archappl.propertiesthat is typically present in
WEB-INF/classesof all the webapps or as the environment variable
ARCHAPPL_PROPERTIES_FILENAME. This contains various configuration elements that are common to all machines in the cluster and probably common to all deployments of the archiver appliance in your infrastructure. One of the advantages of having your site specific properties checked into the source repository is that as the system evolves and we add new configuration elements, default values for these new configuration elements can be added to
archappl.propertiesof all the sites. The configuration elements present here are configuration decisions that are made during the initial scoping of your archiving project; so, please do look at these configuration elements and make choices appropriate to your installation.
For example, using the default key mapping strategy, data for the PV
EIOC:LI30:MP01:HEARTBEAT for the timeframe
2012-08-24T16:xx:xx.xxxZ on an hourly partition is stored under the key
Data for the same PV in a daily partition is stored under the key
EIOC/LI30/MP01/HEARTBEAT:2012_08_24.pb for the day
To use the default key mapping strategy, it is important (for performance reasons) that the PV names follow a good naming convention that distributes the chunks into many folders - see the Javadoc for more details. If the key/file structure reflecting the PV naming convention feature is not important to you, you can choose to use an alternate key mapping strategy by implementing the PVNameToKeyMapping interface and setting this property to name of the implementing class.