Jamie Maguire

Software Architect / Developer / Microsoft MVP (AI)

Architecture, ASP.NET Core, C#, Tooling

Implementing Long running Tasks in Azure

A few months ago, I had to build functionality that invoked a background process from an ASP.NET Core web application.

This had the responsibility of ingesting data from the web that was then surfaced during chatbot conversations.

In the past I would have written a Windows Service to do this and then installed it on an interface server (or something to that effect). Or, if I was REALLY pushed for time, quickly write a console application then house this in Tophelf (shock horror!)

With everything moving to the Cloud, provisioning a new VM that would only have this job on it seemed like overkill!

After a bit of research and looking around, I narrowed my options down to the following:

  • .NET Core Worker Service
  • Azure Function
  • Web Job

I had a few constraints, one of which was the business also needed a way of logging into the ASP.NET Core Web App to quickly check the status of the background process in dashboard.

Hangfire

It’s at this point that I discovered Hangfire and the more I looked into it, Hangfire became a viable option to help me quickly implement the background threading and UI that I needed.  It turned out to be an ideal solution for my specific requirements.

It was easy to install, had no other dependencies on additional services and background jobs were persisted in a storage mechanism of your choice.

(image source https://www.hangfire.io/)

Installation and Setup

Installing and setting up Hangfire is straightforward. You can download it as  NuGet package and make a few tweaks to your ASP.NET Core web app. Literally a few tweaks.

If you want to leverage the dashboard (more on that in a bit), you only need to add a few lines of code for that as well.

It’s one of the smoothest installations I’ve had when you consider all the functionality that’s on offer.

Key Features

I won’t go into all the features, but some include:

  • Dashboards to visualise performance, queued work, failed jobs
  • Detailed screen to drill down into the background job details
  • Calling methods in the background
  • Calling methods with a delay
  • Passing arguments to background methods
  • Passing dependencies
  • Using IoC Containers

You can find out more about the key features that ship with Hangfire here.

Invoking Hangfire from ASP.NET Core

I was looking to invoke a background thread that accepted a parameter (customer id) in the constructor.

To that end, I had a class within an API which contained a method to get the chatbots data.

The constructor for this class required the customer id parameter.

This caused me a few headaches with Hangfire but after a little reading on the documentation site, it turns out that all you need to do is to implement a custom Job Activator.

Why?

Well, out of the box, Hangfire uses a classes default constructor.  i.e. the constructor that has no parameter. Doh! After sorting out that issue I was good to go.

In terms of invoking a background job, it’s as simple as writing something like:

var jobId = BackgroundJob.Enqueue(
    () => Console.WriteLine("Fire-and-forget!"));

The Verdict

This tool saved me quite a bit of work a few months ago.  I didn’t have to be concerned about managed background threads and could leverage existing APIs I had built. Hangfire also gave business users an easy to understand dashboard to keep them up to date with chatbot data processing.

I have some other data processing middleware that I need to migrate soon that applies Azure Cognitive Services to social data.  For this I’ll most likely use a Web Job or Azure Function as I don’t need much of an interface.

What are you using to invoke and manage background threads in Azure?

JOIN MY EXCLUSIVE EMAIL LIST
Get the latest content and code from the blog posts!
I respect your privacy. No spam. Ever.

Leave a Reply


Theme by Anders Norén