Content Delivery and Deployment [ 242 ] Deploying to multiple servers On a specic receiving server (FSR), you can congure 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 congure FSR on multiple servers. To congure multiple deployment receivers, follow the instructions given in this chapter in the Conguring a web project to use FSR section. In the Add Deployment Receiver form, use the Source Path eld to specify a folder for the web project to be deployed. Also use the Excludes eld to exclude certain types of les to be deployed. Advanced topics on FSR This section covers a few advanced features that are useful to extend the File System Receiver. Conguring 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 les 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 les are successfully copied to the target location. Download from Wow! eBook <www.wowebook.com> Chapter 7 [ 243 ] 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 lesystem • Integrating with a third-party system, such as updating a database upon receipt of certain les • Copying les to an external lesystem via FTP • Sending e-mail notication upon failure or success of deployment Refer to the deployment/file-system-target-sample.xml le, which includes prepare and postCommit blocks listed as folows: <! Add your prepare callbacks here > <property name="prepare"> <list> <bean class="org.alfresco.deployment.SampleRunnable" /> </list> </property> <! Add your postCommit callbacks here > <property name="postCommit"> <list> <bean class="org.alfresco.deployment.SampleRunnable" /> </list> </property> Dening 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 dened in the conguration le deployment-service-context.xml. On the File System Receiver, transformers are dened in the conguration le 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 Download from Wow! eBook <www.wowebook.com> Content Delivery and Deployment [ 244 ] Here is an extract from deployment-service-context.xml showing the conguration of the encryption transformer, which takes two parameters: <! Payload transformers > <bean id="deploymentEncryptor" class="org.alfresco.deployment. transformers.SampleEncryptionTransformer"> <property name="password"> <value>Alfresco</value> </property> <property name="cipherName"> <value>PBEWithMD5AndDES</value> </property> </bean> Dening transport adapters The Alfresco deployment service supports the conguration of multiple transport adapters to enable connection to remote lesystem receivers using different network protocols (that is, encrypted RMI). Transport adapters are congured on the Alfresco Staging Server in the Spring conguration le 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: Download from Wow! eBook <www.wowebook.com> Chapter 7 [ 245 ] 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 exibility 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 conguration. 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. Conguring WCM deployment service You can congure the WCM deployment service by editing the settings in the <tomcatHome>/shared/classes/extension/deployment-service-context.xml le. Download from Wow! eBook <www.wowebook.com> Content Delivery and Deployment [ 246 ] Number of send threads To assist with cases where les are being deployed over a network with high latency, the deployment client is multi-threaded and sends several les at once. By default, ve sends are done in parallel. From 3.2 Enterprise onwards you can set the deployment.service. numberOfSendingThreads property in the alfresco-global.properties le. 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 alfresco- global.properties le. deployment.service.corePoolSize=2 deployment.service.maximumPoolSize=3 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 ne 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' prex. 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". Auto deployment Alfresco WCM staging has an autodeploy option in its default workow, allowing end users, at the time of submit, to enforce automatic deployment of approved changes directly to the live website without having to manually initiate deployment. Download from Wow! eBook <www.wowebook.com> Chapter 7 [ 247 ] The Submit Items window has an Auto Deploy checkbox, as shown in the following screenshot: Upon approval, if the auto deploy option is on, the workow will perform a deployment to those live servers that have the Include In Auto Deploy option enabled. For more details about enabling this option, refer the Conguring a web project to use FSR section in this chapter. Deploying to a test server The Test Server Deployment functionality provides in-context preview by allowing a contributor to deploy their content to an external target (either an ASR or FSR), from which it can be rendered by any web application technology that can either read from a lesystem or access an ASR via HTTP (which includes all of the major web application technologies in use today, including Java, .NET, PHP, Ruby, Python, CGI, and so on). Once a test server has been deployed to, it is allocated to the user or workow that performed the deployment. Once the user or workow has nished with the test server it is released and returned to the pool of test servers. This happens automatically in the case of a workow sandbox and manually via a UI action for User Sandboxes. Download from Wow! eBook <www.wowebook.com> Content Delivery and Deployment [ 248 ] The following process has to be followed to use the test server: 1. Set up a test server pool. 2. Deploy to a test server. 3. Preview the content. 4. Release the test server. Setting up a test server pool The following are the steps to congure a Web Project to use an FSR. 1. Navigate to Company Home | Web Projects | <web project name>. 2. Select the Edit Web Project Settings from the Action menu. 3. Click on Next to reach the Congure Deployment Servers window. 4. Click on the Add Deployment Receiver link as shown in the following screenshot: Download from Wow! eBook <www.wowebook.com> Chapter 7 [ 249 ] 5. For Type, select Test Server, specify the Display Name, Host name, and the Target Name. Click on the Add button. Similarly congure another test server, say with "cignex-test2" as the target. Ensure that the FSR is running on the test server. The targets "cignex-test1" and "cignex-test2" are congured in FSR. Deploy to a test server Let's say, you as a content manager would like to deploy your User Sandbox to the test server for testing purposes. Go to your User Sandbox and from the More Actions menu choose Deploy as shown in the following screenshot: The Deploy Sandbox window displays, listing all of the unallocated test servers as shown in the next screenshot. Select a test server to use (only one test server can be allocated to a sandbox at a time), and click on OK. The Monitor Deployment information displays once the deployment completes. If an error occurs, the reason for the error is shown under the Deployment Failed message: Download from Wow! eBook <www.wowebook.com> Content Delivery and Deployment [ 250 ] Preview the content You can preview the content deployed on the test server either using Apache or application servers such as Tomcat or PHP, as per your FSR conguration settings. Release the test server Once a test server has been deployed to, it is allocated to the user or workow that performed the "Deploy". The administrator or content manager can see what test server is allocated to which sandbox by going to the Edit Web Project Wizard and viewing the Allocated eld. Hovering over the Yes label will reveal the actual store name as a tooltip. Test servers allocated to User Sandboxes can be released by the owner of the sandbox, the administrator, or the content manager. The Release Server option is available in the More Actions menu as shown in the following screenshot. A user can also view the deployment history by clicking on the View Deployments option available in the More Actions menu: Download from Wow! eBook <www.wowebook.com> Chapter 7 [ 251 ] Test servers allocated to review sandboxes are automatically released by the system upon completion of the workow. Once the user or workow has nished with the test server, it is released and returned to the pool of test servers. Deploying from workow When you have a test server congured, you can deploy the content to that test server from the workow process, similar to the way you deployed it from User's Sandbox. Refer to the following screenshot. You don't have to explicitly release the test server. Test servers allocated to the workow review sandboxes are automatically released by the system upon completion of the workow: Download from Wow! eBook <www.wowebook.com> . les to an external lesystem via FTP • Sending e-mail notication upon failure or success of deployment Refer to the deployment/file-system-target-sample.xml le, which includes prepare and postCommit. following are the steps to congure a Web Project to use an FSR. 1. Navigate to Company Home | Web Projects | < ;web project name>. 2. Select the Edit Web Project Settings from the Action. dened in the conguration le deployment-service-context.xml. On the File System Receiver, transformers are dened in the conguration le application-context.xml. Following are a few use cases