Azure Functions - Service Bus Queue Trigger

August 14, 2017 on Azure Functions, FAAS, azure-service-bus

Azure functions allow have a service bus queue trigger, which will execute the code in the function each time a message is added to the service bus.

Create Service Bus trigger

In Azure functions create a new function, From the template options select "ServiceBusQueueTrigger - C#"

Azure Functions Service Bus Queue Trigger

Select the ServiceBus Connection you want to use, you can also select the access key you want to use. In the above I've selected my contentappMessage bus and my root key.

Select the Queue name and then create

This will create an Azure function that will run when ever a message is added to the service bus Queue you have selected.

For more on Azure Service bus check out my blog post Getting Started with Azure Service Bus

public static void Run(string myQueueItem, TraceWriter log)
{
    log.Info($"C# ServiceBus queue trigger function processed message: {myQueueItem}");
}

Each time you add a message to the service bus queue this function will execute and log the item.

But there is an issue with the trigger. string myQueueItem isn't really useful not if you have used a brokered message and added other information you want to use in the function.

So lets change it.

First lets add the nuget package for Azure Service Bus into our function. (see here for more)

In View Files add "project.json"

Azure Functions Add Project.json

In project.json add the following code


{
  "frameworks": 
    {  
      "net46":
      { 
        "dependencies":
        {
          "WindowsAzure.ServiceBus": "4.1.2"
        }
      }
    }
}

And save, watching the logs panel you will see it restoring the nuget package

Azure Functions logs

Back into our Run.csx and we want to make some changes


using System;
using System.Threading.Tasks;
using Microsoft.ServiceBus.Messaging;

public static void Run(BrokeredMessage myMessage, TraceWriter log)
{
    log.Info($"C# ServiceBus queue trigger function processed message");

    string sMessage = myMessage.Properties["Message"].ToString();
    string sID = myMessage.Properties["ID"].ToString();


    log.Info($"message - " + sMessage + " Id " + sID);
}

We add the

Using Microsoft.ServiceBus.Messaging

We then change

string myQueueItem

to be

BrokeredMessage myMessage

Then Replace the log lines as this will fail. But also we add in two strings reading from our message in the service bus queue.

Lastly we need to change the binding in the function. Open Function.json in the View Files.


{
  "bindings": [
    {
      "name": "myQueueItem",
      "type": "serviceBusTrigger",
      "direction": "in",
      "queueName": "serversncodedemo",
      "connection": "contentappmessage_XXXXXXXXXXXXXXXXX",
      "accessRights": "Manage"
    }
  ],
  "disabled": false
}

This is the binding that will trigger the function to execute.

Change the "Name": "myQueueItem" to


"name": "myMessage"

Now save and in the logs it should now read Compilation succeeded.

Azure functions allow have a service bus queue trigger, which will execute the code in the function each time a message is added to the service bus. Create Service Bus trigger In Azure functions create a new function, From the template options select "ServiceBusQueueTrigger - C#" Select the…

Azure Functions Nuget Packages and the dot Net Framework

August 07, 2017 on Azure, FAAS, Azure Functions

Using Nuget and the .NET Framework in our Azure Functions is easy and straight forward. We can give our Azure functions alot of power and functionality.

Using the .NET Framework

For framework assemblies, add references by using the #r "AssemblyName" directive.

For example if we want to use System.Data.SqlClient we would need to add a #r directive to the top of our code like this


#r "System.Data"

using System.Data.SqlClient;

This will allow us to use the SQLClient libarary of the .net framework.

Adding Nuget

If you are wondering where to get started check out our Azure Functions Getting Started

In our Function we need to add a "project.json" file. Go to View Files and add a new file and name it project.json

Azure Function Add Project json

In our Project.json we want to add the following


{
  "frameworks": 
    {  
      "net46":
      { 
        "dependencies":
        {
          "Newtonsoft.Json": "10.0.3"
        }
      }
    }
}

This will load the nuget package of Newtonsoft Json into our function.

Then in our code we just reference


using Newtonsoft.Json;

And now we can use our Nuget package in our Azure Function.

