Baby steps into Azure Functions. A journey from Local to Production.

Recently I got excited about Serverless Architecture after reading this article from thoughtworks. So I decided to have a look into Azure Functions.

I wanted to deploy using Visual Studio 2017 because I didn’t want to think about a pipeline at this point, and to do so, there are three pre-requisites that you’ll need:

1. Visual Studio 2017 Preview 15.3
2. Azure Function Tool Extension, and also
3. Azure SDK and Tools

Once we have all of that, we can crate our project using a template like this one:

Add our first function:

It will prompt a few options, so just choose the type you want.

I selected ServiceBusTopicTrigger as that’s the kind of architecture that I’m looking for. But hold your horses, because the template is not complete and you’ll need to add a function.json file that it’s not included by the default (at least it wasn’t on the 20 of June 2017).

Have a look about how to bind your configuration here:

Mine was easy, at the end my function.json looked like:

{
“name” : “<Name of input parameter in function signature>”,
“topicName” : “<Name of the topic>”,
“subscriptionName” : “<Name of the subscription>”,
“connection” : “<Name of app setting that has your topic’s connection string — see below>”,
“accessRights” : “<Access rights for the connection string — see below>”,
“type” : “serviceBusTrigger”,
“direction” : “in”
}

As soon as you start running it, it will ask you for the Azure Functions CLI, another framework needed. But luckily this one will be automatically installed on your first run.

In order to run my first code, I updated the ServiceBusTrigger attribute to make it slightly simpler, so my first run looked like this:

And this is the first error that I got:

Which I solved adding AzureWebJobStorage to my local.settings.json

As WebJobs, or most of the components in Azure, we’ll need a storage account to run them, so I needed to create one for my test and get the connection string. The result was something like this:

As soon I fixed that, BINGO! I managed to run it locally.

That was fantastic (so far this took me around 2 hours to get here, and that was my main motivation to write this blogpost 😅)

So the time to deploy came! I set my profile from VS and pushed the code. What happened next?

Surprise! Another error 🙃 😰

The system cannot find the file specified MessagingFunction.dll

I tried to downgrade Microsoft.Azure.WebJobs to 2.0.0 but then I realized that we are using 2.1.0-beta for the signature FunctionName("name") among other features. So I took it back to the beta version.

What I did to fix this problem was update the Microsoft.NET.Sdk.Functions to 1.0.0-alpha6 and downgrade Microsoft.Azure.ServiceBusto 2.0.0.
I also cleaned the solution, closed VS2017 and started it again (the classic), and one of these three things made it work, giving me a nice output log with the files being updated to Azure 👌

What happened after this? Yeah, you saw that coming, another error:

I thought I could fix it adding that value in red to myfunction.json so I started putting it all over the place, trying different positions as if the order matters but that obviously (obviously?) wasn’t the problem.

Actually, a new one arouse, by givingAzureWebJobServiceBus a value, the key AzureWebJobEndpointstarted to pop up as missing property. So I added it, but I was getting a weird exception saying AzureWebJobEndpoint with value `Endpoint=sb://superbus.... ` is missingWHAT? How is it possible that the key is missing if the tool knows the value? 🙄 Well, you start to suspect that something fishy is going on when this kind of things happen. As if the error in truth is pointing to somewhere else.

On that stage, I started reading around github and the different set of documentation available, decided to redeploy again — just in case — with a different name to start from scratch, and finally found that the key to solve my problem was in the Integrate section, so I disabled my previous function, and headed to the configuration of my new function:

Once there, I added the Service Bus Connection string with the name I thought appropriate (ConnectionString. LOL). Bear in mind that this is the way that Azure Function manages secrets, having said that, to see the real connection string that you added here you’ll need to go to

Platform Features -> Application Settings -> App settings.

But the order here matters, as if you add the ConnectionString property into your AppSettings it will mean nothing to your function because we didn’t tell our function — yet — where do we want to read this data from. Integrate section is the key. Where you’ll see something like this:

After that I added the appsettings.json file (manually), with the following values:

And the result of my function.json was something like that:

Et voilà! 🙌🏼 🚀 
I could finally read messages from my function

My next goal is to generate an xml with the message that I’m reading from Azure Service Bus, and save them into an blob storage, maybe query Azure SQL just to see how it goes. After that setting up a proper deployment pipeline, I’ll be covering those in the next series. We’ll see if it’s as easy-peasy as it seems haha 😁

Thanks for reading so far!

P.S: The repo with the structure in case that you want to have a look is: https://github.com/pliyosan/azure-messaging-function