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.
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.
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.
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!"));
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?
Leave a Reply