I am looking for an options to execute recurring background tasks. The background Task would call the external REST GET request and update the status accordingly in the application database.
Which one of the following would be appropriate, considering that we do not like to maintain separate web.config between the application and the scheduler/task app. Looking for Simple option in .NET/Asp.NET web API context - not looking for any separate installation / 3rd party.
Scheduled task - believe we need to create those many scheduled tasks in a server which points to those many databases? maintainability is a concern?
windows service
Asp.Net background task options
any other better option?
Please provide your insights for this question.
I highly recommend looking at Hangfire to implement background tasks
This works better than a windows service in a cloud environment and supports fire-and-forget and repeat tasks/processing etc and integration is really seamless.
I just noticed your non-3rd party comment, not sure if you mean commercial component, but this is free, via nuget, if that helps?
see: https://www.hangfire.io
Related
I am developing a site in ASP.net (C#) and have the following requirement:
The site should fetch data from an RSS feed every night, perform some calculations and update the DB with the calculated values. How can I achieve this in a shared hosting environment?
The answer that I usually get is to have a Windows Service that does this but I cannot use this as I am not allowed to run Windows Services in my shared hosting environment.
The other alternative that I found was to use the HttpRuntime.Cache as described in https://blog.stackoverflow.com/2008/07/easy-background-tasks-in-aspnet/
However that approach seems to have a lot of cons. Is there any other approach?
At some (most?) shared hosting providers, at least the ones I have used, they allow you to schedule tasks through their control panel. I know discountasp.net does and rackspace as well.
If you provider does have that capability, have it call/load a certain asp.net web page at the designated time, and do its work. For a lot of small tasks, this will be the path of least resistance.
If it doesn't provide that capability, and you are not willing to switch providers, you can always run a scheduled task (use the built in one in windows server) from a machine that is NOT at your ISP, as long as you can get to the database from it. I have used this method as well in the past. Any machine that is reliably on at the right time will do.
Windows Scheduled Tasks:
Impossible in shared hosting if you don't have any dedicated resource. Very limited.
Using hacks like Windows Scheduled Tasks and Control Panel abilities are not nice solutions. They sucks most of the time, they was a headache for us due this years.
Scheduling Web Service:
You can use ATrigger scheduling service in shared hosting. A .Net library is also available to create scheduled tasks without overhead.
Disclaimer: I was among the ATrigger team. It's a freeware and I have not any commercial purpose.
I have an asp.net mvc 2 app, and I need to run a task (call WS, save into db) once a day. What is the suggested way for this? One thing, I have a feeling I would like to execute this task from within the webapp.
Does anyone have any suggestions:
I was considering .net quartz or regular System.Timers.Timer?
Does anyone see any problems?
Any other better solutions?
Thanks a lot
--MB
Why do you want to run this from the webapp? You have no way of even knowing if the webapp will be running at the required time. I would recommend you look at Windows Services
web apps are not the best host for a scheduled task. Unless you implement a system to keep the process awake, there's no chance to be sure your schedule will be executed.
Quartz.net is good for that.
It consists in a core module which you can use in your web app to save tasks and a server (windows service) module which executes your scheduled jobs.
I've recently implemented my own windows services and used Sql Server as storage for my scheduled jobs. Everything works pretty well, even if, I had to struggle a little bit to put things together.
The documentations is not always so clear.
Have a look at Quartz.Net, which is available as a NuGet package or from their site.
There are lots of examples of how to set these up, they are very flexible, you just have to define a class which implements IJob with a single Execute() method which gets fired by your choice of triggers.
You could also consider using Windows Workflow Foundation.
I have downloaded TheWorldsWorstStackOverflowClone. One of the project is called TheWorldWorsts.ApiWrapper, which basically is the core of accessing the API. There is a class called ApiProxy.cs, which has all the methods for the API call. This is good.
Now what I want to do is I am trying to collect data from this API interface and store it in a database. I know the limit to the API call is 10k per day. I.e: I want to be able to call the method in the ApiProxy class 10k times per day, done automatically. How can I do this?
The non-automatic way would be to create a dummy site where when every time I access the site it does all that process, but this not efficient. It seems that I have to write some kind of a scheduler by deploying a web service, but that is too complicated... as explained here. Any other simpler methods?
A Windows Service or Desktop App might be a better solution than a web application. You are not deploying a web service, you are consuming one using a proxy class, and this does not require you to have a web server or a web site.
You could use a web application to control and monitor progress as your service downloads data, but the actual work is long running and needs to be offloaded to another process or thread so you can tell the user whats going on.
Check out this one
http://stacky.codeplex.com/
This looks what you need, though I am facing some debugging issues, but hope you can figure it out.
I am writing a web application in ASP.NET 3.5 that takes care of some basic data entry scenarios. There is also a component to the application that needs to continuously poll some data and perform actions based on business logic.
What is the best way to implement the "polling" component? It needs to run and check the data every couple of minutes or so.
I have seen a couple of different options in the past:
The web application starts a background thread that will always run while the web application does. (The implementation I saw started the thread in the Application_Start event.)
Create a windows service that is always running
What are the benefits to either of these options? Are there additional options?
I am leaning toward a windows service because it is separated and can run on a different server (more scalable) as well as there is more control over when it is started/stopped, etc. However, I feel like the compactness of having the "background" logic running in the process of the web application might make the entire solution more understandable.
I'd go for the separate Windows service primarily for the reasons you give:
You can run it on a different server if necessary.
You can start and stop it independently of the web site.
I'd also add that it could well have some impact on the performance of the web site itself - something you want to avoid.
The buzz-word here is "separation of concerns". The web site is concerned with presenting the data to the user, the service with checking the integrity of the data.
You can also update the web site and service independently of each other should you need to.
I was going to suggest that you look at a scheduled task and let Windows control when the process runs, but I re-read your question and noted that you wanted the checks to run every couple of minutes. The overhead of starting the process might be too great in this case - though some experimentation would probably prove this one way or the other.
If you use a scheduled task there's also the possibility that you could start the next check before the current one has finished - something you can code for if you're in complete control.
Why not just use a console app that has no ui? Can do all that the windows service can and is much easier to debug and maintain. I would not do a windows service unless you absolutely have to.
You might find that the SQL Server job scheduler sufficient for what you want.
Console application does not do well in this case. I wrote a TAPI application which has to stay in the background and intercept incoming calls. But it did it only once because the tapi manager got GCed and was never available for the second incoming call.
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?
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.
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.
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.
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.
Use the Windows Scheduled Tasks or create a Windows Service that does the scheduling itself.