Architecting Azure Functions: Function Timeouts and Work Fan-Out with Queues

When moving to Azure Functions or other FaaS offerings it’s possible to fall into the trap of “desktop development’ thinking, whereby a function is implemented as if it were a piece of desktop code. This may negate the benefits of Azure Functions and may even cause function failures because of timeouts. An Azure Function can execute for 5 minutes before being shut down by the runtime when running under a Consumption Plan. This limit can be configured to be longer in the host.json (currently to a mx of 10 minutes). You could also investigate something like Azure Batch.

Non Fan-Out Example

Azure functions flow

In this initial attempt, a blob-triggered function is created that receives a blob containing a data file. Each line has some processing performed on it (simulated in the following code) and then writes multiple output blobs, one for each processed line.

using System.Threading;
using System.Diagnostics;

public static void Run(TextReader myBlob, string name, Binder outputBinder, TraceWriter log)
{
    var executionTimer = Stopwatch.StartNew();

    log.Info($"C# Blob trigger function Processed blob\n Name:{name}");

    string dataLine;
    while ((dataLine = myBlob.ReadLine()) != null)
    {
        log.Info($"Processing line: {dataLine}");
        string processedDataLine = ProcessDataLine(dataLine);
        
        string path = $"batch-data-out/{Guid.NewGuid()}";
        using (var writer = outputBinder.Bind<TextWriter>(new BlobAttribute(path)))
        {
            log.Info($"Writing output line: {dataLine}");
            writer.Write(processedDataLine);
        }
    }

    executionTimer.Stop();

    log.Info($"Procesing time: {executionTimer.Elapsed}");
     
}

private static string ProcessDataLine(string dataLine)
{
    // Simulate expensive processing
    Thread.Sleep(1000);

    return dataLine;
}

Uploading a normal sized input data file may not result in any errors, but if a larger file is attempted then you may get a function timeout:

Microsoft.Azure.WebJobs.Host: Timeout value of 00:05:00 was exceeded by function: Functions.ProcessBatchDataFile.

Fan-Out Example

Embracing Azure Functions more, the following pattern can be used, whereby there is no processing in the initial function. Instead the function just divides up each line of the file and puts it on a storage queue. Another function is triggered from these queue messages and does the actual processing. This means that as the number of messages in the queue grows, multiple instances of the queue-triggered function will be created to handle the load.

Azure functions fan-out flow

public async static Task Run(TextReader myBlob, string name, IAsyncCollector<string> outputQueue, TraceWriter log)
{
    log.Info($"C# Blob trigger function Processed blob\n Name:{name}");

    string dataLine;
    while ((dataLine = myBlob.ReadLine()) != null)
    {
        log.Info($"Processing line: {dataLine}");
        
        string path = $"batch-data-out/{Guid.NewGuid()}";
        
        await outputQueue.AddAsync(dataLine);
    }
}

And the queue-triggered function that does the actual work:

using System;
using System.Threading; 

public static void Run(string dataLine, out string outputBlob, TraceWriter log)
{
    log.Info($"Processing data line: {dataLine}");

    string processedDataLine = ProcessDataLine(dataLine);

    log.Info($"Writing processed line to blob: {processedDataLine}");
    outputBlob = processedDataLine;
}


private static string ProcessDataLine(string dataLine)
{
    // Simulate expensive processing
    Thread.Sleep(1000);

    return dataLine;
}

When architecting processing this way there are other limits which may also cause problems such as (but not limited to) queue scalability limits.

To learn more about Azure Functions, check out my Pluralsight courses: Azure Function Triggers Quick Start  and  Reducing C# Code Duplication in Azure Functions.

New Pluralsight Course: Reducing C# Code Duplication in Azure Functions

Azure Functions allow small discrete pieces of code to execute in response to an external stimulus such as a HTTP request, message queue message, new blob data, etc.

Just because functions are easy to create (even writing and testing code right in the Azure Portal) doesn’t mean good practices such as avoiding code duplication can be abandoned.

My new Pluralsight course Reducing C# Code Duplication in Azure Functions shows some ways to reduce or remove code duplication both in a single Function App and across apps.

