Seeing what Variations Work Items are Queued

One of the sources of confusion when using sites based on the Variations infrastructure is the delay that occurs between creating a page in a target site, or publishing an existing page, and seeing the results in the target variation.

This process is controlled by a number of timer jobs which all start with the word "Variations" which means that you can at least find them quickly in the list of timer jobs. Go to Central Adminstration -
> Monitoring -> Timer Jobs - Review job definitions, and you will see them listed. If you click on the link for one of these you can see, and modify, the schedule on which it runs. You can also monitor running jobs by going to Central Adminstration -
> Monitoring -> Timer Jobs -> Check job status and, if you time it right, you might see one of the variations timer jobs running.

What you don't get to see is the list of specific tasks, or work items, that are queued up to be actioned the next time the timer job runs. These actually live in a table in the content database called dbo.ScheduledWorkItems. If, heaven forbid, you were to look at this table in, say, SQL Server Management Studio, you would see the list of work items, if any, that are waiting. I don't want you to go poking around in the SharePoint databases, particularly on a production system - even running a query just to look at the contents of the table could potentially cause locks and is not recommended - but if you did you would find it pretty unhelpful because the items are defined in terms of GUIDs or, in some cases, fragments of XML.

If we can't see this in the UI, and we don't want to run a query against the content database, what can we do? Well there is an API called SPWorkItemCollection in the object model that can be used to get a list of pending work items of a particular type. How is the type defined? Yes, you guessed it - a GUID. The problem is that the SPWorkItemCollection is really intended to help you build custom work item timer jobs. It's constructor executes a query against the work item table to give you a set of items to process, but it doesn't do this passively. The assumption is that you are going to deal with them, and the table gets updated to mark these items as "in progress". That means a second call won't return any items and, what's worse, neither will the timer job. In this case it sounds as though doing the right thing and using the SharePoint object model is worse than querying the database. Ouch.

Well, the good news is I have managed to figure it out and use the API to get the queued items, after which I call the UpdateWorkItem method to put things back the way they were. You can call it as many times as you like and it will still work, and the timer job will still be able to pick them up as well.

I have saved this code as a small console application that you can download. But please remember that I give no warranty - if you are going to use it on a system that you care about be sure to test it first. In fact I would advise against using it on any kind of production system. I hope you find it useful.