This page provides an overview of how to configure a Deployment Receiver Engine for use with deployment targets. This configuration does not depend on the transport protocol (HTTP, RMI), the type of target (AVM, DM, filesystem), or the environment in which the Deployment Receiver Engine runs (stand alone deployment receiver, Alfresco instance). Configuration parameters are grouped by the likelihood that the parameter will need to be adjusted and the means by which the parameter is adjusted.
This is not a complete configuration of a receiver: it lacks a transport protocol and targets. This page illustrates only how to configure the receiver engine. The configuration objectives addressed on this page are:
Configuration of the constant (or unlikely to change) parameters.
Configuration of parameters which may be set in a property file.
Articulate the common options for parameters which must be set with XML configuration.
Configuration Parameter Triage
In this section, all Deployment Receiver Engine parameters are classified into one of three groups: effectively constant, configurable via a setting in a property file, and configurable only via xml.
Property file configuration
authenticator (currently, only two options)
transformers (currently, this may have zero, one, or two transformers; and the order of the list may make a difference)
Effectively Constant Parameters
Most of the effectively constant parameters involve setting the property to an instance of a bean which performs some necessary support function. This effectively initializes the engine. Some of these utility beans may be required elsewhere, so this configuration instantiates them with an id so that other beans may refer to them in other configuration files. The following table lists the bean id and class associated with each of these utility properties.
One final note: there is another housekeeper implementation available which applies only to file system deployment targets. However, this housekeeper is not configured on either the stand alone receiver or the alfresco instance. (See fileSystemReceiverHousekeeper) It also requires knowledge of the File System Receiver Service (if this engine has File System Deployment Targets), so it cannot be configured here. Although this configuration ignores this housekeeper, your situation may call for its use.
One effectively constant parameter (daemonThread) is a flag indicating whether or not the deploymentReceiverEngine requires a 'keep alive thread'. This must be true if the engine is running within Alfresco and false if it is running in a stand alone receiver. The default value is false. This parameter is considered effectively constant because it only depends on where the engine is running.
Property File Parameters
The pollDelay parameter is a number representing the inverval between successive calls to the housekeepers, and is set by the deployment.pollDelay property.
XML Configuration Parameters
The configuration items in this section have 'options'. However, to make a choice requires that the xml files be changed to reflect that choice. The available options (i.e. options which are included with Alfresco) are described here.
This property refers to a single Deployment Receiver Authenticator, of which there are two implementations packaged with Alfresco: a simple 'single username/password' version which works regardless of environment, and a full alfresco authenticator version, which works only if the deployment engine is running within an Alfresco instance. Conceptual details concerning the implementations included with Alfresco are available here.
There are only two choices for authentication, and it is an either-or choice: no combinations are possible. A configuration goal is to export an authentication bean with the id of targetAuthenticator, so that each individual target can use it.
Because there are only two choices, both will be included in the configuration file, with one commented out. The simple username and password mechanism will be the default, configured with user 'USERNAME' and password 'PASSWORD', to encourage administrators to customize these values. The xml file will be written such that only one of the options can be uncommented. To choose the Alfresco authentication method, comment out the 'simple' method and uncomment the 'alfresco' method.
Making the choice about authentication in this file allows the choice to be used with all the deployment targets.
Zero or more Deployment Transport Input Filters may be applied to the received data before the deployment receiver engine uses it. This is only valuable if the authoring server has applied content transformers to the data prior to sending it. The transformers property is a list, and the input filters are applied in the order specified in the list. Successful configuration requires that the input filters on the deployment engine be applied in the reverse order that the output filters were applied on the authoring server. For instance, if the authoring server encrypted the data, then compressed it, the deployment engine must uncompress the data, then decrypt it.
The two input filters supplied with Alfresco are really meant to be examples (as explained on the input filter page), but they are usable as-is. This configuration includes both filters. If they are not desired, remove them from the list.
The value of the transformers list configures all interaction with the deployment receiver, meaning all deployment targets inherit this behavior.
See alfresco/WEB-INF/classes/alfresco/subsystems/wcm_deployment_receiver/default/deployment-receiver-context.xml in the tomcat webapps directory after alfresco.war has been exploded. This contains the default configuration of the Deployment Receiver Engine within an Alfresco instance.