New Pluralsight Course: Azure Function Triggers Quick Start

Azure Functions allow small discrete pieces of code to execute in response to an external stimulus such as a HTTP request, message queue message, new blob data, etc. They can also be triggered manually from within the Azure Portal or set to execute on a specified schedule.

My new Azure Function Triggers Quick Start  Pluralsight course shows how to get up to speed quickly with each of the function trigger types such as:

  • Manual Triggers
  • Azure Queue Storage Triggers
  • Blob Triggers
  • Timer Triggers
  • HTTP Triggers
  • Webhook Triggers
  • Service Bus Triggers
  • Event Hub Triggers

You can check out the course here.

Creating Versioned APIs with Azure Functions and Proxies

One of the interesting possibilities with the (currently in preview) Azure Function Proxies is the ability to create HTTP APIs that can be versioned and also deployed/managed independently.

For example, suppose there is a API that lives at the root “https://dctdemoapi.azurewebsites.net/api". We could have multiple resources under this root such as customer, products, etc.

So to get the product with an id of 42 we’d construct: “https://dctdemoapi.azurewebsites.net/api/products?id=42”.

If we wanted the ability to version the API we could construct “https://dctdemoapi.azurewebsites.net/api/v1/products?id=42” for version 1 and “https://dctdemoapi.azurewebsites.net/api/v2/products?id=42” for version 2, etc.

Using proxies we can use the format “https://dctdemoapi.azurewebsites.net/api/[VERSION]/[RESOURCE]?[PARAMS]”

Now we can create 2 proxies (for example in an Azure Function called “dctdemoapi”) that forwards the HTTP requests to other Function Apps (in this example dctdemoapiv1 and dctdemoapiv2).

Screenshots of the proxies are as follows:

Azure Function proxy settings for API version 1

Azure Function proxy settings for API version 2

And the respective proxies.json config file:

{
    "proxies": {
        "v1": {
            "matchCondition": {
                "route": "api/v1/{*restOfPath}"
            },
            "backendUri": "https://dctdemoapiv1.azurewebsites.net/api/{restOfPath}"
        },
        "v2": {
            "matchCondition": {
                "route": "api/v2/{*restOfPath}"
            },
            "backendUri": "https://dctdemoapiv2.azurewebsites.net/api/{restOfPath}"
        }
    }
}

Notice in the proxy config the use of the wildcard term “{*restOfPath}” – this will pass the remainder of the path segments to the backend URL, for example “products”, meaning a request to “https://dctdemoapi.azurewebsites.net/api/v1/products?id=42” will be sent to “https://dctdemoapiv1.azurewebsites.net/api/products?id=42”; and “https://dctdemoapi.azurewebsites.net/api/v2/products?id=42” will be sent to “https://dctdemoapiv2.azurewebsites.net/api/products?id=42”.

Now versions of the API can be updated/monitored/managed/etc independently because they are separate Function App instances, but code duplication is a potential problem; common business logic could however be compiled into an assembly and referenced in both Function Apps.

To jump-start your Azure Functions knowledge check out my Azure Function Triggers Quick Start Pluralsight course.

Using Azure Functions and Microsoft Flow to Send Notifications for NuGet Package Downloads

One of the NuGet packages I maintain is approaching 100,000 downloads. I thought it would be nice to get a notification on my phone when the number of downloads hit 100,000.

To implement this I installed the Flow app on my iPhone, wrote an Azure Function that executes on a timer, and calls into Flow.

Creating a Flow

The first step is to create a new Microsoft Flow that is triggered by a HTTP Post being sent to it.

The flow uses a Request trigger and a URL is auto generated by which the flow can be initiated.

The second step is the Notification action that results in a notification being raised in the Flow app for iOS.

Azure Function calling Microsoft Flow

Creating an Azure Function with Timer Trigger

Now that there is a URL to POST to to create notifications, a timer-triggered Azure Function can be created.

This function screen scrapes the NuGet page (I’m sure there’s a more elegant/less brittle way of doing this) and grabbing the HTML element containing the total downloads. If the total number of downloads >= 100,000 , then the flow URL will be called with a message in the body. The timer schedule runs once per day. I’ll have to manually disable the function once > 100,000 downloads are met.

