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:
- .NET logic (some of them big, some of them small, but mostly it’s manipulation of database data)
- SQL Server jobs
The job architecture is old and setup like this:
- .cmd / .ps1 files get created
- 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
- Success/failure gets returned
This is annoying and unintuitive, for reasons:
- Admin has to create .cmds (which are basically copy-pasted and their content changed) and register job in Windows Task Scheduler
- 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.
- Would there have to be one .NET solution with Hangfire and would that solution have to contain all jobs in it?
- 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.
- 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