Understanding TimerTriggers in Azure Functions

Azure Functions are Microsoft’s way of offering serverless compute.

In essence, Azure Functions are just source-code functions, running on PaaS servers, which are triggered by some external mechanism. You just deploy functions and do not care about the infrastructure underneath it.

Multiple programming languages are supported e.g. C#, Javascript, Java to write your function in.

Multiple kinds of triggers are available. Most of them are related to some event in another Azure resource. For example, adding a blob in Azure Blob Storage (a BlobTrigger) or receiving a message in an Azure Event Hub can trigger the function (a EventHubTrigger).

A function can also expose an external HTTP endpoint. Then a Rest call on that endpoint triggers the function (HttpTrigger).

All these triggers are scalable. The more triggers are fired on the Azure Function, the more functions are executed. If you choose for a consumption plan this can even result in a scale-out on the number of servers (which you do not have configured).

Azure Functions also offers a TimerTrigger. Functions are just triggered by a … timer.

This seems simple but the Timer trigger behaves a little bit differently when executed.

Let’s try understanding the Timer Trigger.

Doorgaan met het lezen van “Understanding TimerTriggers in Azure Functions”

Where is my logging in Azure Mobile Apps?

Microsoft has two solutions for mBaas at this moment. The first and already existing “mobile Backend as a Service” is Azure Mobile Services. but a few weeks ago a new one arrived: Azure App Service.

Azure App Service is dividend into four parts:

  1. Web Apps
  2. Mobile Apps
  3. API Apps
  4. Logic Apps

API Apps and Logic Apps are advertised as brand new. But Web apps should be nothing more then Azure Websites and Mobile apps should be an equivalent of Mobile Services.

Although Azure App Service just arrived and it is still in preview (..) it is quite clear that things have changed. First of all it is recommended not to mix AMS specific Nuget packages with an App Service. For example adding the “Microsoft Azure Mobile Services .NET Backend Azure Storage Extension” to a Mobile App is not a good idea and will result in many conflicts. Just use the good old “Windows Azure Storage” package.

But for me the first thing that I was missing, when I managed to generate a Mobile App, was the log screen. You know:


Yes, it’s slow and filtering is missing but at least you know what happens on the server. And it’s great for a demo.

In Mobile apps, this page is not there. But Mobile Apps has other goodies. If you go in Visual Studio (with Azure SDK 2.5.1) to the Server Explorer, it is possible to look at Log files:


But even if you use something like:

Services.Log.Info("blablabla info");
Services.Log.Warn("blablabla warn");
Services.Log.Error("Ablablabla error");

the log files are not filling up with the expected messages…

It turns out you just have to activate it first.

Go to the new portal and if you drill down into the settings of your Mobile app, you will finally find these diagnostics settings:


Just ignore everything but the switch and dropdown in the red box 🙂

Flip the switch and select the right diagnostics level. And once the changes have been saved, you start getting logging (just keep refreshing):


And this is not really cluttering your logging. The setting will be disabled after 12 hours automatically.

And it even get better. The new portal also support streaming logbooks. You litterally see the message appear in the portal:


So you can test or diagnose without any delay!

One annoying thing is that changing the diagnostics level in the portal using the drowdown, does not active the save button at this moment! Seems to be a bug which is easy to fix. For now, before changing level, first disable and then re-enable the service.

For more detailed information look here.