Background Process - What is the best approach

I am trying to set up a communication system that will allow a manager to specify a series of emails/text to be sent to a group of individuals. I plan to log these requests in a database from the application front end. I have this working

So now I have a database with this set of tasks that need to be processed at different times. What is the best way of doing this?

I was thinking I should set up a background process that would regularly check (every 15 minutes) the database and process any task that needs to be completed.

A similar question was addressed here: http://www.vbforums.com/showthread.p...ground+process

where Gary (gep13) suggested " A better solution, if you have the option, would be to create something like a scheduled task to hit a Web Service, or a Windows Service, to process all the jobs, when there are some in the queue."

I have never dealt with a web service or windows service, so I am not sure what to do with this suggestion. Any pointers would be much appreciated.

This screams out 2 approaches to me.

1. Use WCF with MSMQ. WCF becomes your service and it latches onto an MSMQ Broker. There's no real polling needed then as the WCF Service would simply pick it up when it hits the queue.

2. Use Windows Workflow. You should be able to get away with just this, but if not it can be hooked into MSMQ relatively easy.

If your only tasks are on SQL Server then just create some jobs on the SQL Server.No need for web services or anything else.
I'm not familiar with MSMQ perhaps if Bill Crawley could elaborate more we can have something useful to look at.

Everything is not on the sql server. My tasks are to send out emails / or texts. The solution I am using requires me to send them out sequentially, so I am queueing them up in the database. I also read and process any incoming emails / text, which could initiate some other activity. So I am looking for something that is running in the background. I have not previously used either of the approaches proposed, so I am still doing a lot of research to figure out how to use them. Any pointers/suggestions would be appreciated.

From what I am reading it does not seem that WCF or Windows Workflow would be useful. These seem to be designed to send a request to a separate process that does something and returns a result.

I have 2 things I have to deal with. I have to poll a database on a regular schedule and act on records which have become due (based on a datetime field). I also have to regularly check to see if I have received any new email.

So I need something which is going to trigger these two processes on a regular schedule (say every 15 minutes). I would think this would be called from the Global.asax Application.start. This background process would fire off ever x minutes and call one process to check and handle the database, and another to handle incoming email, then go back to sleep until the next time period. It seems like this could be done all in my aspx app. I just don't know how to create the background app. I am not really returning anything back to the user interface, which is why I don't see the need for WCF or WWF.

Is this approach reasonable? If so how do I create the background portion. If it is not reasonable, how should this be implemented?

No it's not a good approach.You should definitely not use your page to handle these.I would say SQL JOB or Web service or local service or last resort windows scheduler.As i've said i haven't used MSMQ so i cannot express an opinion.You say about emails.There is also the ability to handle emails from sql server.It's rough but it can be done.
So:
"I have to poll a database on a regular schedule and act on records which have become due (based on a datetime field)" 100% SQL job.

"I also have to regularly check to see if I have received any new email." How do you check?If from sql then 100% SQL job.If you check your email account then how do you pass that info into your web app?

"This background process would fire off ever x minutes and call one process to check and handle the database, and another to handle incoming email, then go back to sleep until the next time period"
As i've said.Either SQL JOB or web service or local service or scheduler don't use your pages this will lead to the dark side.

If you check your email account then how do you pass that info into your web app?

When I get an email, I would parse it and do one of a couple of options. The primary two options are make an entry into the database, and send an email (these are the only two options at the moment, but there may be others in the future). The parsing would require some sort of logic to see if it fits some sort of pattern.

I don't really need to send anything back to the web app. All the communication goes through the database.

Also, I am using MySQL (although I could switch to SQL Server if that makes my life easier). I was not aware that it is possible to email out of SQL Server. I will have to look into it.

You have to have some sort of mechanism to parse the email.That is what i asked.Do you have a specific app?
Yes you can email.You can check my posts if you like(as i've said it's hard but it can be done), i don't have the time to do that now, and the example is in one of my posts from 3-5 months ago i think.
Or i could check it next week myself provided that i have time and not absent for some splashing in the Greek islands!

I have not written the parsing app yet. It likely is going to be fairly simple. It will look for a few keywords which will trigger some action. If those are not found there will be some other action.

Thanks for the offer, but I have found some examples already on the web.

One site suggested that using the database server to send email is not a good idea (http://stackoverflow.com/questions/3...from-mysql-5-1)

So it looks like I could totally separate my two apps linked together through the database. The user interface could just act as the UI to the database, and is just focused on adding / modifying the database based on user interaction.

The second app does not have (or need) any web interface. It needs to read and process emails, and process tasks stored in the database table. I do need some logic to read the emails (I have written that) and then parse them, and enter new records into the database. Processing the database tasks does the rest.

This is all new ground for me. Thanks for helping me think through this.

I said you can send emails i didn't value the solution.I would have used it if i knew exactly what i am doing with the database and if everything is handled by the database.Now since you haven't yet created the way to process your emails i have nothing to suggest,yet.

This needs to be run as a service. WCF can be written as standard to run under IIS7 and will be a service. You can if you so choose, wrap the WCF service in a Windows Service this will mean that you are not reliant on a web server since under this scenario you do not require IIS.

WCF can be used to poll the database if you wish, however the point with MSMQ is that it is a Message Queue. Both MSMQ and Workflow can analyse information in an email (it's down to how you code) and can both act accordingly. The Queue approach would work well, since you would place e-mails in a 'master' queue and then filter the data. That is to say, assume the first mail just needs forwarding, then that's what you do. the second mail need's forwarding and an action taken in 3 days time. You forward the mail as normal and you send an 'action' to say an action queue. The action queue would hold the data until the criteria has been met before doing what ever needs to be done. Workflow can work this way as well. It's what workflow was designed for.

google wcf with msmq there are plenty of examples.