As we know most instances from Microsoft.SharePoint namespace run within a memory space headed by w3wp.exe but timer jobs, from the namespace of Microsoft.SharePoint.Administration, are executed in another service instance’s memory space: Windows SharePoint Services Timer Service headed by Owstimer.exe. The instance from Owstimer.exe, should I say, is named as SPTimer.
To create our own timer jobs in custom solutions involves steps as creating classes with business logic implementations, configuring timer job schedules, and registering the schedule to the instance of SPTimer.
First, creating business classes and implementing business logic routines; one of the classes needs to have a base class inherited from Microsoft.SharePoint.Administration.SPJobDefinition so that it facilitates business classes functions and methods defined in the base class to execute our timer jobs. Second, defining or configuring a timer job schedule; for the sake of flexibility, a timer schedule can be defined in an external configuration file. You may think of, say, an application configuration file named Owstimer.exe.config in usual practices. However, reading a timer schedule through the application configuration file is not recommended by Microsoft. Anyhow, reading the schedule through an external file, SharePoint list, or an hierarchic object storage is acceptable as claimed by the ShaerPoint team at Microsoft. Why?
As long as you have a timer schedule defined by any means as mentioned above, the following step is to register the schedule to the instance of SPTimer. Simply enough, just call a method “Update” from the base class. Thus so far, we should complete our customer timer jobs.
So questions are still remained as when and where we should have our business classes instantiated into running objects, and the method of Update being called?
We make it all happen at the moment of a feature activation! This is because we have our custom timer jobs wrapped into a solution package as a SharePoint feature to be deployed to a server farm.
We define the timer job schedule and register it to the timer instance of SPTimer in the captured event of SPFeatureReceiver.
Anyhow, one more question: how our business objects being executed at the timer defined in the schedule?
The base class from Microsoft.SharePoint.Administration.SPJobDefinition faciliates another virtual method – Execute, from which we can override it and instantiate the business objects and further, execute the business logic. As a matter of fact, we do not call the method instead, the method of Execute will be called by the instance of SPTimer at the scheduled time.
Here is a simple sample code showing steps and routines as discussed above:
TO BE CONTINUED…
For detailed information, click here to visit MSDN Online.
