Content Delivery in Alfresco 3

September 2010


Alfresco 3 Web Content Management

Alfresco 3 Web Content Management

Create an infrastructure to manage all your web content, and deploy it to various external production systems

  • A complete guide to Web Content Creation and Distribution
  • Understand the concepts and advantages of Publishing-style Web CMS
  • Leverage a single installation to manage multiple websites
  • Integrate Alfresco web applications with external systems

Read more about this book

(For more resources on Alfresco 3, see here.)

Introduction to content delivery

Alfresco provides a framework for pushing content from a stage (or authoring) server to live and test servers, as shown in the following figure:

The Alfresco content production environment produces an approved view of a web project called a snapshot. Consider each snapshot as a web project version. Alfresco deployment takes a snapshot and pushes it out to either live or test servers. Consider a sample scenario as shown in the following diagram, where the content from the stage server is deployed to live servers. When snapshot version 2 is deployed to live servers, then the Alfresco deployment engine only copies the files which are either new or modifed and removes the files which are deleted when compared to snapshot version 1. The deployment engine is smart, which affects only few files rather than copying all of the files of a web project. Now that the snapshot version 2 is live (deployed to live servers), the editorial staff may work on a future version 3.

Let's say for some reason there is an issue with snapshot version 2, which is live. You have the option of rolling it back to the previous good version of snapshot version 1. You can roll forward or you can roll back to a specific version of a web project snapshot version. This feature is very powerful even from a legal audit point of view, wherein you have an ability to reproduce the website as of a specific date.

Further, the deployment process may be automated so that it happens automatically when content is approved for publishing.

The deployment framework provides a flexible and highly-configurable system to allow you to tailor the system to your requirements. If the Alfresco-supplied components are not suitable, you can plug in your own authenticators, transport implementations, content transformers, and deployment targets.

Live server vs. Test server

Alfresco WCM enables previewing the content within the stage server environment. After content creation, the Editorial staff may preview web pages to verify the content, as well as the look and feel. Similarly the content reviewers and business owners may preview to review the web pages during the workflow process.

Because of this powerful feature, you may not need a separate test server to preview and approve the content. The stage server itself is used for both authoring and testing the content. Hence, the content is authored and approved on the stage server and then deployed to the live servers directly.

However, there can be a situation where you may need a separate test server. For example, if you are deploying content to another frontend application outside of Alfresco such as a PHP or .NET application, or situations when the virtualization server is not capable of providing the preview. Starting with the version 2.2 release Alfresco introduced the concept of a Test Server.

You deploy the content from a Staging Sandbox to the live server and you deploy content from User Sandbox or from a workflow to the test server.

Static vs. Dynamic delivery model

Within the live or test server environment, you can push out content to a fat filesystem to be served up by Apache or IIS, or you can push your content into another runtime instance of Alfresco.

Pushing content to a fat filesystem environment is also known as Static Deployment and it is achieved using Alfresco File System Receiver (FSR). Pushing content to another runtime instance of Alfresco is also known as Dynamic Deployment and it is achieved using Alfresco Server Receiver (ASR).

In static deployment, the web pages are already rendered (or baked) before deploying. In dynamic deployment, since the content is in the runtime instance of Alfresco, the web pages will be generated (or fried) at runtime. The following is a summary of static and dynamic delivery models:


Static "Bake" Model

Dynamic "Fry" Model

Delivery Technology

Web Servers

Application Servers

Page Compositing

Submission time

Request time

Content deployed to

File System

Alfresco Runtime

Content Search

Not supported

Supported out of the box

Content Security

Not supported

Supported out of the box






Less than the "bake" model

You can consider a hybrid deployment (both static and dynamic) for some business applications. You can define certain static content of the web project such as images, videos, and scripts to be deployed to the filesystem and certain dynamic content such as web pages to be deployed to the Alfresco runtime. This approach gives you good performance as well as personalized and dynamically changing content in a production environment.

FSR for static delivery

A File System Receiver (FSR) will need to be installed and configured on each live or test server to receive published static content from the Alfresco Staging Server.

The FSR is a small, standalone server that receives updates from an Alfresco repository running Web Content Management; content is published to a fat filesystem. The published fat files will typically be served by a web server such as Apache, for static content or an application server such as Tomcat, JBoss, or IIS for web applications (WARs, PHP files, and so on).