The function code:

using System.Net;
using HtmlAgilityPack;
using System.Globalization;
using System.Text;

public static async Task Run(TimerInfo myTimer, TraceWriter log)
{       
    try
    {
        string html = new WebClient().DownloadString("https://www.nuget.org/packages/FeatureToggle");

        HtmlDocument doc = new HtmlDocument();
        doc.LoadHtml(html);     
                            
        HtmlNode downloadsNode = doc.DocumentNode
                                    .Descendants("p")
                                    .First(x => x.Attributes.Contains("class") &&  
                                                x.Attributes["class"].Value.Contains("stat-number"));                        

        int totalDownloads = int.Parse(downloadsNode.InnerText, NumberStyles.AllowThousands);
        
        bool thresholdMetOrExceeded = totalDownloads >= 1; // 1 for test purposes, should be 100000

        if (thresholdMetOrExceeded)
        {
            var message = $"FeatureToggle now has {totalDownloads} downloads";

            log.Info(message);

            await SendToFlow(message);            
        }        
    }
    catch (Exception ex)
    {
        log.Info(ex.ToString());
        await SendToFlow($"Error: {ex}");
    }
}

public static async Task SendToFlow(string message)
{
    const string flowUrl = "https://prod-16.australiasoutheast.logic.azure.com:443/workflows/[redacted]/triggers/manual/paths/invoke?api-version=2015-08-01-preview&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=[redacted]";

    using (var client = new HttpClient())
    {
        var content = new StringContent(message, Encoding.UTF8, "text/plain");
        
        await client.PostAsync(flowUrl, content);
    }
}

Manually running the function (with test threshold of 1 download) results in the following notification on from the Flow iOS app:

This demonstrates the nice thing about Azure Functions, namely that it’s easy to throw something together to solve a problem.

iOS Flow App Notification

To jump-start your Azure Functions knowledge check out my Azure Function Triggers Quick Start Pluralsight course.

Cross Function App Proxies and Proxy Request Parameters in Azure Functions

In a previous article we saw how to get started with Azure Function Proxies. In addition to creating proxy URLs for HTTP functions in the same Function App, it is also possible to specifiy a backend URL that exists in a different Function App (or even a URL somewhere completely different). This essentially allows a single (HTTP) API for clients to use, that behind the scenes routes traffic to multiple Function Apps to enable  the decomposing of a single large Function App into multiple smaller ones. This also enables isolation between different Function Apps for deployment, testing, management, monitoring, etc..

For example, suppose we have an HTTP function defined in a Function App called myazurecloudfunctions that GETs a customer using an id querystring parameter; a request for customer 42 would look like the following (with function authorization enabled):

https://myazurecloudfunctions.azurewebsites.net/api/LoadCust?id=42&code=SKmM3Hr0IFEdJp9QnQ5ztu/mClYScUxjdjQw4TvSQ9OXm0xrgXQUpg==

In another Function App called dontcodetireddemos a proxy can be created to enable the following URL to be used instead:

https://dontcodetireddemos.azurewebsites.net/customer/42?code=SKmM3Hr0IFEdJp9QnQ5ztu/mClYScUxjdjQw4TvSQ9OXm0xrgXQUpg==

Notice in this proxied URL the id 42 is specified in the URL, not as a querystring parameter. This is another feature of Azure Function Proxies that  allows request parameters to be mapped from the proxy URL to the backend URL. In this example the proxy route template is “customer/{custId}” and the backend is set to “https://myazurecloudfunctions.azurewebsites.net/api/LoadCust?id={custId}” – notice the token {custId}.

The proxies.json configuration is:

{
    "proxies": {
        "CustomerGet": {
            "matchCondition": {
                "route": "customer/{custId}",
                "methods": [
                    "GET"
                ]
            },
            "backendUri": "https://myazurecloudfunctions.azurewebsites.net/api/LoadCust?id={custId}"
        }
    }
}

And a screenshot of the configuration:

Azure Function Proxy settings

