Azure Web Jobs — Creating your first Azure Web Job from Scratch

9 min readApr 17, 2017

So, you have just created your first Web App in Azure, and it is working like a charm. You have all the scalability you need and you know exactly how to store your data in the many options that Azure provide. What else do you need? Well, what will you do if you need to run some asynchronous background processing, like processing images or batch data? That is when Azure Web Jobs comes in handy.

What are Azure Web Jobs?

Straight from Azure documentation web site:

WebJobs is a feature of Azure App Service that enables you to run a program or script in the same context as a web app, API app, or mobile app. The purpose of the WebJobs SDK is to simplify the code you write for common tasks that a WebJob can perform, such as image processing, queue processing, RSS aggregation, file maintenance, and sending emails.

So, as you can see, it can perfectly fit the role of asynchronous background processing and with one interesting advantage, Web Jobs have very powerful integration with other Azure Services like the Service Bus and the Storage Services, making it incredibly easy not only to read/write data to this services but also to use them as TRIGGERS, avoiding the use of scheduled processing.

Let’s begin.

Creating your first ‘Azure Web Job’ from Scratch

The idea here is to create a simple Web Job that will be triggered after an item is added to an Azure Queue, and after very little parsing, save it to the Azure Tables Service.

The Setup

The first thing we are going to need is an Azure Account. If you don’t already have one, you can create one here, for free. Then we will install the Azure CLI 2.0, the installation instructions for all platforms can be found here. You may also want to install the Azure Storage Explorer, a tool that we will use to manage our Storage Account for testing.

Now we need to setup the resources in Azure to which the Web Job will connect. I’ll give you a list of commands from the Azure CLI that must be execute in a shell prompt.

First things first, we need to login to Azure through the console.

# After executing the command, follow the on-screen instructions to login
az login

Then we need to create the Resource Group that will group all our resources.

# Create the Resource Group
az group create -l WestEurope -n AzureCoderResources

# Wait until the Resource Group is created
az group wait --created -n AzureCoderResources

Storage Account

Next step, create the storage account.

# Create the Account
az storage account create -l WestEurope -n azurecoderstorage -g AzureCoderResources --sku Standard_LRS

Then we create the Queue, that will be the source for our data, and the Table, which will be the destination of the processed data.

# Get the Storage Account Connection String
az storage account show-connection-string -n azurecoderstorage -g AzureCoderResources

# Create the Queue
az storage queue create -n azure-coder-queue --connection-string <Storage Connection String>

# Create the Table
az storage table create -n AzureCoderTable --connection-string <Storage Connection String>

That’s all we need in the Storage service. Now we need to create the App that will host our Web Jobs.

App Service

# First, let's create the App Service Plan
## We are using the Standard Princing Tier (B1) because we are going to setup the "Always On" setting

az appservice plan create -n AzureCoderServicePlan -g AzureCoderResources -l WestEurope

# Create the Web App
az appservice web create -n AzureCoderApp -p AzureCoderServicePlan -g AzureCoderResources

# Configure the App Service
az appservice web config update --always-on true --php-version Off -n AzureCoderApp -g AzureCoderResources

And last, but not least, let’s configure our Connection Strings for the App:

# Get the Connection String
az storage account show-connection-string -n azurecoderstorage -g AzureCoderResources

# Create the Configurations in the Web App
appservice web config appsettings update --settings AzureWebJobsDashboard=<Connection String> AzureWebJobsStorage=<Connection String> -g AzureCoderResources -n AzureCoderApp

And that is it for the Setup. Now, we can begin the coding.

The Coding

For the coding part we can use whatever code editor we prefer. I will use Visual Studio Code, as it offers great support for coding C#.

As for the programming language, you may be surprised to know that Azure supports a lot of programming/scripting languages in the Web Jobs SDK, so you can choose the one you like the most. For this exercise, I will use C# because I feel like doing so :)

Start the Project

As I want this article to be as multi platform as possible, I will create a new project using the dotnet CLI. Open a shell prompt, navigate to the directory of your Web Job and type the following command:

dotnet new console -lang C#

Unfortunately the Web Jobs SDK has no support yet for the .NET Core Framework, so we have to make a small modification to the .csproj file, so we can use .NET Framework v4.5x.

<TargetFramework>net45</TargetFramework>

The final file should look like this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net45</TargetFramework>
  </PropertyGroup>
</Project>

It is important to understand that a .NET Core Application can be executed by a Web Job, it only cannot make use of the Web Jobs SDK, which makes it much easier to integrate with other Azure Services

Azure Web Jobs SDK

Back to the shell prompt, we need to do three things. Add the Web Jobs SDK Package, restore the packages and build the project.

