Pushing content to a flat filesystem environment is also known as Static Deployment and it is achieved using Alfresco File System Receiver FSR.. Pushing content to another runtime instan
Trang 1Pushing content to a flat 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 Filesystem Alfresco Runtime
Content Search Not supported Supported out of the box
Content Security Not supported Supported out of the box
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
Trang 2FSR 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 flat
filesystem The published flat 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
Trang 3deployment.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:\\dir1\\dir2
Trang 4Configuring 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:
1 Definition of your target information in the deployment.properties 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
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
Trang 5Using 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.
Trang 6The 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.
5 Click on the Add and Finish buttons to complete the configuration.
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>.
Trang 72 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
Trang 8When 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
Trang 9For 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:
Trang 10Reverting 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