Using Nuget and the .NET Framework in our Azure Functions is easy and straight forward. We can give our Azure functions alot of power and functionality. Using the .NET Framework For framework assemblies, add references by using the #r "AssemblyName" directive. For example if we want to use…

Azure Functions Triggers

July 31, 2017 on Azure, FAAS, Azure Functions

Azure Functions come with a number of triggers, from HTTP, Timers, service bus, blob and many more. In this post we go over the different types of triggers available out of the box for Azure Functions.

Last week I covered the creating of functions and getting up and running, Azure Functions Getting Started

Azure Function Triggers

Azure functions have a number of quick start templates for different triggers in C#, F# and Javascript. These are out of the box and have some default code.

Azure Function Triggers

HTTP Trigger

When a HTTP request is made to the function, the functions code will be executed. It provides a REST API endpoint that can be called with a HTTP post request.

Timer Trigger

This is a trigger that is based on a schedule. You can define the schedule and it will execute the code in the function.

To create a schedule you use the CRON Expression

A timer trigger is made up of

{second} {minute} {hour} {day} {month} {day-of-week}

Examples

Once every 5 minutes

0 */5 * * * *

Trigger once every two hours

0 0 */2 * * *

Trigger once every hour from 9 AM to 5 PM

0 0 9-17 * * *

Trigger At 9:30 AM every weekday

0 30 9 * * 1-5

Queue Trigger

This is a trigger that will execute the code whenever a message is added to a selected Azure Queue Storage

Blob Trigger

When an item is added to a specified Blob Storage container the code will be executed.

EventHub Trigger

When an event is added to the selected event hub the code in the function will execute.

Servicebus Queue Trigger

When a message is added to a selected Service Bus queue, this function will be executed.

Servicebus Topic Trigger

When a message is added to a specified Service Bus topic, then this function will be triggered.

With these triggers we have alot of flexibility to create a very flexible application.

Azure Functions Getting Started

July 24, 2017 on Azure, FAAS, Azure Functions

Function as a Service or FAAS we do love our abbreviations. FAAS is a set of functions that are short lived and single responsibility and have the ability to scale well. The big part of Functions as a service is they are part of serverless, this doesn't mean there isn't a server it just means the server is not your problem.

Some of the properties of Function as a service are

Short lived functions - AWS Lambda has a timeout of 1 second.
Single Responsibility - A Function should only do 1 thing.
Event Driven - A function can respond to a HTTP Trigger like a Webhook, a schedule and timer or a Service bus message.
Scale easily with traffic spikes

This is the first post in a series on FAAS in general but starting with Azure Functions.

Azure Functions

Azure functions are Microsofts FAAS offering and what we will start to explore.

With Azure Functions you can write functions in C#, F#, Node.js, Python, PHP, Batch, Bash and an executable. Functions have full support for Nuget and NPM. Easily integrate to other Azure services.

Pricing

Azure functions have two price plans, app service plan so it would be tied to your existing plans or consumption and you only pay for what you use.

With Functions you pay per second X number of executions.

Getting Started

Lets get creating some azure functions. Open the Azure Portal

