This is a very insightful blog by Brian Cartmel.
Brian is a Microsoft Certified Master for SharePoint 2010 who
specialises in designing, developing and promoting solutions built
on the SharePoint Platform. Check out this blog by Brian
I recently learnt about a new (well new to me at any rate) type
of SharePoint timer job. Rather than the standard timer jobs I
normally create that inherit from SPJobDefinition, this different
kind of timer job inherits from SPWorkItemJobDefinition
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spworkitemjobdefinition.aspx
With a normal SharePoint timer job (SPJobDefinition), the job is
scheduled via an
SPSchedule object, and is run whenever this schedule dictates.
When an occurrence of the timer job runs, any logic that is
contained in the Execute method is then called:
So far, so normal. However, it is a fairly common requirement
for a site collection to want a timer job to process something on
its behalf - after all this what timer jobs excel at. However,
communicating to the timer job what needs to be processed is usual
done by creating custom list items (or some other content) in the
site collection. Then the timer job has to iterate through the site
content to find the items and then start performing some work based
on those items or their properties.
I've done this myself and seen it done dozens of times and it
usually involves hidden lists or custom columns on list items that
the timer jobs is trained to look for.
Here's where SPWorkItemJobDefinition
timer jobs comes in. These timer jobs use a queue to determine what
should be processed and the site collection simply adds items to
the queue. No custom hidden lists, no custom columns, just a nice
simple FIFO queue we can write too from the site collection .
How it works
Create a timer job that inherits from
SPWorkItemJobDefinition:
…override the WorkItemType property
with a unique Guid of your choosing:
…the WorkItemType is a unique Guid
that this timer job will 'listen' for. Any operations that add SPWorkItems to
the queue from the site collection will include a reference to this
Guid. In this way, multiple timer jobs can share the same queue and
SPWorkItems
are picked up by the right timer jobs.
Next we override the ProcessWorkItem
method, this is where we do our main processing and is the
equivalent of the Execute method of a normal SPJobDefinition timer
job:
This method is called by the timer job
framework on each occurrence of the timer job schedule AND ONLY IF
work items have been queue for this timer job based on its
WorkItemType Guid. Because this method is only called when items
are queued for it and the method is passed the work items to
process rather performing expensive queries looking for items
within the site collection, this is potentially a much more
efficient operation compared to a standard timer job!
Read
More>>
Stay tuned for more content by joining our community or by
following us on twitter or facebook!