Alternatives to SharePoint Timer Jobs
Note to reader [28th March 2018] - the following article is still valid if you're on SharePoint 2010 or older and unable to use Cloud. However if those conditions don't apply then you now have access to Flow, Azure Functions and all that good stuff, making the below advice somewhat out of date (Hey it's from 2013).
Some time ago now I blogged that SharePoint Timer jobs should not be written without good reason. One thing I've noticed is there's no guidance online about alternatives to achieving the same results, so decided it was time for another post. (Though to prove there are never any new ideas I did find this post from 2008 )
First to recap; The prior article noted that advice in forums was promoting the use of timer jobs for any old recurrent process. Timer jobs are full trust solutions and when written badly can seriously impact your farm, not to mention if you did write one for every recurrent process you ever need you'd end up with an unmanageable number of processes and code. Looking to the future, if you ever considered moving to The Cloud e.g. Office 365, such Full Trust solutions would not be allowed, and your business would find itself scrambling at great cost to replace the functionality in another way. Actually, Timer Jobs are so Cloud Unfriendly that (and this is complete speculation on my part) I could see custom Timer jobs even being announced as deprecated in a future SharePoint versions. (The ootb ones would stay, but custom ones would be disallowed).
So, what does all this mean? Well, it means that we can't actually know for sure what will happen in the future, but we can see the way the tide is turning. There's a strong push against Full Trust solutions in general, (typified by the now deprecated (sic) Sandbox Solutions and now) in favor of Apps. We need to make sure that whatever we put in place now meets the business requirement, but also has a fighting chance of surviving whatever feature deprecations might occur in the next couple of product versions.
Just a few years ago, Full Trust solutions would be how I'd solve many issues in SharePoint. But now I'm making sure that as few of my solutions as possible need to be deployed onto my SharePoint farm. First off, I'm using javascript and JQuery to achieve what I might have done with web parts in the past. For more involved functionality (where I might have used Timer jobs for example) I'm taking my lead from the way WorkFlow has been architected in SharePoint 2013 and taking it off the SharePoint farm completely onto a different dedicated box. See the diagram below;
How the Design thought process has changed in three years!
Where the thinking was once a custom timer job, I now have several alternative ways of providing robust recurrent processes. To head off a few questions, let's have a Q&A right now;
Q. Why doesn't the above use SharePoint asmx web services?
A. There's a very interesting article on MSDN here that states that the asmx web services are deprecated in SharePoint 2013. As such, where possible even in SharePoint 2010 I'm using the CSOM and REST APIs instead. I say where possible as the APIs are not as fully featured as the asmx web services in all areas. If I have to use the old web services or a Full Trust solution to meet the requirement, I'm still open to that. However CSOM and REST give me a lot of possibilities when manipulating List Data, which is the mainstay of most SharePoint solutions.
Q. When would I use a Windows Service and when the Task Scheduler?
A. That's a debate that rages elsewhere on the web to this day. :) Windows Services are really designed for continually running processes, rather than occasional batch processing. I think Task Scheduler will meet your needs in the majority of cases. Viewpoint here. btw I should mention a third option used by some Quartz .NET
Q. What credentials would the above use?
A. I'd favor a service account with non-expiring credentials whose rights on the SharePoint environment are the minimum required to complete the task. The service account will need 'Logon As Batch' rights to be scheduled.
Q. What's the Linux box all about?
A. Just to illustrate that the REST services make this cross platform. Your functionality doesn't need to be Windows based to orchestrate actions in SharePoint.
Q. So the diagram means Timer jobs in SharePoint 2010 but the external service calls in SharePoint 2013?
A. Nope. The years just illustrate the prevalent thinking at that time. The approach can be used for SharePoint 2010 as well as 2013 (even Office 365 in fact). Also watch this space as the CSOM and REST API are being invested in by Microsoft, more capabilities will become available.
Q. Doesn't this approach complicate development?
A. It simplifies development. Rather than having to write complicated code to manage your process within SharePoint (with all the plumbing that requires) you can write a relatively simple Console Application. The scheduling is handled by the Task Scheduler. As such you'll end up writing a lot less code.
Q. So this covers an idea for Timer Jobs, what about other functionality?
A. The general approach of calling into SharePoint from outside might be useful for all sorts of problems. I'm trying to limit the number of Full Trust solutions I deploy to SharePoint here. For example I recently had to write a one-off utility to updates the metadata on eighty thousand list items. Rather than Full Trust or Powershell I wrote a quick Winforms App to make the calls. It gave me a nice degree of visibility and flexibility when making the changes.
Q. So this approach should be used in all cases?
A. No, as always in Solution Design 'it depends' is your mantra. Full trust solutions and timer jobs still exist (except for O365 of course), and if that's currently the best way to meet your requirements then do it. But where possible you might want to use the above to save your organization future headaches. I should also mention that recurrent functionality can be done via Workflows, but I suspect the WF approach will not be robust enough for most use cases where a Timer Job would have been considered. That said, do consider the post by Fabian Williams here.
Q. This is all very well, but it presumes I have another server to use right?
A. Yes it does, but in a world where virtualization is everywhere and cloud hosting services abound, is it really so difficult to get your hands on an extra server? Remember this is moving some application resource usage off your SharePoint farm, which is a good thing.
Happy SharePointing!