Process Service Bus dead-letter message with Azure Functions

How about an Azure Function to re-evaluate messages on a Service Bus dead-letter queue and send them back to the originating queue?

Great idea! Sadly, when you look at the docmentation regarding the Azure Functions Service Bus binding, it does not list the possibility to read messages from a dead-letter queue…

Trying to configure this manual in the UI seems not possible when you try to save it…

 

How about editing the function.json?

This file contains de queue names and other Service Bus related settings (such as the maxConcurrrentCalls setting).

Setting the DLQ queue name here, makes it possible to save and run the Function!

Putting it all together

Some sample code on how a ReprocessDLQ Function could look like:

 

Using Azure Table Storage as ADAL token cache

Outline: In this post I will talk about the possibility to replace a SQL Database as the ADAL token cache in the default Visual Studio ASP.NET MVC Template. The replacement data store will be Azure Table Storage.

At a recent project we where using an ASP.NET MVC Website to present data located in Azure Table Storage. The application was using Azure Active Directory for its Authentication.

When creating an ASP.NET MVC Site and adding Azure Active Directory for Authentication, the Template will add a ConnectionString to a Database to use for the ADAL Token Caching:

When you deploy this to an Azure Website you will need to use an Azure SQL Database. Using LocalDb in Azure is not possible. (The Publish tool in Visual Studio guides you in this.)

After deploying this the first time to Azure we ended up with 2 storage backends: Azure SQL Databse (for Authentication) and Azure Table Storage (for the real Business Data). As the SQL Database was only used for the ADAL Tokens, we surely wanted to get rid of this beceause of the extra cost in Azure.

As we were already using Table Storage, we decided to go with that.

From Azure SQL to Azure Table Storage

  • Add the Windows Azure Storage nuget package to your solution
  • Setup a storage account and add the connection configuration to your web.config
  • Add your custom AdalTokenCache implementation. Remove “AdalTokenCache.cs” and “ApplicationDbContext.cs”

  • Use it in “Startup.Auth.cs” and “UserProfileController.cs”
AuthenticationContext authContext = new AuthenticationContext(Authority, new TableTokenCache(signedInUserID));

 

A complete working sample can be found on GitHub: https://github.com/joenmaes/TableTokenCacheSample

 

Creating a Logic Apps Singleton Instance

Since the release update of 2016-11-18  we can now mark a Logic App trigger as “Singleton”.

Which results in a Logic App that will run as only one instance at a time. To be more precise: it is the trigger who will not fire unless the previous instance of the Logic App has fully completed.

A trigger which was skipped because of a running instance will result in a “WorkflowRunInProgress” code.

 

 2016-11-30-13_05_36-history-microsoft-azure

Marking a trigger as singleton

Currently there is no possibility to mark a trigger as singleton in the designer. You need to switch to codeview and add the following at the same level as the recurrence property.

1
"operationOptions": "SingleInstance",

As soon as you save, the setting will become active and your Logic App will run as a singleton.