Custom Document Expiration Policy – Part-2: Implementation
Posted by zieglers on January 18, 2010
In my previous post (https://zieglers.wordpress.com/2010/01/18/custom-document-expiration-policy-part-1-overview/), i tried to show how custom expiration policy works. Now in this post, i’ll dive into implementation details.
Here what we do is to create and install our own expiration formula as Policy Resources that are linked to the Expiration Policy Feature.
The Expiration Policy Feature communicates with your custom expiration formula policy resource through a special interface provided for that purpose. The IExpirationFormula interface is declared in the Microsoft.Office.RecordsManagement.PolicyFeatures namespace. This interface declares a single method that is called to compute the expiration date for a given list item.
Policy Namespace Overview
The following figure shows the organization of the major classes of the information policy object model, located in the Microsoft.Office.RecordsManagement.InformationPolicy namespace. The top-level object, PolicyCatalog, represents the catalog containing the site-level Policy and IPolicyFeature collections.
Most of the properties of the various objects are read-only, and cannot be set programmatically. The properties of the various information policies, policy items, policy features, and policy resources are set in the XML specified when the objects are initially added to Office SharePoint Server 2007.
Each Policy object represents an information policy defined for the site and, in turn, includes a collection of PolicyItem objects.
Similarly, each PolicyFeature object represents an installed policy feature, and contains a collection of the PolicyResourceType object that the policy features can use, as well as a collection of the actual policy resources currently installed for the policy feature; each of these policy resources is represented by a PolicyResource object.
The following figure shows the information contained within the Policy Feature Definition, and the items that the information references.
I think above information clears the overall picture. Now let’s see the implementation of IExpirationFormula interface.
Here we need to implement only one method, which is ComputeExpireDate. You can implement your own custom logic to calculate expiration date here and then return it. As for this POC, my custom logic is as follows:
1. Check for existing expiry date, if there is any.
2. If there is, compare it with current time. If time difference is less than 2 minutes, send a warning email to user.
3. If there is no existing expiry date, set it based on following rule:
[Extra Functionality] if user wants this item to be collected immediately (if ‘CollectMe‘ field value is Yes – assuming that there is a Yes/No column called CollectMe in the library), then set expiration date to current time.
if CollectMe is No, then set expiration date to 5 minutes after last modification time.
Pretty straightforward, right? Note that this function will be called each time Expiration Timer Job runs and each time this list item is edited.
Also, here is the snippet of SendWarningEmail helper method. This code is just for demonstration, values are hardcoded, but it shows how to use SPUtility.SendEmail method.
Well, that’s all about it.