To jump-start your Azure Functions knowledge check out my Azure Function Triggers Quick Start Pluralsight course.

Azure Functions Proxies Preview

Azure functions allow the creation of HTTP-triggered code. A new feature to Functions is the ability to define proxies. (Note: at the time of writing this feature is in preview)

For example a function can be created that responds to HTTP GETs to retrieve a customer as the following code demonstrates:

using System.Net;

public class Customer 
{
    public int Id {get; set;}    
    public string Name {get; set;}
}

public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log)
{
    // error checking omitted

    string id = req.GetQueryNameValuePairs()
        .FirstOrDefault(q => string.Compare(q.Key, "id", true) == 0)
        .Value;

    return req.CreateResponse(HttpStatusCode.OK, GetById(int.Parse(id)));
}

public static Customer GetById(int id)
{
    // simulate fetching a customer, e.g. from Table storage, db, etc.
    return new Customer
        {
            Id = id,
            Name = "Amrit"
        };
}

This function (called “GetCustomer”) could be available at the following URL (with function authorization enabled): https://dontcodetireddemos.azurewebsites.net/api/GetCustomer?id=42&code=rEQKsObGFDRCCiVuLhOnZ1Rdfn/XGgp5tfC1xHrhAqxvWqzHSQszCg==

Notice in the URL the name of the function is prefixed with “api” i.e. “api/GetCustomer”

Calling this URL would result in the following JSON being returned:

{
  "Id": 42,
  "Name": "Amrit"
}

Function proxies allow the “api” part to be replaced, for example to create a URL:  “https://dontcodetireddemos.azurewebsites.net/customer?id=42&code=rEQKsObGFDRCCiVuLhOnZ1Rdfn/XGgp5tfC1xHrhAqxvWqzHSQszCg==”

Azure Function Proxy

This proxy defines a name “CustomerGet”, a route template of “customer”, the actual URL to maps to “https://dontcodetireddemos.azurewebsites.net/api/GetCustomer”, and limited to only GET HTTP verbs.

If we had another function e.g. called PostCustomer we could also setup a POST proxy for that function:

Azure Function Proxy

Now we can issue both POSTs and GETs to the customer “resource” at: https://dontcodetireddemos.azurewebsites.net/customer (code key omitted).

Using Kudu for example, we can see a proxies.js file created in the wwwroot folder with the following contents:

{
    "proxies": {
        "CustomerGet": {
            "matchCondition": {
                "route": "customer",
                "methods": [
                    "GET"
                ]
            },
            "backendUri": "https://dontcodetireddemos.azurewebsites.net/api/GetCustomer"
        },
        "CustomerPost": {
            "matchCondition": {
                "route": "customer",
                "methods": [
                    "POST"
                ]
            },
            "backendUri": "https://dontcodetireddemos.azurewebsites.net/api/PostCustomer"
        }
    }
}

To jump-start your Azure Functions knowledge check out my Azure Function Triggers Quick Start Pluralsight course.

 

Push Notifications and Buttons with Microsoft Flow: Part 2

In part 1 we created a Flow to toggle the sending of push notifications on and off by storing the configuration in Azure blob storage.

Now that we have a way of enabling/disabling notifications we can start to build the second Flow.

Before jumping into the Flow designer, we need to consider how to generate random positivity phrases and how to integrate this into the second Flow. One option to do this is to create a simple Azure Function with an HTTP trigger. The Flow can then use an HTTP action to issue a GET to the server that will return the string content to be sent via push notifications.

In the Azure Portal function editor a new function can be created with a HTTP trigger configured to GET only as the following screenshot shows:

Creating an Azure Function with a HTTP trigger

Notice in the preceding screenshot the authorization level has bee set to “function”. This means the key needs to be provided when the function is called.

We can now write some code in the function code editor window as follows:

using System.Net;

public static HttpResponseMessage Run(HttpRequestMessage req, TraceWriter log)
{
    log.Info("C# HTTP trigger function processed a request.");

    string phrase = GeneratePhrase();

    return req.CreateResponse(HttpStatusCode.OK, phrase);
}

