Alexander Brütt

Best practices: SharePoint Timer Jobs

Part 1: Experiences and bad practices

I’ve developed a couple of SharePoint Timer jobs during the last months and gained a lot of experiences with deploying, configuring, debugging and updating them. Adding your code directly into a SharePoint timer job has many disadvantages:

Configuration

Timer jobs are run from the SharePoint Timer Service also known as owstimer.exe. You can place a owstimer.exe.config and add your configuration settings here. It serves as a shared app.config for all timer jobs. If you modify the configuration file you have to restart the timer job service to let the changes take effekt.

The config file is not designed to be used for timer job configuration so it doesn’t exist after you installed SharePoint. You have to create it on your own.

There are some alternative possibilities like custom defined xml files stored in a file at a defined location on the hard disc. Andrew Connel describes some ways to configure SharePoint timer jobs at MSDN. In my opinion none of them are simple to implement and nice to handle like a web.config or app.config.

Degbugging

To debug a timer job you have to attach the debugger to the owstimer.exe process, set breakpoint and wait until your timer job is executed. This could take minutes for each debugging session.

Deployment and redeployment

The deployment of a timer job is easy stuff if you have a visual studio template doing the dirty work for you. However, redeploying a solution means that you have to restart the SharePoint Timer Service and IIS what means session reset to all connected users.

Part 2: Extract code from timer job to web service

A default timer job is implemented like this:

Your code is inside the timer job and accessing your SharPoint using the API.

If you are going to write many lines of code your timer job you have a huge potential for error and you will need a couple of debugging sessions to fix all errors. Since debugging timer jobs take much time this doesn’t seem to be the best way implementing timer jobs.

Here’s my idea: Extract your code from the timer job into a web service.

In this scenaro your timer job has just those lines of code needed to call the web service. The configuration parameters of this timer job is quite short - just the URL of your webservice. On single server farms you could reference your web service using “localhost:portxy” and do not need a configuration for this. If you need a configuration option you could chose on of the alternatives described by Andrew Connell at MSDN.

Using a web service has some big advantages:

Configuration file

You can deploy a web.config file and put as many configurations in it as you wish and do not have to worry about affecting other job configurations. If you modify the web.config file you do not have to restart any services or the IIS.

Deployment

You can deploy and redeploy your web service without having to restart the SharePoint timer service or IIS.

Testing

You can write your own test client to call your web service whenever you want. You don’t have to wait until the timer service runs your code.

External job engine

If you have an external job engine like Control-M you can forego timer jobs and let the external job engine call your web servce. In this case you do not need the owstimer.exe.config anymore.

Security considerations

A web service accessing the SharePoint with administration rights adds a point of attack. Only the persons or service accounts that use the web service should be allowed to call the service.