I have a very basic question.
I have built with R a script than can send me reports by email.
I then used task scheduler to send those emails on specific times.
But now I would like to automate more frequently these scripts (let's say every 2 hours) and to only receive an email when the alert I created in my script (a flag) is on, and this even when my pc is off.
As task scheduler won't work, does that mean I need a server or something ?
Does it have a cost ? I am complete newbie in that area. Thank you.
Unfortunately, you would need a separate server for when your computer is off. I might suggest the Free Tier services from Amazon Web Services.
Related
Background: This is largely a learning exercise. I am working on a task scheduling program. I have been asked to make it so that the application I am working on will send emails to users telling them they have messages waiting to be looked at. I already have the part that sends emails working right, but that only works when the user is actively on a page. I essentially want to make it so that the server decides to send emails at a certain time for instance midnight to tell users how many messages and meetings they have unread updates on during that day. I am not familiar with how to make the app do work when not receiving input from the user.
What I am looking for: How do I make ASP run a function on at a scheduled time.
Here we had difficulties with the functionality of a browser when scheduling the browser (starting with a specific page) on the server.
A Temporary solution was to make one page in your project that reloads after waiting 5 minutes <META http-equiv='refresh' content='6000'>, and start this page on a client or on the server. Note: The copy running on the server stops when rebooting the server.
The final solution was to make a .Net package using the right server-side objects, and schedule this package in task scheduler.
Use Windows Schedule Task to get IE to run the page at a scheduled interval.
e.g.
You will have to make sure that it runs unattended and with an account that is allowed to run it. Also you will want the page to close the window after having finished.
(How to configure and what Schedule Task looks like varies depending on your Windows Version)
I have some users in my web site that have a task with a deadline. I want to email them when their deadline is finish. but this action must be perform automatically. Is there any way to make something like that? should i use global in asp, or there is a better way?
You really should write either a scheduled task or a Windows service to perform that sort of action. An ASP.NET website will happily go to sleep if there are no requests, and you really don't want to have long running threads on a web server.
(There is a 'trick' using cache expiration to get scheduled callbacks to your code, try it if you can't use the options below.)
Write an endpoint (URL like /CheckTaskDeadline.ashx) that when called will check for task deadlines and trigger an action (send email). Add a scheduled task that makes a request for the endpoint every 5 minutes, or every hour (whatever granularity you need for reliably triggering close to the deadline). Use curl or wget to 'ping' the URL.
If you don't have access to the machine, sometimes you can create scheduled tasks using your webhost's configuration panel. If you don't, ask them nicely :-). A good hosting service provider should be able to help you. Otherwise, consider moving the application to another host, or get a separate 'ping' service, like Pingdom.
I have a site that I'm working on. Say I need something to run every... say... 30 minutes, how would I get just a simple thing to run like that?
EDIT
I'll be hosting this online with another company. This is why I am not making it as a separate scheduled program.
If you need a process to be run at pre-defined intervals you might be better off using the windows task scheduler, or to create a windows service with a timer. ASP.NET applications aren't ideal for doing this sort of thing, since they are vulnerable to restarts and so you can't guarantee that the process will run at the given interval.
Windows scheduled tasks and services are ideal for this but if you want to run database queries at specified times then I would suggest using SQL Server Agent if you have access to this.
I don't know of any way to reliably do this using ASP.NET. My understanding is: after a certain period of inactivity, IIS will unload your website/webspp from memory. If that happens, your periodic job very likely won't execute, regardless of what technique you used to configure it.
You could, of course, set up some kind of automated system on your own, which occasionally pings your site to keep it from being unloaded. But if you're doing that anyway, well you could just set it up to do the desired operation at the desired interval. :)
I need to invoke a long running task from an ASP.NET page, and allow the user to view the tasks progress as it executes.
In my current case I want to import data from a series of data files into a database, but this involves a fair amount of processing. I would like the user to see how far through the files the task is, and any problems encountered along the way.
Due to limited processing resources I would like to queue the requests for this service.
I have recently looked at Windows Workflow and wondered if it might offer a solution?
I am thinking of a solution that might look like:
ASP.NET AJAX page -> WCF Service -> MSMQ -> Workflow Service *or* Windows Service
Does anyone have any ideas, experience or have done this sort of thing before?
I've got a book that covers explicitly how to integrate WF (WorkFlow) and WCF. It's too much to post here, obviously. I think your question deserves a longer answer than can readily be answered fully on this forum, but Microsoft offers some guidance.
And a Google search for "WCF and WF" turns up plenty of results.
I did have an app under development where we used a similar process using MSMQ. The idea was to deliver emergency messages to all of our stores in case of product recalls, or known issues that affect a large number of stores. It was developed and testing OK.
We ended up not using MSMQ because of a business requirement - we needed to know if a message was not received immediately so that we could call the store, rather than just letting the store get it when their PC was able to pick up the message from the queue. However, it did work very well.
The article I linked to above is a good place to start.
Our current design, the one that we went live with, does exactly what you asked about a Windows service.
We have a web page to enter messages and pick distribution lists. - these are saved in a database
we have a separate Windows service (We call it the AlertSender) that polls the database and checks for new messages.
The store level PCs have a Windows service that hosts a WCF client that listens for messages (the AlertListener)
When the AlertSender finds messages that need to go out, it sends them to the AlertListener, which is responsible for displaying the message to the stores and playing an alert sound.
As the messages are sent, the AlertSender updates the status of the message in the database.
As stores receive the message, a co-worker enters their employee # and clicks a button to acknowledge that they've received the message. (Critical business requirement for us because if all stores don't get the message we may need to physically call them to have them remove tainted product from shelves, etc.)
Finally, our administrative piece has a report (ASP.NET) tied to an AlertId that shows all of the pending messages, and their status.
You could have the back-end import process write status records to the database as it completes sections of the task, and the web-app could simply poll the database at arbitrary intervals, and update a progress-bar or otherwise tick off tasks as they're completed, whatever is appropriate in the UI.
I'm writing an application where the user will create an appointment, and instantly get an email confirming their appointment. I'd also like to send an email the day of their appointment, to remind them to actually show up.
I'm in ASP.NET (2.0) on MS SQL . The immediate email is no problem, but I'm not sure about the best way to address the reminder email. Basically, I can think of three approaches:
Set up a SQL job that runs every night, kicking off SQL emails to people that have appointments that day.
Somehow send the email with a "do not deliver before" flag, although this seems like something I might be inventing.
Write another application that runs at a certain time every night.
Am I missing something obvious? How can I accomplish this?
Choice #1 would be the best option, create a table of emails to send, and update the table as you send each email. It's also best not to delete the entry but mark it as sent, you never know when you'll have a problem oneday and want to resend out emails, I've seen this happen many times in similar setups.
One caution - tightly coupling the transmission of the initial email in the web application can result in a brittle architecture (e.g. SMTP server not available) - and lost messages.
You can introduce an abstraction layer via an MSMQ for both the initial and the reminder email - and have a service sweeping the queue on a scheduled basis. The initial message can be flagged with an attribute that means "SEND NOW" - the reminder message can be flagged as "SCHEDULED" - and the sweeper simply needs to send any messages that it finds that are of the "SEND NOW" or that are "SCHEDULED" and have a toBeSentDate >= the current date. Once the message is successfully sent - the unit of work can be concluded by deleting the message from the queue.
This approach ensures messages are not lost - and enables the distribution of load to off-peak hours by adjusting the service polling interval.
As Rob Williams points out - my suggestion of MSMQ is a bit of overkill for this specific question...but it is a viable approach to keep in mind when you start looking at problems of scale - and you want (or need) to minimize/reduce database read/write activity (esepcially during peak processing periods).
Hat tip to Rob.
For every larger project I usually also create a service which performs regular or periodical tasks.
The service updates its status and time of last execution somewhere in the database, so that the information is available for applications.
For example, the application posts commands to a command queue, and the service processes them at the schedule time.
I find this solution easier to handle than SQL Server Tasks or Jobs, since it's only a single service that you need to install, rather than ensuring all required Jobs are set up correctly.
Also, as the service is written in C#, I have a more powerful programming language (plus libraries) at hand than T-SQL.
If it's really pure T-SQL stuff that needs to be handled, there will be a Execute_Daily stored procedure that the service is going to call on date change.
Create a separate batch service, as others have suggested, but use it to send ALL of the emails.
The web app should record the need to send notifications in a database table, both for the immediate notice and for the reminder notice, with both records annotated with the desired send date/time.
Using MSMQ is overkill--you already have a database and a simple application. As the complexity grows, MSMQ or something similar might help with that complexity and scalability.
The service should periodically (every few minutes to a few hours) scan the database table for notifications (emails) to send in the near future, send them, and mark them as sent if successful. You could eventually leverage this to also send text messages (SMS) or instant messages (IMs), etc.
While you are at it, you should consider using the Command design pattern, and implement this service as a reusable Command executor. I have done this recently with a web application that needs to keep real estate listing (MLS) data synchronized with a third-party provider.
Your option 2 certainly seems like something you are inventing. I know that my mail system won't hold messages for future delivery if you were to send me something like that.
I don't think you're missing anything obvious. You will need something that runs the day of the appointment to send emails. Whether that might be better as a SQL job or as a separate application would be up to your application architecture.
I would recommend the first option, using either an SQL or other application to run automatically every day to send the e-mails. It's simple, and it works.
Microsoft Office has a delivery delay feature, but I think that is an Outlook thing rather than an Exchange/Mail Server thing, so you're going to have to go with option 1 or 3. Or option 4 would be to write a service. That way you won't have to worry about scheduled tasks to get the option 3 application to run.
If you are planning on having this app hosted at a cheap hosting service (like GoDaddy), then what I'd recommend is to spin off a worker thread in Global.asax at Application_Start and having it sleep, wake-up, send emails, sleep...
Because you won't be able to run something on the SQL Server machine, and you won't be able to install your own service.
I do this, and it works fine.