I have an Azure timer triggered function scheduled to run every 3 months in production. However in test environment I'd like it to run on start up, every time it is triggered.
At the moment I have:
[TimerTrigger("%TimerInterval%", RunOnStartup = false)]
I don't really want to change the RunonStartup to true but wondered if there's a way of setting this in the configuration?
Is it possible to do something like:
RunOnStartup = "%RunOnStartUpBool%" and set that in appsettings?
Update 2022-03-30: My previous answer was updating your code to use an #IF Debug pre-processor directive as a way to switch into the RunOnStartup=true method parameter. As of 2022, you can bypass that ungainly workaround and just select an option in the VS Code Azure Functions extension! That seems less complex. There is more information here.
Another alternative would be logging into the Azure portal, navigating to your function app and using the function's Test/Run tab.
OLD ANSWER: There is a good SO question with multiple answers to this same question here.
My test environment is normally my local environment. So if we want to write code that ONLY runs on your local environment and not in production we could use a a preprocessor directive in the middle of the method signature that only sets RunOnStartup=true when you are in the debug mode.
public static void Run([TimerTrigger("%TimerInterval%"
#if DEBUG
,RunOnStartup=true // When debugging... run the job as soon as we press debug, no need to wait for the timer.
#endif
)]TimerInfo myTimer)
{
Explanation: During local development (debug) the #if DEBUG block is activated.
It enables the RunOnStartup=true parameter. In production (not debug) the #if DEBUG block is hidden.
Clearly not the prettiest code. But much better than the alternatives ... such as having to wait on the timer trigger interval during dev.
You can not set RunOnStartup dynamically from configuration/environment variable at runtime. But you can solve your problem in some other way since your purpose is to trigger it manually at startup (or anytime). You can manually trigger the function by some specialized http call as described below. You can do that let's say from your deployment pipeline of test environment as a post deployment step (or any other means you prefer).
To run a non HTTP-triggered function (like in this case it's timer triggered), you need a way to send a request to Azure to run the function. The URL used to make this request takes a specific form.
Host name: The function app's public location that is made up from the function app's name plus azurewebsites.net or your custom domain.
Folder path: To access non HTTP-triggered functions via an HTTP request, you have to send the request through the folders admin/functions.
Function name: The name of the function you want to run.
You use this request location along with the function's "master key" as x-functions-key header in the POST request to Azure to run the function. Note Content-Type header should be set as application/json
For details, refer Manually run a non HTTP-triggered function
Related
In my dev environment, I have an Azure Functions with 21 functions and the app plan is consumption.
Some functions have a timer trigger and at the end of the process each function sends an email. I have 2 type of timer trigger:
run a function every 20 minutes
run a function once at a particular time in the night
Every 20 minutes the function is doing what I expect. Great.
The problem I'm facing is with the function that they have to start at a particular time. Basically, they don't start until I open the portal and do something on the Azure Function (for example open the monitor for one of them).
In the code point of view, all functions with the timer trigger are defined like that:
[FunctionName("invoiceMonthlyGeneratorTimer")]
public void Run([TimerTrigger("%Timers:GenerateMonthlyInvoices%")] TimerInfo myTimer)
{
// ..
}
[FunctionName("invoiceDunningTimer")]
public async Task Run([TimerTrigger("%Timers:DunningTimer%")] TimerInfo timer)
{
// ...
}
The configuration of the timer is in the settings file like:
"Timers": {
"DunningTimer": "0 0 4 * * *",
"GenerateMonthlyInvoices": "0 0 4 * * *"
}
Generally, speaking, this approach was working in dev environment and it is working perfectly in the production environment.
Because each function sends an email, I expect each morning to find in my inbox some emails but it doesn't happen. Then, I open the Azure portal to see the logs and the monitor.
Open the Azure function in the portal.
Open the monitor for a function
Voila, after a couple of seconds, I start to receive the email for all services! In the production environment I don't have all the function I have in dev because I want to test before deploying. In prod the functions are working fine and start at the right time.
If I look at Application Insights, I can find only the logs for the time I opened the monitor.
There is one interesting thing in the log:
Trigger Details: UnscheduledInvocationReason: IsPastDue, OriginalSchedule: 2020-07-24T05:00:00.0000000+00:00
Update
Apparently, you can't have more than a couple of timer triggers in the same Azure Functions. I opened an issue on Github, so if other devs are facing the same. Something similar with HTTP triggers, look this post.
There are too many functions in your function app, they may interact each other. I met similar problem with this, in that case, the timer trigger functions in one function app and did not work. But when i deploy them to different function apps, they work fine. so you can try to deploy your second function to another function app.
And I suggest you report this problem to Microsoft, they can know more information about this problem, and may have a better solution.
I have a system for sending E-mails to users by a specific time .
built in ASP.NET MVC4 and has an action result "function" for checking the time of messages and send it if the day of the message is today .
how can I call this action result (daily) -like a scheduler- in efficient way ?
Thanks.
Whilst a separate service / application would be better, you could use wget.
GNU Wget is a free software package for retrieving files using HTTP,
HTTPS and FTP, the most widely-used Internet protocols. It is a
non-interactive commandline tool, so it may easily be called from
scripts, cron jobs, terminals without X-Windows support, etc.
You would then do something like:
"C:\Program Files (x86)\GnuWin32\bin\wget.exe" --no-check-certificate https://www.exammple.com/YouController/YourAction -O NUL
in a .bat file and set that to run via a windows Scheduled task at the time you require (assuming you don't need to run it less than every 60 seconds - if you do, let me know as I have another way around this using a windows service to call the bat file instead).
Omitting the -O NUL part would also save the output so you could see if everything ran successfully by doing:
public ActionResult YourAction()
{
//Do your code, get some stats that show it ran properly.
return Content("Return your stats here.");
}
from your controller action.
More efficient will be when you create new application as Windows Service. There u can easy set code to start at specific time. in this solution you will have more flexibility and independent. You can start hire : Windows Service to run a function at specified time
You could create a small console application that just calls the API do send out the emails. You can then schedule the console app to run at a specific time using the Windows Scheduler; you can even have it run without showing the console window. See here or here for details on how to schedule a task.
Use Azure Functions, that's exactly what it was built for. It's really good.
https://learn.microsoft.com/en-us/azure/azure-functions/functions-overview
I have written some code in the application_start() method in my global.asax file. It does not get called when I deploy my application on IIS server. The code is accessible when I run it in the .NET framework.
I've tried to restart the application many times, but it's still not working.
I've also tried the suggestion from the following link.
Application_Start not firing?
There are few things you need to know before you are trying to debug Appplication_Start. There are -
One : When the code executes and why it is almost impossible to debug by attaching to it.
The application start method is executed when the application pool starts and your website is being started up for the first time. If you deploy new deliverables to IIS, then IIS might restart it itself, but there is no guarantee that it will. So, deploying new codes does not guarantee that it will restart the pool and he execution of application start. You should restart your application pool to guarantee execution of application start.
While debugging IIS applications, Visual Studio attaches itself to a process something named w3wp.exe or similart (I forgot the actual executable name), which is the worker process and only available after, remember after, your application pool is up and your site is up. So, in other words, if you are seeing this in service list, then the application start has already been executed and attaching to it will not give you a chance to debug it. It is kind of a tug of war with time.
So, in other words, it is kind of impossible to debug application start unless you are very very quick.
Two, the solution 1 - With Dev Server
Launch your application in visual studio with Asp.net development server or IIS express, then you will be able to debug. But if you really want to debug on IIS, then check the next section
Two, the solution 2 - With IIS
There is a library in the name System.Diagnostics, Debuggerand it has a nice way to call debugger in code. You can read it here - http://msdn.microsoft.com/en-us/library/system.diagnostics.debugger.break(v=vs.110).aspx
Modify you application start with this -
public void Application_Start(){
....... //other codes
Debugger.Break() or Debugger.Launch()
}
When this line executes, IIS will halt execution, and will show you a debugger selector window (similar to the one attached), keep your solution open in vs and select that vs from the list, will be able to debug as usual... :)
In case you are using windows 8 and the debugger does not launch, read this article to enable it -
http://blogs.msdn.com/b/mapo/archive/2013/11/07/debugger-launch-not-displaying-jit-debugger-selection-popup-on-windows-8-8-1.aspx
Three: A very important thing
I noticed that you said, you are adding db entries in Application_Start. You should keep in mind that, Application_Start does not have a HttpContext, ViewContext, So your db access code may fail for so many others reasons.
Make sure that the Global.asax file is actually deployed to the destination folder in the root. If the file is not present then the code behind you have written for Application_Start will never be called.
Also make sure the signature is correct
public class Global : System.Web.HttpApplication {
protected void Application_Start(object sender, EventArgs e) {/*do something here like logging so you know it was called*/}
}
If you are running Server 2008R2 (or earlier) and/or IIS 7.5, you might want to look into the Application Initialization module. This can be downloaded here:
www.iis.net/downloads/microsoft/application-initialization
With IIS versions prior to 8.0, the application start is not called until the first web request arrives. I'm reading your question as you want your application start to be fired before the first web request, yes?
Here is a fantastic guide to configuring this module (if it applies to you):
https://blogs.msdn.microsoft.com/benjaminperkins/2014/01/07/configure-the-iis-application-initialization-module/
The key takeaways is that you need to set your app pool to 'AlwaysRunning' instead of 'OnDemand'. You also need to set a preloadEnabled flag for your website. Once both of these are done, fire off an iisreset and you should see the results of your application start (look in the database since it's writing there).
Other answers are relevant as well, in that this is tough to debug and you're missing all the niceties you're used to such as a httpcontext in app start.
If you are running IIS 8.0 - you should still read the above link to configure preloading.
This did work for me:
Menu -> Build -> Clean Solution
Menu -> Build -> Rebuild Solution
Then, Application_Start() was fired only for the first time.
In my case in production environment App_global.asax.compiled was missing and all content of global.asax not fired.
I have a C# console app called during the startup of a WebRole to perform customized instrumentation. I'd like for this program to be able to read the latest values from Service Config and act accordingly.
I've setup the startup script that calls my .EXE to run in elevated mode. I've added a reference to Azure's ServiceRuntime to the console app, however I'm getting the following error: role discovery data is unavailable
If you've put calling this executable as a start-up task in the .csdef, then the information you're asking for may not be available as the role has not yet been set up (see lifecycle of Web/Worker role).
This could also be the problem if you're calling the executable within OnStart in WebRole.cs - as IISConfigurator is called asynchronously with OnStart.
For the startup task, one work around for this is detailed at http://mvolo.com/configure-iis-websites-windows-azure-startup-tasks-appcmd/ (although it deals with changing IIS configuration).
For the WebRole issue, you could overload Run() and call your executable from there - possibly with retries like:
while (!RoleEnvironment.IsAvailable) {
Thread.Sleep(1000);
}
RunExecutable();
I would like to run a time consuming script (to update a database from a 3rd party API) at regular intervals. I was wondering what the best practice for this would be:
What should the 'script' be - an ASP.NET service? Bearing in mind I am on shared hosting, this may not be possible (but I would like to know).
How could the script be scheduled to run at regular intervals/at set time automatically?
Thanks in advance!
Some options for this:
Use a separate thread that keeps running all the time - and does the update on time (and then sleeps).
Use a timer and trigger the update event.
Use a Cache expiration trigger, but test this so that it keeps running without users visiting the site.
I would suggest checking out http://www.beansoftware.com/ASP.NET-Tutorials/Scheduled-Tasks.aspx for more details on these methods.
There is no way you can guarantee that something runs e.g. every night in a normal IIS setup. Batch jobs are thus a pain to handle. The only "mode" of execution for IIS is requests. If your application has no requests it doesn't run at all so IIS does not spend any resources on executing code in your application, i.e. it can unload it entirely.
If you have your own host, you would typically create a windows service to run your background tasks. I believe the same is possible in Azure. But for a standard sharesd IIS host, you basically can't setup a scheduled background task.
One of the simplest hacks is to setup a protected service that executes the job when it gets a request. Then you can make sure an external caller calls into your service at the required intervals.
What you can do is add a System.Timers.Timer in Global.asax.
System.Threading.Timer timer = new System.Threading.Timer(new TimerCallback(TimerElapsed), null, new Timespan(0), new Timespan(24, 0, 0));
// This will run every 24 hours.
private void TimerElapsed(object o)
{
// Do stuff.
}
In IISManager, enable HTTP-Keep Alives for your application.
In IIS Manager, select Http Response Headers Module, open it and in the Actions Pane, select Set Common Headers and in there select Enable Http Keep Alives.
Also, check for a setting of your application pool -
Select the application pool of your application, select Advanced Settings from the right Actions Tab.
In there there is a setting called - Idle Timeout (minutes)
By default it is 20 Minutes. Make it something like 60 Minutes or increase it even more and check.