FSR requires filesystem access and must run as a user with appropriate rights to the target filesystem. The FSR is a standalone Java Daemon (no Tomcat or other app server required) and it has minimal resource requirements. The FSR supports the invocation of custom Java code and/or programs. Therefore, it can be used to perform additional tasks post-deployment such as search engine indexing, pushing content to a Content Delivery Network (CDN), or replicating content to other systems or repositories.

The destination file server receiver has to be running with its RMI registry port and service port (44100 and 44101 by default) opened.

Installing FSR

If you refer to SourceForge at, you will notice three different downloads of FSR. A Microsoft Windows installer file (Alfresco-DeploymentCommunity-3.3-Setup.exe), a Linux installer file (Alfresco-DeploymentCommunity-3.3-Linux-x86-Install) for automatic installation, and a ZIP file ( for manual installation. I would prefer using the ZIP file and manually installing the standalone deployment receiver. Both Windows and Linux installers have certain limitations as they do not provide configuring various deployment targets. Unzip the deployment ZIP file into a convenient location (it does not make its own directory) on a live or test server. Notice a file named, which contains the configuration information. The folder deployment includes default target information. To configure the filesystem receiver, open the file in the text editor of your choice. Choose locations for each of the following:

; filesystem receiver configuration


; Deployment Engine configuration

; Stand alone deployment server specific properties

  • deployment.filesystem.datadir: This is the location in which the filesystem deployment receiver stores deployed files during a deployment, before committing them to their final locations.
  • deployment.filesystem.logdir: This is the location in which the filesystem deployment receiver stores deployment time log data.
  • deployment.filesystem.metadatadir: This is the location in which the filesystem deployment receiver stores metadata about deployed content.
  • deployment.filesystem.autofix: The file system deployment target can either issue an error upon detecting a problem or automatically fix the problem. The autofix parameter controls whether the File System Deployment Target will attempt to fix the metadata itself or just issue a warning. Set the value to true to fix, or false to not fix.
  • deployment.filesystem.errorOnOverWrite: The file system deployment target can issue an error upon overwriting the files. Set the value to false to overwrite the files, which is needed when updating the existing files.
  • deployment.rmi.port: The port number to use for the RMI registry. Choose this so as not to conflict with any other services. By default, the standalone deployment receiver uses 44100.
  • deployment.rmi.service.port: The port number to use for RMI service. Choose this so as not to conflict with any other services. By default this is 44101.

Note that while specifying the directory locations on Microsoft Windows, either use forward slashes or escape the backslashes. For example, C:/dir1/dir2 or C:\\dir1\\dir2>

Configuring your deployment targets

You can configure as many target filesystem receivers as you need on a single live or test server. By default, a single filesystem receiver is defined with simple configuration via

Deployment targets are placed in the deployment folder with the filename deployment/*target.xml. To define more targets, follow the pattern of deployment/default-target.xml. There are two steps involved

  1. Definition of your target information in the file.
  2. Registration of your target with the deployment engine using an XML file.

Let's create a deployment target for the CIGNEX website and let's name it as cignex-live1 target. As a first step to configure filesystem receiver, open the file in the text editor of your choice and add the cignex-live1 filesystem target configuration as follows:

; cignex-live1 filesystem target configuration
deployment.filesystem.cignex-live1.metadatadir= ${deployment.

Now to register this new target, you need to create a target XML file in the deployment folder. You can refer to an existing target file, default-target.xml, in the deployment folder for more information.

Copy deployment/default-target.xml as the deployment/cignex-live1-target.xml file. Open the deployment/cignex-live1-target.xml file in your text editor of choice and replace the keyword default with the keyword cignex-live1.

With these simple two steps, you have configured a new target named cignex-live1.

Start and stop deployment receiver

To run the receiver, execute deploy_start.bat) as the user on that server. Remember this user will be the owner of the deployed content.

To stop the receiver, execute the or deploy_stop.bat file.

Using FSR from Alfresco WCM staging

Now that the FSR is configured and running, you can use it from Alfresco staging to deploy the content.

Configuring a web project to use FSR

The following are the steps to configure a Web Project to use an FSR.

  1. Navigate to Company Home | Web Projects | <web project name>.
  2. Select Edit Web Project Settings from the Action menu.
  3. Click on Next to reach the Configure Deployment Servers window.
  4. Click on the Add Deployment Receiver link as shown in the following screenshot. Fill out the form as needed. The minimum required fields to be filled out, assuming default settings, are the Host name where the FSR is located and the Target Name.

    The following table contains the description of each of the FSR configuration fields.

    Field Name



    Live Server or Test Server. You deploy the content from Staging Sandbox to the live server. And you deploy the content from User Sandbox or from workflow to the test server.

    Display Name

    A descriptive label for the server, used by the UI.

    Display Group

    The deployment receivers configured using the same Display Group name will be treated as one batch during deployment.

    Transport Name

    Name of the network protocol connection to the remote filesystem receiver. By default it is RMI.


    The host name of the destination server, can be a name or IP address.


    The RMI port to connect to on the destination server.


    The runtime URL of the destination server. Can be used to preview the deployment, upon a successful deployment.

    User Name

    The username to use to connect to the destination server.


    The password to use to connect to the destination server.

    Source Path

    The path of the folder to deploy, for example /ROOT/site1.


    A single regular expression (multiple rules can be defined within the expression) of items to exclude from the deployment, for example .*\.jpg$|.*\.gif$.

    Target Name

    The name of a target to deploy to, configured in the FSR.

    Include in Auto Deployment

    If checked, then this target will be included in auto deployment.

  5. Click on the Add and Finish buttons to complete the configuration.

Read more about this book

(For more resources on Alfresco 3, see here.)

Deploying a snapshot to FSR manually

The following represents the steps required to deploy content to an FSR. Similar steps are used to deploy content to an ASR.

  1. Navigate to Company Home | Web Projects | <web project name>.
  2. Expand Recent Snapshots; it may be required to select the appropriate When value to find a snapshot to deploy.

  3. Deploy content by clicking on the Deploy icon to the right-hand side of the desired snapshot.
  4. Select the server(s) to deploy the snapshot to, on the Deploy Snapshot window. Click on OK. This screen will auto refresh to show the success or failure of a deployment.

When the deployment is successful, you will notice that the files from the Alfresco WCM staging environment are copied to the filesystem of the live server where the target location is specified. The following screenshot shows that the files are copied to the folder configured for the target cignex-live1

Viewing deployment report and history

Alfresco WCM staging environment captures all of the deployment reports and maintains the complete deployment history for audit trail purpose.

In order to view the deployment report and the history, navigate to Company Home | Web Projects | <web project name> and click on the View Deployments link on the right-hand side top corner of the Staging Sandbox window. You will notice the report similar to the one shown in the following screenshot.

For a specific deployment, you can list the files deployed by clicking on the Details link. You can also see reports for all of the deployments done earlier. Click on any Attempt Date listed in the More Deployment Reports window to view the detailed deployment report:

Reverting or rolling back to an older snapshot

Snapshots can be reverted, compared to the previous snapshot, and compared to any snapshot by selecting the appropriate actions icon as shown in the following screenshot:

Let's say for some reason there is an issue with snapshot version 4, which is live. You can revert to a previous and stable snapshot version 3. In order to revert to a specific snapshot, click on the Revert icon and select the targets to revert to.

For the deployment Status, there could be four possible values:

  • IN PROGRESS: Deployment is occurring on one or more servers
  • LIVE: All servers were deployed to successfully
  • PARTIAL FAILURE: Deployment failed on one or more servers
  • FAILED: Deployment failed on all servers

Deploying to multiple servers

On a specific receiving server (FSR), you can configure more than one target. For example, you can deploy images to a doc-root of the Apache web server (say target1) and you can also deploy videos to a streaming server (say target2). Similarly, you can install and configure FSR on multiple servers.

To configure multiple deployment receivers, follow the instructions given in this article in the Configuring a web project to use FSR section.

In the Add Deployment Receiver form, use the Source Path field to specify a folder for the web project to be deployed. Also use the Excludes field to exclude certain types of files to be deployed.

Advanced topics on FSR

This section covers a few advanced features that are useful to extend the File System Receiver.

Configuring prepare and postCommit callbacks

On the target receiving servers, the FSR can be extended by implementing a prepare() or postCommit() callback. The prepare() callback is called after all files have been successfully deployed to the FSR's temporary storage areas before actually copying them to the target location. The postCommit() callback is called after the files are successfully copied to the target location.

These two callbacks allow the developers to implement processing on deployed content through the use of a system command, script, or Java class.

Some examples are:

  • Re-indexing of external search engine for newly added content in the filesystem
  • Integrating with a third-party system, such as updating a database upon receipt of certain files
  • Copying files to an external filesystem via FTP
  • Sending e-mail notification upon failure or success of deployment

Refer to the deployment/file-system-target-sample.xml file, which includes prepare and postCommit blocks listed as follows:

<!-- Add your prepare callbacks here -->
<property name="prepare">
<bean class="org.alfresco.deployment.SampleRunnable" />

<!-- Add your postCommit callbacks here -->
<property name="postCommit">
<bean class="org.alfresco.deployment.SampleRunnable" />

Defining payload transformations

The data that streams out of Alfresco and into the FSR can be transformed by content transformation. On the Alfresco server, content transformers are defined in the configuration file deployment-service-context.xml. On the File System Receiver, transformers are defined in the configuration file application-context.xml.

Following are a few use cases listed for your reference.

  • File compression for slow networks
  • Encryption of sensitive data
  • Transformation of content as it is deployed

Here is an extract from deployment-service-context.xml showing the configuration of the encryption transformer, which takes two parameters:

<!-- Payload transformers -->
<bean id="deploymentEncryptor" class="org.alfresco.deployment.
<property name="password">
<property name="cipherName">

Defining transport adapters

The Alfresco deployment service supports the configuration of multiple transport adapters to enable connection to remote filesystem receivers using different network protocols (that is, encrypted RMI).

Transport adapters are configured on the Alfresco Staging Server in the Spring configuration file deployment-service-context.xml. An instance of the Alfresco server may support many different transports. However, each deployment receiver only exposes a single transport as shown in the following screenshot:

ASR for dynamic delivery

The Alfresco System Receiver (ASR) is just another instance of the Alfresco Server. It is also known as headless Alfresco, as the Web Client UI is not used. Also some features such as CIFS, WebDAV, FTP, and NFS are disabled.

The ASR allows a web project being authored in one Alfresco server instance to be deployed to another separate instance of Alfresco. ASR provides the ability to leverage search, versioning, and dynamic queries (via web scripts) within a live server environment—thereby making the content available for dynamic queries by basically any web technology (PHP, Python, J2EE, ASP .NET, AJAX, Flash, Cold Fusion, and so on). This provides ultimate flexibility in what and how the content is displayed on a page.

From Alfresco 3.2 version onwards ASR is replaced by the client-side WCM Deployment Service and receiver-side AVM Deployment Target.

The WCM deployment service is the staging (sending) side of WCM deployment. The AVM Deployment Target is a target which is registered with the receiving side of deployment. By default its target name is "avm", although of course this can be changed through configuration. The AVM Deployment Target receives a deployment from an Alfresco WCM authoring environment and puts the content into an AVM store where it can be used to support a dynamic website.

Configuring WCM deployment service

You can configure the WCM deployment service by editing the settings in the <tomcatHome>/shared/classes/extension/deployment-service-context.xml file.

Number of send threads

To assist with cases where files are being deployed over a network with high latency, the deployment client is multi-threaded and sends several files at once. By default, five sends are done in parallel.

From 3.2 Enterprise onwards you can set the deployment.service.numberOfSendingThreads property in the file.

Number of deployments in parallel

Deployment is controlled through the Action Service which controls how many deployments happen in parallel. If you need to deploy to many servers, then you may need to increase the number of deployments in parallel. But if you run out of processing power or memory, then you may need to reduce this setting.

From 3.2 Enterprise onwards you can set the following properties in the file.


AVM Deployment Target

The AVM Deployment Target is a target that is registered with the receiving side of deployment. By default its target name is "avm".

The ASR names the live and stores the same as the staging store. This is fine in most cases except for where the ASR is used to deploy to the same machine that has the authoring instance. In this case, the ASR attempts to avoid a circular dependency (or overwriting the source) by appending the destination store name with '-live'.

In order to have consistency between deploying to a local instance and deploying to a remote instance, the AVM deployment target always names live stores with the '-live' prefix. For example, if your web project name is "cignex" (on Staging Server), then on the ASR destination Alfresco server, the name of the web project would be "cignex-live".


In this article we saw that Alfresco provides both static as well as dynamic delivery models. You can configure the Alfresco stage environment to deploy the selective content to external live servers and test servers.

In the next article we will take a look at the deployment feature of Alfresco.

Further resources on this subject:

You've been reading an excerpt of:

Alfresco 3 Web Content Management

Explore Title