(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 |
| Personalization | Limited | Unlimited |
| Performance | Ultimate | 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 http://sourceforge.net/projects/alfresco/files/, 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 (alfresco-community-deployment-3.3.zip) 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 deployment.properties, which contains the configuration information. The folder deployment includes default target information. To configure the filesystem receiver, open the deployment.properties file in the text editor of your choice. Choose locations for each of the following:
; filesystem receiver configuration
deployment.filesystem.datadir=D:/07_MUN_WORK/alfresco_book_wcm_32e/
deployment-data/depdata
deployment.filesystem.logdir=D:/07_MUN_WORK/alfresco_book_wcm_32e/
deployment-data/deplog
deployment.filesystem.metadatadir=D:/07_MUN_WORK/alfresco_book_
wcm_32e/deployment-data/depmetadata
deployment.filesystem.autofix=true
deployment.filesystem.errorOnOverwrite=false
; Deployment Engine configuration
deployment.rmi.port=44100
deployment.rmi.service.port=44101
; Stand alone deployment server specific properties
deployment.user=admin
deployment.password=admin
- 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:dir1dir2>
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.properties.
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
- Definition of your target information in the deployment.properties file.
- 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 deployment.properties 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.
filesystem.metadatadir}/cignex-live1
deployment.filesystem.cignex-live1.rootdir=
D:/07_MUN_WORK/alfresco_book_wcm_32e/deployment-data/targets/cignex-
live1
deployment.filesystem.cignex-live1.name=cignex-live1
deployment.filesystem.cignex-live1.user=admin
deployment.filesystem.cignex-live1.password=admin
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.sh(or 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 deploy_stop.sh 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.
- Navigate to Company Home | Web Projects | <web project name>.
- Select Edit Web Project Settings from the Action menu.
- Click on Next to reach the Configure Deployment Servers window.
- 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
Description
Type
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.
Host
The host name of the destination server, can be a name or IP address.
Port
The RMI port to connect to on the destination server.
URL
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.
Password
The password to use to connect to the destination server.
Source Path
The path of the folder to deploy, for example /ROOT/site1.
Excludes
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.
- Click on the Add and Finish buttons to complete the configuration.
