Content Expiration

[resplin]

Obsolete Pages{{Obsolete}}

The official documentation is at: http://docs.alfresco.com

{{AVMWarning}}
AVM

Table of Contents

• 1 Introduction


• 2 Features
  
  
  
  • 2.1 Setting An Expiration Date On All Items
  
  
  • 2.2 Setting An Expiration Date On A Single Item
  
  
  • 2.3 Resetting An Item's Expiration Date
  
  
  • 2.4 Dealing With An Expired Asset
  
  


• 3 Implementation
  
  
  
  • 3.1 Model
  
  
  • 3.2 Workflow
  
  
  • 3.3 Code
  
  


• 4 Configuration


• 5 Debugging

Introduction

This page explains the WCM Content Expiration capabilities added to the 2.1 release.

Features

Content expiration provides the ability to specify a global 'freshness' date on all assets in a content submission or specific freshness date on a single item. Automatic daily task assignment to content contributors and publishers to review, update, or remove expired content. Each of these areas are explained further in the following sections.

Setting An Expiration Date On All Items

A new section has been added to the Submit Dialog in the 2.1 release allowing an expiration date to be applied to all submitted items, this section is shown below.

Expiration_section.gif

To set a date, click on the 'Set expiration date for all modified items' label, the standard Alfresco date selector component will be shown with an additional 'Apply To All' button as shown in the screenshot below.

Expire_apply_all.gif

Clicking the 'Apply To All' button will apply the date selectors current value to all non-folder items in the list of modified items. This can be seen in the new 'Expiration Date' column in the Modified Items list.

Setting An Expiration Date On A Single Item

A new 'Change Expiration Date' action has been added to items in the Modified Items list in the 2.1 release as shown in the screenshot below.

Expiration_action.gif

The action launches the new 'Change Expiration Date' dialog which allows a date to be applied to an individual item. Again, the standard date selector is used to select a date.

Resetting An Item's Expiration Date

There are a couple of ways to reset the expiration date. It can be done for all items by clicking the 'Set expiration date for all modified items' label in the 'Content Expiration' section, pressing the 'None' button and finally pressing the 'Apply To All' button. To reset a single item's expiration date launch the 'Change Expiration Date' dialog and press the 'None' button in the date selector, then the 'OK' button of the dialog.

Dealing With An Expired Asset

The repository checks periodically for expired items (see the Configuration section for details on adjusting the frequency of the checks). When any expired items are found they are added to a workflow and sent to the user that last modified the asset. If multiple items are destined for the same user they are batched up into a workflow for each Web Site the asset belongs to. For example, if logo.jpg and index.html from the web site 'Corporate Site' and product.html from web site 'Product Catalog' all expired and 'joe' was the last user to modify all the assets he will receive 2 tasks in his Alfresco task list.

Expired_item_task.gif

Clicking on the task will launch the Manage Task dialog which lists all the expired items, from here the assigned user can perform the relevant action on each item. These changes occur in isolation from the users sandbox, thus not affecting any work they may currently be doing in their sandbox. The workflow however is layered over the users sandbox so any changes they have made in their sandbox will be visible.

The dialog displays two buttons as shown below, both signal that all changes have been made and will therefore apply the changes to the users sandbox. The bottom button 'Task Done & Re-Submit All' will immediately launch the Submit Dialog so the user can submit their changes, whereas the 'Task Done' button will just apply the changes, users can then pick and choose when and which items to submit.

Change_request_buttons.gif

Implementation

This section describes the implementation details of the content expiration capabilities.

Model

A new aspect holding the expiration date property has been added to the WCM application model (wcmAppModel.xml).

<aspect name='wca:expires'>
  <title>Content that has or can expire</title>
  <properties>
    <property name='wca:expirationDate'>
      <title>Expiration Date</title>
      <type>d:datetime</type>
      <mandatory>true</mandatory>
    </property>
  </properties>
</aspect>

Workflow

A new workflow called 'Change Request' has been added, for the 2.1 release it's only used for managing expired items but in future releases the intention is to allow it's use in more generic scenarios.

