Azure Functions allow you to execute small, lean pieces of back-end code without worrying about a whole application or the infrastructure to host and run the code. There are different types of Azure Function apps, all of which are based on executing code when a different trigger or event occurs.

Since you only need to worry about the chunk of code that will execute, Azure Function apps are a useful part of Azure’s serverless computing offering. You only pay for when the code runs, and Azure handles scaling up and down as needed.

A Use Case for Creating Timer Trigger

I was recently working with a client who had Dynamics CRM Online and wanted a weekly process that looked at their CRM data and emailed lead info to their salespeople. Since CRM Online didn’t give me direct access to the underlying server, I needed a separate place to host the custom code that would send emails.

I didn’t want to have to manage an entire one-off VM, its own Windows Task Scheduler job, and custom logging visibility just for a weekly job that ran specific repetitive code.

This called for a Timer Trigger type of Azure Function app. This function allowed us to schedule a custom chunk of code to execute on whatever schedule the client wanted and gain immediate visibility of logging in the Azure portal.

How to Set Up Azure Function App

After you install the Azure SDK tools for Visual Studio, you can create new Projects based on an Azure Function template.

This example uses the Timer Trigger type of Azure Function, but there are other options.

The entry point is a single Run method. You can directly annotate it to setup the schedule in which you want to run, and you have access to an out of the box logger.

These would run the code at the first second of every minute. There is a ton of flexibility with the scheduling.

When you run the app, Visual Studio uses Azure Functions CLI tools to setup up a local Function App host to run your code, and you can start debugging like normal.

All you need to worry about with this method is your specific logic. You don’t have to deal with any of the infrastructures for triggering, logging, hosting, and scaling.

You can easily deploy directly to Azure from inside Visual Studio using your Azure login and by selecting the Azure Function or creating a new one.

After it’s deployed, you can easily monitor the Invocations, and any messages the code logs.

It’s just that easy! And all you have to think about is the code that would run.

Additional Tips when Using Azure Function App

Instead of the common .NET App.config file, Function Apps use a “local.settings.json” file. Further, this file is only used when debugging the app locally. When you deploy your app to Azure, it does not include this file’s settings; you need to recreate the settings in the Function App in the Azure portal.

When you’re deploying code to the Azure Function App, rather than the less-common method of writing code directly inside the Azure portal, some settings will be disabled in the Azure portal and can only be changed by modifying your source code and re-deploying. It can be a little unclear inside the Azure portal. For example, to change the schedule/frequency, or to disable the trigger completely, you need to modify these settings in the source code and re-deploy; changing these settings in the portal will be ignored.

Next Steps

Since the app is now living as an Azure Function App, we could go further and leverage other Azure resources. Such as Azure Key Vault to secure our app’s configuration, or Azure Application Insights to get even more information from the app’s logs.