# Include the SDK Package
dotnet add package Microsoft.Azure.WebJobs

# Restore all the Dependencies
dotnet restore

# Build the Project
dotnet build

Code Host

It is worth mentioning now that one Web Job project has, at least, two main components:

The Code Host
This is the Entrypoint for the application, and this is where we should do all the configuration for our Web Job
A Trigger
Our project must have at least one Trigger, but it can have many others. In this case we will use only one trigger, fired by a new entry in our Queue.

Let’s start with the Code Host, which will be placed in the Main method of our code and will be the starting point of the application

using Microsoft.Azure.WebJobs;

namespace AzureCoderWebJob
{
    class Program
    {
        static void Main(string[] args)
        {
            new JobHost().RunAndBlock();
        }
    }
}

That’s it :D

No! I am not. The Host is, as the name implies, a piece of code that will configure your web job and control the lifetime of the code. It can be a lot bigger than this, including all sorts of configurations, but that is all we need for a simple Web Job.

The Trigger

The trigger is where the real business logic of our Web Job live or, at least, where it begin. In our case we will have a single method that takes a QueueTrigger and records the data to a Table. The table will also be represented through a parameter, to which we will save the data.

This is the method code:

using System.IO;
using Microsoft.Azure.WebJobs;
using Microsoft.WindowsAzure.Storage.Table;

namespace AzureCoderWebJob
{
    public class WebJob
    {
        public static void ProcessQueue(
            [QueueTrigger("azure-coder-queue")]QueueModel message,
            [Table("AzureCoderTable")]out DataModel model,
            TextWriter log)
        {
            log.WriteLine($"Found message {message.LastName}, {message.FirstName}");
            model = new DataModel
            {
                PartitionKey = message.LastName,
                RowKey = message.FirstName
            };
        }
    }
    public class QueueModel
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
    }
    public class DataModel : TableEntity
    { }
}

Simple enough, isn’t it?

The method gets three parameters, the first one is the trigger itself, the message in the queue, notice that the attribute of the parameter specifies which queue the message comes from. The second parameter has the “out” keyword, specifying that is the output of the code and the parameter attribute also specifies the Table to which the data must go. The last parameter is a TextWriter object that the Azure SDK injects so you can log information to the Azure Log Console.

The model for the Queue is a simple POCO class, nothing special about it. The model for the Table inherits from “TableEntity” making it suitable to be saved to an Azure Table.

We are almost there! Only one step missing!

The Deploy

Now we have to deploy our Web Job to Azure, which is actually pretty simple. First thing we want to do is to build the project, to make sure that everything is in place, back to the shell prompt!

dotnet build

We should get a result like this:

Navigate to the directory showed in the build command, in my case C:\Code\AzureCoderWebJob\bin\Debug\net45\, then we will zip the content of the folder.

Now you have to open the Azure Portal, and login with your account.

In the Dashboard page, look for the App Service you created during the setup and open it. In the App Service Blade, under “Settings”, look for the option “WebJobs” and click on it, the WebJobs Blade will be opened, and at the top you should see a button “Add”, click on it. The Blade to add a new WebJob will be opened, and we will have to fill some information:

The name is simply an identifier for the WebJob, the File must be the Zip file we have just created.

The possible “Type”s are “Continuous” and “Triggered”, it may cause a little confusion but we want to keep the Continuous Type.

The scale is what define if the WebJob will run in only one instance of the App Service or in all the instances, scaling with the Web App, it is not so relevant for our WebJob, so we will keep the default “Multi-instance”.

After filling all the fields, click in “OK”, wait for the deployment and process and… that’s it :) You have just deployed your first WebJob created from scratch! But, how can we test it?

The Test

Let’s start by opening the “Logs” for our deployed WebJob. After we deployed the WebJob, we will be sent back to the WebJobs list Blade. In this list, select the WebJob and click in “Logs”. The Logs will be opened in another Tab of the Web Browser. We should see something like this:

Click on the title of the Web Job and you should see a small console, with the execution details for the Web Job:

As you can see, our “ProcessQueue” method has been detected!

Now we must add a new item to the azure-coder-queue, using the Azure Storage Explorer…

{
    "FirstName": "Lucas",
    "LastName": "Araújo"
}

…and then look at the log again:

Our message has been successfully processed! Now, if we take a look at the contents of the AzureCoderTable, also using Azure Storage Explorer, we should see our item added to the table:

And, finally, that is all you need to know to create a very simple WebJob from scratch! Most of what I showned here should work fine in Linux and Mac OS (apart from the usage of .NET Framework) but, unfortunatly, I am not able to test every step in these platforms, so let me know if you try and have any problem!

I am really sorry for the long post :)