Questions about Hangfire for my particular situation

question
1

Greetings,

Introduction:

At work we use on-premises Windows Servers with .NET apps hosted on IIS.
There are a lot of scheduled tasks that fall into two categories:

  1. .NET logic (some of them big, some of them small, but mostly it’s manipulation of database data)
  2. SQL Server jobs

The job architecture is old and setup like this:

  1. .cmd / .ps1 files get created
  2. Files either do HTTP POST requests (curl for .cmds) to .NET APIs (the ones that do the actual job logic) or they use sqlcmd commands to invoke stored procedures in SQL Servers
  3. Success/failure gets returned

This is annoying and unintuitive, for reasons:

  1. Admin has to create .cmds (which are basically copy-pasted and their content changed) and register job in Windows Task Scheduler
  2. No central place for everyone (non-admins) to see if job succeeded or failed

Hangfire looks like a good solution to upgrade to, but I have a hard time realising how the job architecture should look like? As I said, we have a lot of .NET solutions that work with different SQL servers / databases.

  1. Would there have to be one .NET solution with Hangfire and would that solution have to contain all jobs in it?
  2. What about SQL Server jobs? I’m guessing they should be better off if scheduled in SQL Server itself? I don’t see anything about this in Hangfire.
  3. I know that .NET has a built-in TaskScheduler class which can be used to schedule service logic, why not use that instead? Or could it be used together with Hangfire?

It seems like a lot of refactoring should be done. Looking forward to any thoughts and suggestions.

Thank you <3

2

This is kind of vague. There are two parts, reading the file and communicating with .net APIs. I think Hangfire would be a good choice for reading files and doing api calls if you an ETL/ELT application isn’t viable.

Would there have to be one .NET solution with Hangfire and would that solution have to contain all jobs in it?

Hangfire can be added to an existing web application or desktop/console/service application. It can also be a stand alone application/service. You can connect the Hangfire dashboard to multiple Hangfire instances. You can also have multiple Hangfire instances pointing to the same database, just specify a unique schema for each one. How you break it up is up to you.

What about SQL Server jobs? I’m guessing they should be better off if scheduled in SQL Server itself? I don’t see anything about this in Hangfire.

If the SQL Server jobs are running t-sql then it doesn’t have to change. You could create Hangfire jobs that call an equivalent stored procedure so you have a common interface (the dashboard). If you’re looking to migrate the t-sql to .net, Hangfire could also be an option.

I know that .NET has a built-in TaskScheduler class which can be used to schedule service logic, why not use that instead? Or could it be used together with Hangfire?

If you’re going to use Hangfire then I would use the scheduling/recurring features built into Hangfire. This gives you a consistent view (the dashboard) of the jobs.

Where I work we use messaging/unit of work for most things. Areas that rely on third parties or tasks that are measured in seconds instead of milliseconds get moved to Hangfire. We also find their scheduled job to be more intuitive than a deferred message.

3

Thanks for the reply.

So theoretically, could I have such a system:

  • one application with Hangfire dashboard, just for the sake of UI
  • lots of applications that contain the actual job logic and start/stop jobs? (say each application is split into different business logic)
4

Yes. I don’t know how well the dashboard will perform if you connect it to “lots” of instances.

If each application has it’s own database you would just configure Hangfire to use that database within the application. If they share a database you can configure a schema unique to each application.