Quản lý cấu hình web - part 15 pot

The content will be submitted directly into the Staging server.ZERO Workflow You are required to select a user or group whenever your workflows are processed to deploy content on the sta

5 The content will be submitted directly into the Staging server.

ZERO Workflow

You are required to select a user or group whenever your workflows are processed

to deploy content on the staging server However, if you customize your workflow, the user group selection becomes optional

Let's take the same example that we have used for the Dynamic deployment section.

• Step 1: Add one more task in your model Dynamic Model

dynamicWCMWorkflowModel:

<aspect name="dynamic:assignee">

<associations>

<association name="bpm:assignee">

<source>

<mandatory>false</mandatory>

<many>false</many>

</source>

<target>

<class>cm:person</class>

<mandatory>false</mandatory>

<many>false</many>

</target>

</association>

</associations>

</aspect>

Make the highlighted changes Earlier we have used bpm:assignee; now we are using dynamic:assignee

<type name="dynamic:initializeTask">

<parent>dynamic:startTask</parent>

<properties>

<property name="dynamic:property">

<title>Dynamic Property</title>

<type>d:text</type>

</property>

</properties>

<mandatory-aspects>

<aspect>dynamic:assignee</aspect>

</mandatory-aspects>

</type>

<type name="dynamic:reviewTask">

<parent>dynamic:workflowTask</parent>

<overrides>

<property name="bpm:packageItemActionGroup">

<default>edit_wcm_package_item_actions</default>

</property>

</overrides>

<mandatory-aspects>

<aspect>dynamic:assignee</aspect>

</mandatory-aspects>

</type>

Reload the model using a dynamic approach as discussed earlier

• Step 2: Make the highlighted changes in web-client-config-custom.xml

<config evaluator="node-type" condition="dynamic:initializeTask" replace="true">

<property-sheet>

<separator name="sep2" display-label-id="users_and_roles" component-generator="HeaderSeparatorGenerator" />

<show-property name="dynamic:property" />

<show-association name="dynamic:assignee"

display-label-id="wf_reviewers" />

</property-sheet>

</config>

<config evaluator="node-type" condition="dynamic:reviewTask" replace="true">

<property-sheet>

<separator name="sep1" display-label-id="general"

component-generator="HeaderSeparatorGenerator"/>

<show-property name="bpm:taskId" />

<show-property name="bpm:description"

component-generator="TextAreaGenerator"

read-only="true"/>

<show-property name="bpm:comment"

component-generator="TextAreaGenerator" />

<separator name="sep2" display-label-id="wf_reviewers"

component-generator="HeaderSeparatorGenerator" />

<show-association name="dynamic:assignee"

display-label-id="wf_reviewers"

read-only="true"/>

</property-sheet>

</config>

Reload Alfresco explorer using dynamic approach as discussed earlier

• Step 3: Make the highlighted changes in dynamicProcessdefinition.xml

<?xml version="1.0" encoding="UTF-8"?>

<process-definition xmlns="urn:jbpm.org:jpdl-3.1"

name="dynamic:processTask">

<swimlane name="initiator"/>

<start-state name="start">

<task name="dynamic:initializeTask" swimlane="initiator"/>

<transition name="" to="submitreview">

</transition>

</start-state>

<decision name="submitreview">

<transition name="" to="end" >

<condition>#{bpm_assignee ==null}</condition>

</transition>

<transition name="" to="review">

<condition>#{bpm_assignee!=null}</condition>

</transition>

</decision>

<task-node name="review">

<task name="dynamic:reviewTask">

<assignment class=

"org.alfresco.repo.workflow.jbpm.AlfrescoAssignment"> <actor>#{bpm_assignee}</actor>

</assignment>

<event type="task-end">

<action class=

"org.alfresco.repo.avm.wf.AVMSubmitPackageHandler"/> <action class=

"org.alfresco.repo.avm.wf.AVMDeployHandler"/>

<action class=

"org.alfresco.repo.workflow.jbpm.AlfrescoJavaScript"> <script>

