9

I am working on a SharePoint 2013 site collection. And I have an Issue Tracking list, where I want to perform these actions on it once a day (at 12:05 AM):-

  • Check if a column named "Review Date" of an item is met (Review date = today), and if so, to change the item status to be "In Progress".
  • Then to send an email to the "Assigned To" user , that there is an item assigned to him with “Review Date” that have been met.

Now I read many articles about implementing similar background jobs in SharePoint 2013, and I can list these main approaches:-

  • Write the 2 checks inside a PowerShell script, and call this PowerShell script on timely basis using windows task scheduler.
  • Using Visual studio I can create a timer job as a Farm solution and deploy it inside the web application.
  • To create a workflow which do the two checks (send email & update the tem status), then link the workflow with the related content type. After that I can set a retention policy which calls the workflow daily.

So I am totally confused on what are the advantages and disadvantages of each approach. Now from my point of view I can list these :-

  • Using PowerShell & windows task scheduler. I will be creating dependencies on SharePoint outside the SharePoint farm. For example backuping the farm will not include the PowerShell scripts and their schedule.
  • While creating a timer job , will require me to create a farm solution which is not the best approach in SharePoint 2013.
  • While the third approach seems the best as it is more SharePoint oriented and can be extended and managed with minimal code?

So can anyone advice on the differences between these approaches, and are there additional approaches better than these?

4 Answers 4

9
+100

Workflows
The last option I'd go with is the workflow: workflows are slow, buggy, do not work at all when there's a lot of them running, complicated to debug, and most of all they completely disturb the users since they're visible in the UI (with a messy UI). Why would a background task be visible in the UI? In addition, conceptually, your task is not a workflow: there's no interaction with users, no need for a UI, etc.
And also: workflows don't migrate well, especially running instances... and in your case, you'll have running instances.
And also (bis): your workflow would do what? Wait most of the time? Have a big one "Wait" activity? Just by imagining what he'd look like, you can see it's not "right".

Scheduled PowerShell
I like that one for its simplicity and the ease to maintain for a non-dev person. No need to know Visual Studio, WSP, packages, etc. You can create your script, test it, improve it, and once it's ready: you schedule it. But, as you, said, you will create dependencies on SharePoint outside the SharePoint core: on which server do you deploy? What happens if the server is removed from the farm? Will somebody else be reminded she/he has to deploy it on the new farm in case of migration?
Another thing: a scheduled task will give you the opportunity to retry failed work items (the same applies to jobs).
If you go that way, the most important point will be: add logging and document your work!

Timer job
Definitely the way I'd do it. WSP are not deprecated. Microsoft just wants you to move to the add-in (App) concept so you're "cloud-ready". But WSP are still there, as long as SharePoint will exist on-premises. The only downside I can see with this approach is: you need a good SharePoint developer to do it, and to do it good.

Another one: create a client app
Another approach you may consider: develop a C# client application (or service) leveraging the client API of SharePoint. That client could run on a third-party server (not part of the SP farm). While this has the same downside as the "Scheduled PowerShell" (outside of SP, and even a need for a third-party server) it has the advantage of being "cloud/O365-ready". But still, not the one I prefer...

TL;DR

  • You are/have/can_buy a good SharePoint developer: a job in a WSP package
  • You aren't/don't_have/can't_buy a good SharePoint developer: scheduled PowerShell + documentation
  • You want to be "cloud-ready": client app
  • You want problems: workflows
15
  • 1
    You got most of my points, yes! :) Even if I'm not even sure about the "WF is the most SharePoint-oriented"...
    – Evariste
    Feb 11, 2016 at 16:43
  • 1
    i mean SharePoint provides the ability to define a Retention Policy on the Content Types, and inside the Retention policy i can call a workflow. and the retention policy will be called base on timer jobs... also backuping a site collection will also backup the related retention policy and workflow ,and content type are designer to be used on different sites.while these things will be missing if i go with powershell, also let say i need such functionalities more and more,, then i will have a long list of powershell scripts being stored/managed out side SP farm,, this is my point..
    – John John
    Feb 11, 2016 at 16:47
  • 1
    I see what you mean. My own vision was just between "Jobs" vs "Workflows" in general. Jobs are really SharePoint-oriented, and IMO more than workflows: even if the OOB product, all background tasks are written as jobs (empty recycle bin, send alerts, ...) and not at all with workflows. But, again, jobs require strong dev-skills. Also, I've never heard of good, usefull, never-crashing, easy-to-use workflows...
    – Evariste
    Feb 11, 2016 at 17:28
  • 2
    Actually everything comes from my own experience (~10 years, since WF in SP2007): I've never seen a good workflow (including: with a UI that doesn't bother users), while all jobs I saw, maintained, developed, always did the job done and well done. And it's not all about "SharePoint-oriented" or "reliability": it's also about debugging easiness, maintenance, evolutivity (with a job I own the code of, I'm quite sure any future need will fit), migration, UI, ease of deployment on different farms...
    – Evariste
    Feb 11, 2016 at 18:36
  • 1
    As I was looking at the "featured" questions here on SharePoint.stackexchange, I noticed that one, and I though it was relevant for our disccusion :) sharepoint.stackexchange.com/questions/169278/…
    – Evariste
    Feb 12, 2016 at 8:07
5