public static string  GeneratePhrase()
{
    var phrases = new string[]
    {
        "Don't worry, be happy :)",
        "All is well",
        "Will it matter in 100 years?",
        "Change what you can, don't worry about what you can't"
    };

    var rnd = new Random();
    
    return phrases[rnd.Next(phrases.Length)];
}

Azure Function code editor window

Clicking the Run button will test the function and we can see the random phrases being returned with a 200 status as shown in the following screenshot:

Azure function HTTP test output

In the final part of  this series we’ll go and create the second Flow that uses this function and the configuration value created in the previous article to actually send random positivity push notifications on a 15 minute schedule.

To jump-start your Azure Functions knowledge check out my Azure Function Triggers Quick Start Pluralsight course.

Screen Scraping As A Service with Azure Functions in 5 Mins

If you have some data in a web page but there is no API to get the same data, it’s possible to use (the often brittle and error prone) technique of screen scraping to read the values out of the HTML.

By leveraging Azure Functions, it’s trivial (depending on how horrendous the HTML is) to create a HTTP Azure Function that loads a web page, parses the HTML, and returns the data as JSON.

The fist step is to create an HTTP-triggered Azure Function:

Creating a new Azure Function with a HTTP Trigger

To help with the parsing, we can use the HTML Agility Pack NuGet package. To add this to the function, create a project.json file and add the NuGet reference:

Using NuGet Packages in Azure Functions

{
  "frameworks": {
    "net46":{
      "dependencies": {
        "HtmlAgilityPack": "1.4.9.5"
      }
    }
   }
}

Once this file is saved, the NuGet package will be installed and a using directive can be added: using HtmlAgilityPack;

Now we can download the required HTML page as a string, in the example below the archive page from Don’t Code Tired, use some LINQ to get the post titles, and return this as the HTTP response. Correctly selecting/parsing the required data from the HTML page is likely to be the most time-consuming part of the function creation.

The full function source code is as follows. Notice that there’s no error checking code to simplify the demo code. Screen scraping should usually be a last resort because of its very nature it can often break if the UI changes or unexpected data exists in the HTML. It also requires the whole page of HTML be downloaded which may raise performance concerns.

using System.Net;
using HtmlAgilityPack;

public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log)
{
    HttpClient client = new HttpClient();

    string html = await client.GetStringAsync("http://dontcodetired.com/blog/archive");    

    HtmlDocument doc = new HtmlDocument();
    doc.LoadHtml(html); 
    
    var postTitles = doc.DocumentNode
                        .Descendants("td")
                        .Where(x => x.Attributes.Contains("class") && x.Attributes["class"].Value.Contains("title"))
                        .Select(x => x.InnerText);

    return req.CreateResponse(HttpStatusCode.OK, postTitles);
}

We can now call the function via HTTP and get back a list of all Don’t Code Tired article titles as the following Postman screenshot shows:

Using Postman to call Azure Functions

To jump-start your Azure Functions knowledge check out my Azure Function Triggers Quick Start Pluralsight course.

Azure HTTP Function Authorization with Function Keys

When creating an Azure Function triggered via HTTP, one way to authorize use of the function is to configure the HTTP function trigger to require the caller to provide a function key.

Azure Function HTTP Trigger Authorization Modes

With the authorization set to Anonymous, as expected anyone can call it.

When set to Function Authorization, the caller needs to provide the function key either as a URL query string parameter or in a header.

The function key can be found by navigating to Manage tab as the following screenshot shows:

Finding the Azure Function Key

Once Function Authorization is enabled, if the client does not provide it correctly the function will return a 401 Unauthorized.

To supply the function key in the URL, the “code” query string parameter can be used, e.g. “https://myazurecloudfunctions.azurewebsites.net/api/SayHi?code=udXhf3pviSICFMtViW/pqmV/1Q5vLH5aMcRWXfD/q6NXk2VVxRlfYw==”.

Alternatively an “x-functions-key” header can be added containing the key as the following Postman screenshot shows:

Calling Azure Function with Postman and Function Key

To jump-start your Azure Functions knowledge check out my Azure Function Triggers Quick Start Pluralsight course.