Click on New and in the market place type in Function App (it's filed under Compute in the marketplace if you just want to click it)

Getting Started with Azure Function App

Once you select this we can create our first function app. This isn't the functions it's a host for our functions. Think of it like setting up an Azure App Service.

Create Azure Function App

Now we create our function app. We give it a name, select the Resource Group and Subscription as we do with most things in Azure.

Hosting Plan we have two choices,

Consumption Plan
App Service Plan

With an App service plan our function is tied to the currently running app services.

Consumption plan is just what it sounds like you pay for what you use. Per Second per request. I won't go into the details here if you go to the Azure Pricing Calculator you can find out more.

All Azure functions need a storage account and they can be integrated to Application Insights.

Hit create and deploy our new Azure Function.

Next we need to add the menu item to the side bar on our portal. It's not there by default.

Click "More Services" on the bottom of the side bar

Azure More Services

Search for "Azure Functions" and click the Star to add it onto the side bar and then you can move it where you want.

Azure Function Apps sidebar option

Once our Function app has deployed we can start creating functions.

Azure Function App Ready

Let's create a quick function and see it all in action.

Along side functions Hit the plus to create a function

Azure Function New

For your first Function you will see the Azure Function quick start panel.

Azure Function Quick Start

We'll create a web hook Function, this is a HTTP Trigger function, I'll cover the triggers in another post.

Create this function.

Azure Function Code

Ok we now have a function, our screen in the portal is in 3 sections

We our editor which by default is loading the code for our function.
Below this we have our logging output.
Next to this on the left we have "Files" and "Test"

The file "run.csx" is our code. Azure functions are scripts. In this case I have a csharp script.

Select "Test" on the left side to open the test panel.

Test Azure Function

This makes a POST request and sends a request body with "Name": "Azure" this is the default test.

Below that you can select Run and the output will show "Hello Azure"

You can also test it from an API testing tool like postman (for more on postman and api testing check out my post API Testing with Postman)

Click on "</> Get Function URL"

Azure Function Get URL

Copy this url and open Postman or any API testing tool

Azure Function Test

Set the web method to POST and enter the URL from the function.

Select Body and go to RAW, set the application content type to "JSON(Application/json)"

And then enter the RAW body of

{
"name": "James"
}

Click send and then we will get a response of "Hello James"

That's it you have created your first function.

This is the first post in a series on FAAS, focusing at first on Azure Functions.

Over the course of these posts we will cover

Different triggers.
Passing more information.
Nuget Packages.
Working with Visual Studio.
Connecting to other services including SQL and Azure tables.

CI - CD and Visual Studio Team Services (VSTS)

July 17, 2017 on Build, Continuous Integration, VSTS, Continuous Delivery

We have code now it's time to wire it into Visual Studio Team Services for builds and releases and even our tests and show how easy it is. We'll pull our code from Github, work with different triggers and get under the hood of Visual Studio Team Services

Visual Studio Team Services

Visual Studio Team Services is the next version of Team foundation but don't let that put you off. It is so much more under the hood. Microsoft have built a powerful solution with Team services that allow us to store our code, pull code from other places and build anything check out this from Donovan Brown - From 0 to DevOps

Wire up some code

While Visual Studio Team Services offers code repository it also allows you to pull code from a Github project.

It's also Free there are limits of course but it's free to get started so go sign up and come back here Visual Studio Team services

So lets get started in Visual Studio Team Services create a new team project.

Create New Team Project

It takes a minute or so to get everything in place once you create your new project.

Once your project is created you will see a landing page with all the information for submitting code. But since we are here for a build lets go make our first build definition. See build and release on the menu bar at the top. (I added the red box to highlight it you won't see that on the site.. I hope)

VSTS - New Project

When you open the Build and releases option you will see the "New Definition" button. This is the Build Definition where we will get our code from Github and set our triggers and the process of building our project.

VSTS-NewBuild

Go on hit the new definition button

VSTS - New Build

Ok now we see on the right a list of different types of projects,

These are templates to help make it easy. You can do it all manually if you want, just hit "Empty Process" at the top.

But to help they have a bunch of different templates that will allow us to make our project easier. These are common templates and for my project it's an ASP.NET application so we have a ready template available.

My code for this project is here It's my Nunit demo app I used for some other blog posts to show off unit testing. Go ahead and fork it if you want to code along.

So I'm going to select the ASP.NET (Preview).

When we do that we get a build with a number of tasks already loaded. These are the basics we need to build and test our ASP NET Project.

VSTS - Create Build

Name - Is already set for you.
Default Agent queue - This is the agent that will build our project. I'll go into more details on this in another post for today, I've selected "Hosted2017"

Because we are doing a straight ASP net application we don't have anything fancy so the default settings all work for us.

Get Sources

When you open the Get Sources task we get to set up where our code will come from.

VSTS - Get Sources

This Project - Visual Studio Team Services also has code repo's so you can store code there aswell.
Github - We can pull a project from GitHub and load it in.
Remote Repo - If the code is somewhere else, maybe in house or on Bitbucket.
Subversion - Yes it is still out there.

So we're using GitHub so I will select it and then Authorize GitHub to my account.

VSTS-Github

Once I've done that I can select the repository I want it to look at and the branch.

Tests

The Template we picked has a task for testing our build. This task will look for the test.dll if it is there it will run the tests. If not it will pass and just carry on. It won't fail just because there are no tests there.

VSTS Tests

The project I'm using for this post has Tests, in a project NUnit_Demo.Test so it will be selected and run.

Triggers

Triggers will allow our build to happen when something changes. As it is set by default a build is manual.

VSTS Triggers

Continuous Integration - This will trigger our build when ever there is a change to the branch.
Scheduled - Run the build on a time or day of week.
Pull Request - When a pull request is submitted run the build.

These are very useful triggers. We can watch for different things and run the build. Our you can actually have different build definitions triggered for different things.

For us I've selected Continuous Integration on the master branch.

VSTS - Save and Queue

Now we select "Save and Queue" this will save our changes run our first build.

Summary and History

Once your build is ready it will be listed on the builds page.

VSTS - Build Definations

This will list all your build definations, you can see the latest status, triggered by and 7 day history.

The Triggered by will show the commit message that was loaded in. You can also click the commit ID and that will take you to the commit in the code.

As you can see I've failed my builds a few times all for a good cause.

If you read my earlier blog post on unit testing Building real unit tests you will know I have a habit of failing tests on purpose to see what happens. I blame watching too much mythbusters.

So lets look at what happens when my test fails.

If you click on the build definition for me it's "nunitTestApp-ASP.NET (PREVIEW)-CI"

We see a detailed break down of the history and summary.

VSTS - Build Detail

This is my summary after a few runs of the build as you can see I have a good breakdown of the builds and the results. If they failed or succeeded,

Just the summary of the recent builds I can see the triggers too, where it says my name is a manual queue. When it says Microsoft.VisualStudio.Services.TFS that was a trigger from check in.

If we select "History", we see the builds. Each build has it's own name.

VSTS History

We can see more details, we can also see the source Version, this link will bring us right to the code we committed.

So what happens with a failed build well apart from the big red X and failed.

If you click the build we want to see, we get a detailed summary of the build.

Build 20170714.4 has failed so if we click it we will see the reason fail.

VSTS - Failed test

As we can see the Test results, found 5 tests. 4 pass and 1 failed.

We get a bunch of information, we can see from the "associated changes" that the commit was authored by me with a commit of "Break one of my tests again" so I was kinda asking for it.

If we click that link of a commit code though we can see the details in GitHub that where submitted.

VSTS - Failed Test

So lets fix it, If I open the code in visual studio I can set that test to pass. I then commit it and it will pick it up and create build 201714.5 this time it passes all tests.

VSTS - Test Passed

We can now see that our test passed successfully.

A failed test will fail the build and the sheer volume of data available is huge, we'll go into that in more detail later.

Now you see how easy it is to get a build run in Visual Studio Team Services and use our Unit tests.

Create a Release

Now we have our build working, lets set up a release pipeline into Azure.

So I will do a more detailed post on Azure later for now I have an app service running on Azure. I want to wire my Code to the app service and each time a build is successful then deploy my project.

Seriously this is really easy to do.

Click on the Releases Option.

VSTS - Releases

And select "Create Release Definition"

We're given a choice again of some templates. Empty is allowed or for what we want "Azure App Service Deployment with Test"

VSTS - Create Release

Next we tie it to our build.

VSTS - Release Build

We select our Project and the build we've just been setting up, and also tick the "Continuous Deployment" this will trigger a release on a successful build.

Click create.

Defining our release is easy, we've wired it onto our build so now we select the Azure Subscription and authorise access.

VSTS - Define Release

Once you select the Azure Subscription select the "App Service Name" we want to deploy too.

And then hit save and your done. Really it's that easy!

A quick note on Triggers, I'll cover these in more detail later

VSTS - Release Triggers

But you can see the different types of triggers e have available, for the builds we can also set tags. So if builds with some tags succeed we only release these.

Code and release

Really that's it, now go check in a change, and watch the magic happen.

Because we are using hosted agents it can take a minute to queue up a build but once it does you can see the details and watch the build.

VSTS - Lets go

Once it releases it will be displayed under Releases, and you will see if it deploys ok or fails. If the build fails it doesn't even try and do a release.

VSTS - Release

You can see which build was successful. And if you go to the site serversncodedemo it will be live.