views:

1486

answers:

5

I have a website that's running on a Windows server and I'd like to add some scheduled background tasks that perform various duties. For example, the client would like users to receive emails that summarize recent activity on the site.

If sending out emails was the only task that needed to be performed, I would probably just set up a scheduled task that ran a script to send out those emails. However, for this particular site, the client would like a variety of different scheduled tasks to take place, some of them always running and some of them only running if certain conditions are met. Right now, they've given me an initial set of things they'd like to see implemented, but I know that in the future there will be more.

What I am wondering is if there's a simple solution for Windows that would allow me to define the tasks that needed to be run and then have one scheduled task that ran daily and executed each of the scheduled tasks that had been defined. Is a batch file the easiest way to do this, or is there some other solution that I could use?

A: 

Use the Windows Scheduled Tasks or create a Windows Service that does the scheduling itself.

Mehrdad Afshari
+4  A: 

To keep life simple, I would avoid building one big monolithic exe and break the work to do into individual tasks and have a Windows scheduled task for each one. That way you can maintain the codebase more easily and change functionality at a more granular level.

You could, later down the line, build a windows service that dynamically loads plugins for each different task based on a schedule. This may be more re-usable for future projects.

But to be honest if you're on a deadline I'd apply the KISS principle and go with a scheduled task per task.

Kev
I've only been brainstorming with the client so far, so I'm not really on a schedule yet. Right now, it would be easy to add a scheduled task for each of the tasks they want, but if the site gets popular, they may be asking for a whole bunch of other tasks.
Matt Ephraim
+1  A: 

I would go with a Windows Service right out of the gates. This is going to be the most extensible method for your requirements, creating the service isn't going to add much to your development time, and it will probably save you time not too far down the road.

JasonS
A: 

We use Windows Scheduler Service which launches small console application that just passes parameters to the Web Service.

For example, if user have scheduled reports #388 and #88, scheduled task is created with command line looking like this:

c:\launcher\app.exe report:388 report:88

When scheduler fires, this app just executes web method on web service, for example, InternalService.SendReport(int id).

Usually you already have all required business logic available in your Web application. This approach allows to use it with minimal efforts, so there is no need to create any complex .exe or windows service with pluggable modules, etc.

Oleg Yaroshevych
A: 

The problem with doing the operations from the scheduled EXE, rather than from inside a web page, is that the operations may benefit from, or even outright require, resources that the web page would have -- IIS cache and an ORM cache are two things that come to mind. In the case of ORM, making database changes outside the web app context may even be fatal. My preference is to schedule curl.exe to request the web page from localhost.

rpresser
Ah ... Oleg's answer of using an exe to call a WEB SERVICE incorporates the best of both worlds -- flexible parameters for scheduling, combined with the actual job running in the IIS environment. I'd rate him up but I don't have the rep for it.
rpresser