logger.log("WCM Submit Process: End submit for " + bpm_workflowDescription + "

(by " + person.properties.userName + ")"); </script>

</action>

</event>

</task>

<transition name="approve" to="end">

</transition>

<transition name="reject" to="end" />

</task-node>

<end-state name="end"/>

<event type="process-end">

<action class=

"org.alfresco.repo.avm.wf.AVMRemoveAllSrcWebappsHandler"/> <action class=

"org.alfresco.repo.avm.wf.AVMSubmitPackageHandler"/>

<action class="org.alfresco.repo.avm.wf.AVMDeployHandler"/> <action class=

"org.alfresco.repo.avm.wf.AVMReleaseTestServerHandler"/> <action class=

"org.alfresco.repo.avm.wf.AVMRemoveWFStoreHandler"/> </event>

</process-definition>

Update Process Definition using a dynamic approach as discussed earlier

• Step 4: Test using the Submit Items Wizard.

Click on Configure workflow to remove the user you have configured earlier.

• Step 5: Remove the user as shown in the following screenshot:

• Step 6: After removing the user click on OK.

Now that the workflow settings have been changed, click on OK to submit content to

the staging server It will not go to any user for processing, as we have not selected any user Content is submitted directly to staging

Workflow Viewer

Suppose you want to see list of pending workflows We can create a dashlet that will list down all the pending workflows for Groups (the same way you can also create for users) The list is quite useful for administrators

Follow the steps to create dashlets:

1 Create a Java file CustomWorkflowStatusBean in the package com.book web.bean.wcm and paste the downloaded code from the Packt website

2 Add the following code in the faces-config-custom.xml file:

<managed-bean>

<managed-bean-name>CustomWorkflowStatusBean</managed-bean-name> <managed-bean-class>

com.book.web.bean.wcm.CustomWorkflowStatusBean

</managed-bean-class>

<managed-bean-scope>request</managed-bean-scope>

<managed-property>

<property-name>navigationBean</property-name>

<value>#{NavigationBean}</value>

</managed-property>

<managed-property>

<property-name>serviceRegistry</property-name>

<value>#{ServiceRegistry}</value>

</managed-property>

</managed-bean>

3 Create a JSP file workflow-status.jsp in the specified location <install-alfresco>/tomcat/webapps/alfresco/JSP/extension/dashlets/

folder Paste the downloaded code from the Packt website

4 Add the following code in the web-client-config-custom.xml file:

<config evaluator="string-compare" condition="Dashboards">

<dashboards>

<dashlets>

<dashlet id="wfstatus-bean"

label="In-flight Workflow Status"

description="In-flight Workflow Status of invited project" jsp="/jsp/extension/dashlets/workflow-status.jsp" />

</dashlets>

</dashboards>

</config>

5 Run Ant to compile the code and create a JAR file in <install-alfresco>/ tomcat/webapps/alfresco/WEB-INF/lib

6 Start the Alfresco server.

7 Log in as admin

8 Configure In-flight Workflow Status dashlets Refer to the Web Publishing

dashlets section in Chapter 4, Web Content Production with Web Forms,

to configure

9 You will see the following screen that lists all the pending workflows:

Summary

Workflows can be deployed dynamically also In this chapter we have learned the following points:

• The customization of workflow can be achieved using two approaches, manual and dynamic

• E-mail notifications can be made to all the concerned people involved in the workflow process

• Workflows for a specific Staging Sandbox submission can also be removed using some customization

• Implementing ZERO workflow gives the flexibility to submit content using workflows without selecting any user/group

• Workflow Viewer can be implemented to see the number of active

workflows, which is good for administrators

Content Delivery and

Deployment

So far you have learned the content production capabilities of Alfresco using web projects, User Sandboxes, web forms, and workflow This chapter introduces you to the content delivery and deployment features, of Alfresco You will understand the concepts behind delivering static content as well as dynamic content to the external production servers This chapter covers deployment to both live servers as well as to the test servers This chapter also focuses on the auto deployment feature where the content can be scheduled to be delivered to the production servers automatically

By the end of this chapter you will have learned how to:

• Install and configure File System Receiver (FSR)

• Use Alfresco Server Receiver (ASR)

• Set up the process for auto deployment

• Deploy to a test server

• Deploy directly from a workflow

• Set up hybrid deployment for both static and dynamic content

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 modified 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 the 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 flat

filesystem to be served up by Apache or IIS, or you can push your content into another runtime instance of Alfresco