To be honest, based on the requirements:

  1. Check if a column named "Review Date" of an item is met (Review date = today), and if so, to change the item status to be "In Progress".

  2. Then to send an email to the "Assigned To" user , that there is an item assigned to him with “Review Date” that have been met.

I would go for a Workflow. Why? Well, because it has the characteristics of a workflow. You could write a PowerShell script and have it execute from the task scheduler, you also could write some custom code and deploy it to the farm as a timer job, but to me that would be like cutting holes in the floor of your car and using your feet to power it -- why not just use the motor!?

The workflow engine is there to solve tasks just like this. It can be set up with minimal code and can easily be managed and altered without having to do any code deployments, or fiddled with the task scheduler.

You can utilize custom timer jobs for pieces of work that are too complex to package into a workflow, and you can go down the PowerShell/Scheduler route when you aren't able to use a timer job (i.e. SharePoint Online), or for when custom code deployment are disallowed by policy.

1
  • as i wrote this question 10 days ago, so i took the decision by myself, where i define a retention policy on the content type , where the retention policy will be calling a workflow,, so far it is working well, but not sure if this is a reliable approach or not ..especially if a workflow fails for a reason or another , then no email will be send and the item will not get updated...
    – John John
    Feb 11, 2016 at 16:43
5

(A code-only option, as an extra, not necessarily a suggested answer but one for others who will in future come across this question)

I'm surprised nobody's brought up the pretty awesome Patterns and Practices Remote Timer Job Framework

https://github.com/OfficeDev/PnP/tree/master/Solutions/Core.TimerJobs.Samples

Basically it's a .NET library that lets you define a Timer Job class, much like the server side OM equivalent, but what's better is you implement and run in a .NET Console app, which lets you schedule it via the Windows server task schedular, or the exact same console app zipped up can be used as an Azure Web Job.

Maximum flexibility with this model, and you can just use the Client object model to get what you need, and you can then do absolutely anything else you want in .NET code.

10
  • ok thanks for the info i did not use the Remote Timer Job Framework before. so you mean i can write a console app using .net then schedule it to run using windows task scheduler? is this correct ? so my question is what will be the differences between using Remote Timer Job Framework scheduled using windows task scheduler and between writing my code as a power-shell script and call this powers-sell script using windows task schedule ?
    – John John
    Feb 12, 2016 at 2:59
  • second question i have is that i always use windows task scheduler inside my SharePoint farm to do admin jobs ONLY , such as site collection backup, farm backup etc.. but i never though that using windows task scheduler to schedule non-admin tasks such as modifying list items and sending emails is a common and recommended approach,, i always see that scheduled tasks such as modifying list items should run by the timer jobs within SharePoint server rather than being called using windows task scheduler which is outside the SharePoint farm ?? can you advice? thanks
    – John John
    Feb 12, 2016 at 3:04
  • 2
    You're right, admin tasks that you normally do in PowerShell are probably left in there and scheduled if needed. Non-admin tasks that get and update list items are indeed normally done in Timer Jobs in SharePoint, but one was to build something new, they'd want to support future versions of the product, so will use remote APIs if possible. A console app that uses PnP timer job framework will support SP2013 and beyond, needs no WSP installation, and can run anywhere.
    – James Love
    Feb 12, 2016 at 8:30
  • 1
    Yes, the remote timer job is just an app and you need a way to schedule and run it, as it can't run within SharePoint directly like SP timer jobs. You can write PowerShell that can do stuff that you can do in .NET, but complex data structures are harder to write, the syntax is a bit more verbose, and there's the PowerShell Execution Policy which you can't guarantee you have control over on some environments (depending on the company's IT governance).
    – James Love
    Feb 12, 2016 at 18:51
  • 1
    It depends what you class as an admin task. Updating things in a SharePoint list might count as an admin task if there are other processes dependant on it. Essentially you're doing the same thing, be it in PowerShell or a console app, just in a different scheduling model - one of which is easier to modify later if need be (powershell scripts), the other more restricted, but able to run on multiple servers (Timer jobs)
    – James Love
    Feb 16, 2016 at 19:31
-1

Evariste has answered it well. However I would like to give one more option.

Why not to create a simple asynchronous event receiver (ItemUpdated) which checks if (Review date = today) and if yes, update the status field to "In Progress" and send email notification to the assigned to user.

            SPListItem listItem = properties.ListItem;
            DateTime dtReviewDate = Convert.ToDateTime(listItem["ReviewDate"]);
            if (dtReviewDate == DateTime.Today)
            {
                this.EventFiringEnabled = false;
                listItem["Status"] = "In Progress";
                listItem.SystemUpdate(false);
                this.EventFiringEnabled = true;
                SendEmail(strEmailOfAssignedTo);
            }

PS: Don't forget to call this.EventFiringEnabled = false!!

Yes, you need to create WSP to deploy and associate event receiver with List through Feature but I don't see any downside of having wsp, it's part of SharePoint Development.

3
  • 2
    The requirement was to process all items once a day. Your approach will process single item when it's updated. Feb 16, 2016 at 10:51
  • @Dipesh thanks for the answer ,, but this is not related to my question ..
    – John John
    Feb 16, 2016 at 17:46
  • Oh okay, In that case, I think Timer Job would be the best choice. Feb 19, 2016 at 6:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.