Quản lý cấu hình web - part 27 pptx

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 workflow will perform a deployment to those

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

chapter 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 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>

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.

transformers.SampleEncryptionTransformer">

<property name="password">

<value>Alfresco</value>

</property>

<property name="cipherName">

<value>PBEWithMD5AndDES</value>

</property>

</bean>

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 alfresco-global.properties 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 alfresco-global.properties file

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 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"

Auto deployment

Alfresco WCM staging has an autodeploy option in its default workflow, allowing end users, at the time of submit, to enforce automatic deployment of approved

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 workflow 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 Configuring 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 filesystem 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 workflow that performed the deployment Once the user or workflow has finished with

the test server it is released and returned to the pool of test servers This happens automatically in the case of a workflow sandbox and manually via a UI action for

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 configure 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 Configure Deployment Servers window.

4 Click on the Add Deployment Receiver link as shown in the

following screenshot:

5 For Type, select Test Server, specify the Display Name, Host name, and the

Target Name Click on the Add button.

Similarly configure 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 configured 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:

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 configuration settings

Release the test server

Once a test server has been deployed to, it is allocated to the user or workflow 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 field 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:

Test servers allocated to review sandboxes are automatically released by the system upon completion of the workflow Once the user or workflow has finished with the test server, it is released and returned to the pool of test servers

Deploying from workflow

When you have a test server configured, you can deploy the content to that test server from the workflow 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 workflow review sandboxes are

automatically released by the system upon completion of the workflow: