Timer trigger to read messages from a queue

When you want to develop an Azure Function to process messages from a queue, the first hunch is to use a queue trigger. But, let’s say you want to processes messages from a queue every minute. In that case you need a timer trigger. In the example below you see an example of an Azure Function with a timer trigger, an import of multiple libraries and a call of a Logic App using an URI from AppSettings. I need to check if I found a message (message!=null). On the other hand, if there are multiple messages on the queue, they will be processed one-by-one.

[box type=”info”]

#r “Microsoft.WindowsAzure.Storage”
#r “Newtonsoft.Json”

using Microsoft.WindowsAzure.Storage;
using Microsoft.WindowsAzure.Storage.Queue;
using System.Text;
using System.Net.Http;
using Newtonsoft.Json;

private static string logicAppUri = Environment.GetEnvironmentVariable(“ProcessOpdrachtenURI”);

public static async Task Run(TimerInfo myTimer, TraceWriter log)
{

log.Info($”Function TriggerTimedProcessOpdrachten started”);

// Retrieve storage account from connection string.
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(Environment.GetEnvironmentVariable(“ahakstorage_STORAGE”));

// Create the queue client.
CloudQueueClient queueClient = storageAccount.CreateCloudQueueClient();

// Retrieve a reference to a queue.
CloudQueue opdrachtQueue = queueClient.GetQueueReference(“opdrachtevents”);

// GetMessage
CloudQueueMessage message = await opdrachtQueue.GetMessageAsync();
if (message != null)
{

log.Info($”{message.AsString}”);

using (var client = new HttpClient())
{
var response = client.PostAsync(logicAppUri, new StringContent(message.AsString, Encoding.UTF8, “application/json”)).Result;
}

opdrachtQueue.DeleteMessage(message);

}

log.Info($”Function TriggerTimedProcessOpdrachten ended”);

}

[/box]

Note: In the end I didn’t need the Newtonsoft.Json library, but I left that library in for learning purposes.

Finding the Servicebus Queue

I had to troubleshoot an Azure App Services solution that I didn’t develop myself. In the solution a message was sent by a web app to a servicebus queue named From4PS_queue. This action activated a logic app with a servicebus queue trigger. The question was: which servicebus queue is used?

In the Azure Portal I found a service bus named SupportCalls for development, test and production. At the servicebus level I found an ACS policy named SharedAccessKey. After doubleclicking this ACS policy I found the primary connection string for the servicebus. I also found four queues at the servicebus level. Among these queues was the queue I was looking for. This queue had two shared access key policies: api for sending messages to the queue and logicapp for reading messages from the queue. Both access key policies also held a primary connection string.

In the app settings of the api app the primary connection string of the queue (policy: api) was used. I could see this right away from the appsettings of the api app. The settings for the logic app were harder to find. In the logic app’s parameters file I found the servicebus connection string TstSupportCalls (not the queue connection string, not the Dev version). This was confusing, because the setting from the pameters file is actually not used. When I turned to the json file, I saw the queue trigger with a connection named DevSupportCalls. From the resource group of the API connection I could reassure myself that the servicebus connection string DevSupportCalls was used. The name of the queue was entered in another property of the API App.

[box type=”success”] Use the servicebus connection string in logic apps. Use the queue connection string in api apps. [/box]