Wednesday, February 24, 2010

Developing Custom SharePoint Timer Jobs and the importance of separating SharePoint development from SharePoint deployment

The catalyst for me writing this blog post was a pretty standard requirement for a daily timer job on a Web Content Management (WCM) project for a customer last week. I spent the best part of a day writing the logic for the timer job inside a Console Application project where the debug cycle is far greater reduced. I then spent 5 minutes packaging that up and deploying. I then decided I needed to modify the schedule which was originally set via the Feature Receiver but I didn't want to redeploy or reactivate, and nor should I. This reminded me of how many more junior SharePoint developers I see who forget very basic rules about not confusing the development process with the deployment process. This blog post discusses the resources, and methods I used to quickly wrap a piece of SharePoint functionality into a timer job, deploy it to a WSP and modify its schedule via the UI.

So, after you've got your logic written in your Console Application and you want to package that up into a timer job, then what? Well, that's pretty simple. Visit Andrew Connell's blog and read his article on Creating Custom SharePoint Timer Jobs. This isn't groundbreaking, complex code but quite simply put; it works. In the interests of brevity I'm not going to repeat any content here. One thing you will notice is that the scheduling for the job is inside the FeatureActivated() event within the Feature Receiver. This is fine if you know the schedule at the time you deploy. The chances are however you're going to want to modify the schedule after you've deployed when the customer inevitably changes their mind about when, and how often, a specific piece of functionality runs. For this, there's an awesome tool on the CodePlex website called SharePoint Timer Job Administration. This is an awesome piece of software that gives you a link within SharePoint Central Administration called "Manage Timer Jobs" where you can modify the schedule and disable/delete timer jobs. Simply modify the UI and restart the Windows SharePoint Services Timer Service (OWSTimer.exe) and you're good to go.

So my point? By 4:30pm last Thursday I had a piece of code written and tested. By 5pm that code was wrapped in a timer job, packaged inside a WSP and deployed into a customer environment. From that point its schedule was modified multiple times via the browser. Even though I understand how to write timer jobs and how to package SharePoint artefacts into deployable solutions, I would have wasted a great deal of time if I was deploying code into SharePoint inside a timer job from the beginning. Imagine how much timer I'd have wasted if I didn't understand SharePoint timer jobs and I did that? We need to think about what it is we're testing when we write SharePoint code and be absolutely sure to separate functional testing of SharePoint artefacts (Content Types, Site Columns, Timer Jobs) from their deployment. Tools such as the SharePoint Solution Generator, and more recently SPSource, make it so much easier to separate development from deployment and we should take full advantage of them. These tools allow us to generate entire publishing solutions via SharePoint Designer and the SharePoint UI and extract them afterwards. I wrote a tweet today on how the variety and quality, in general, of CodePlex tools make the life of a SharePoint consultant so much easier. I meant it, too.