The change request workflow (changerequest_processdefinition.xml) literally assigns a task to a user allowing them to deal with expired items.

Code

Server

The heart of the content expiration capability is the AVMExpiredContentProcessor. This Spring bean executes as the user specified in the configuration (admin by default) periodically (every day at 3:30am by default) and checks all AVM stores for expired content.

The AVMExpiredContentProcessor is actually called by the AVMExpiredContentJob bean, which is itself a Quartz based job class configured in scheduled-jobs-context.xml, see the configuration section below for more details.

Whenever AVMExpiredContentProcessor is called it iterates through all WCM staging stores and executes a query looking for any nodes that have an expiration date set to anytime before today. Each node is then processed to determine whether it has expired.

The first check determines whether the current expiration datetime value is before the current date and time (this check is done here as there is currently no support for searching time ranges only date ranges). If the node's expiration datetime has elapsed a check is performed to ensure the node is not locked, if it is a warning is logged in the server console and the next item processed. If there is no lock the last modifier of the node is retrieved and stored with the node's path in an internal list. The expiration date for the node is then reset back to null.

Once all nodes have been iterated over the generated list of users and expired nodes they are responsible for is processed. Firstly, a check is performed to see if the user that last modified the nodes still has access to the web project the nodes belong to. If they don't, the creator of the web project is determined. Once the user to assign the workflow to has been determined a workflow sandbox is created layered over the users sandbox. A new change request workflow is then started and the workflow sandbox set as the workflow package.

Client

The Manage Task dialog used by the change request workflow is a specialised dialog implementation represented by ManageChangeRequestTaskDialog. This dialog adds the processing described at the end of the 'Dealing With An Expired Asset' section. Specifically, the dialog updates the user's sandbox with the changes from the workflow sandbox, moves locks from the workflow sandbox to the user sandbox and completes the workflow. Optionally, the dialog will also launch the Submit Dialog pre-populated with all the expired nodes.

Configuration

Configuration for content expiration is in two files, scheduled-jobs-context.xml and avm-services-context.xml, you'll find both of these in the alfresco package i.e. tomcat-home/webapps/alfresco/WEB-INF/classes/alfresco

scheduled-jobs-context.xml contains the configuration for the frequency of expired item checks. By default it is set to check once a day at 3:30am as can be seen in the cron expression below.

<property name='cronExpression'>
  <value>0 30 3 * * ?</value>
</property>

avm-services-context.xml holds the configuration for the AVMExpiredContentProcessor bean. The user name to run the job as and the workflow to use to inform users of expired items are shown below.

<bean id='avmExpiredContentProcessor' class='org.alfresco.repo.avm.AVMExpiredContentProcessor'>
  <property name='adminUserName'>
    <value>admin</value>
  </property>
  <property name='workflowName'>
    <value>jbpm$wcmwf:changerequest</value>
  </property>
  ...
</bean>

Changes can be made directly to these files, ideally though they should be overridden using the standard approach. From release 3.0 onwards a sample configuration file is provided that overrides the cronExpression to enable checks every 2 minutes, see the Debugging section below for details.

By default the standard date selector only goes a couple years into the future. If an expiration date is required further ahead than that then the date selector will need to be configured, to see how this can be achieved read this example.

Debugging

To see debugging output from content expiration add the following lines to log4j.properties, found in tomcat-home/webapps/alfresco/WEB-INF/classes

log4j.logger.org.alfresco.repo.avm.AVMExpiredContentProcessor=debug
log4j.logger.org.alfresco.web.bean.wcm.ManageChangeRequestTaskDialog=debug

To test or demo the content expiration features waiting until 3:30am for the next check obviously isn't ideal. To make the checks more frequent change the cronExpression property mentioned in the previous section, the example below shows how to check every 2nd minute of every hour:

<property name='cronExpression'>
  <value>0 0/2 * * * ?</value>
</property>

Alternatively, use the sample file 'content-expiration-debug-context.xml.sample' provided with release 3.0 onwards, this can be found in tomcat-home/webapps/alfresco/WEB-INF/classes/alfresco/extension. Just remove the '.sample' suffix and restart Tomcat.