When I first read the blogpost from Maurice Prathe about this thing I didn’t really understand what a good purpose could be using this technique. But now I’d wish I had spent more time in researching how cool this functionality is. A recommended read is the following article Creating Custom Timer Jobs in Windows SharePoint Services 3.0 by AC (he does a better job explaining this stuff than I do..:).

Now I assume we all know how easy it is to store key/value pairs in the propertybag of SharePoint objects. The thing is that sometimes we don’t have a reference to the proper object to access those key/value pairs.

So.. considering the following.. you develop a solution which contains the following items :

• Custom featurereceiver that creates a list on the rootweb of the sitecollection where it’s been activated
• Custom timerjob that checks the previously created list to do stuff automatically
• Custom application page to administer the timerjob (scheduling, configuration, etc)

The challenge here is that a timerjob has no knowledge where the feature is activated right? The only thing you pass thru is the WebApplication on which the timerjob runs. So we introduce our own little class that inherits from the SPPersistedObject, where we specify the url of the site on which the feature is activated.

public class CustomTimerJobSettings : SPPersistedObject
{
    [Persisted]
    public string ActivatedSiteUrl;

    public CustomTimerJobSettings() { }

    public CustomTimerJobSettings(string name, SPPersistedObject parent, Guid id) : base(name, parent, id)
    {
    }
}

Now to store the url we use the following bit of code :

CustomTimerJobSettings settings = webApplication.GetChild<CustomTimerJobSettings>("CustomTimerJobSettings");

// If no settings previously created, create them now.    
if (settings == null)
{
    SPPersistedObject parent = SPContext.Current.Site.WebApplication;
    settings = new CustomTimerJobSettings("CustomTimerJobSettings", parent, Guid.NewGuid());
    settings.Update();
}

settings.ActivatedSiteUrl = SPContext.Current.Web.Url.ToString();
settings.Update();

To get the Url we use the following bit of code :

//Getting the ActivatedSiteUrl of the persistence store
CustomTimerJobSettings settings = this.WebApplication.GetChild<CustomTimerJobSettings>("CustomTimerJobSettings");
string activatedSiteUrl = settings.ActivatedSiteUrl;

And that’s it..! :)

So the beauty of this thing is that you can store your own class with all types of datatypes and you are not limited to use only key/value pairs.

The problem is that you can only use it timerjob like applications since you can only store (persist) the object into the SPWebApplication and SPFarm and to access those type of objects you need a lot of rights in the farm while you can store stuff in the propertybag as low as a SPListItem. So maybe.. just maybe in the next version we can use it on every SP-object we want ;)