SharePoint Timer Jobs are processes that run periodically in the background, managed by the SharePoint ecosystem. Long-running operations you normally would like to run nightly (or any time of the day which is considered off-peak) are ideal candidates to be implemented in timer jobs.
To create and run timer jobs you need two things:
- A class that inherits from the SPJobDefinition base class.
- A feature to deploy your job.
All timer jobs have to inherit from SPJobDefinition. Depending on what you develop there are two constructors you can call. If you’re developing a service application then you must call the constructor which has an SPService parameter, otherwise you’d call the one with an SPWebApplication parameter. You’ll also have to write a parameterless constructor, for serializing purposes. Here’s a list of SPJobDefinition constructor parameters:
- Name: the name of your timer job, must be unique per web application / service.
- SPWebApplication/SPService: the web or service application to associate the timer job.
- SPServer: optionally you can associate your timer job with a SharePoint server, but it’s not a requirement.
- SPJobLockType: the lock type of the job.
There are three lock types for a timer job:
- None: runs the job on all servers on the farm, where the parent web or service application is provisioned.
- ContentDatabase: runs the job once per content database. If you specify this lock level you’ll get the identifier of the current content database in the job’s Execute method.
- Job: the job will run only one time.
After identifying and calling the appropriate constructor, you need to override one method to actually do something. This is the Execute method. If you specified the lock type ContentDatabase, then the guid parameter of this method will contain the current content database’s id. Otherwise you can disregard this parameter. In the execute method you can do anything that needs to be done in your job.
To deploy your timer job you’ll need a feature with an event receiver. In the event receiver’s FeatureActivated method you’ll call your concrete SPJobDefinition’s constructor, assign an SPSchedule object specifying when to run your job and assign it to the job’s Schedule property. Then you’ll have to call the Update method on the job definition, and you’re good to go.
To debug a timer job you’ll have to attach to the OWSTIMER process from Visual Studio. Then if you don’t want to wait the scheduled start time of your job, you can run the job from Central Administration.
There’s a very thorough guide for writing timer jobs here if you need more details.