In this tutorial, you will learn some useful tips that can apply when you are using with Hangfire within Episerver. Out of the box, Episerver provides a scheduler to cater for re-occurring tasks. This mechanism can be very useful for simple tasks, however, it does have limitations. The built-in scheduler user-interface is very limited. it is close to impossible to debug tasks within the UI and you will need access to the logs. Not ideal in production.

Hangfire in Episerver

On most projects, if I need to build a lot of scheduled tasks then I tend to use Hangfire. Hangfire is free, it is more feature-rich than the Epi scheduler, it comes with a dashboard that gives better visibility on what tasks are scheduled, when and what has passed, and failed. If you think this sounds great and you want to use Hangfire on your project then I have written an Episerver installation guide here.

Assuming you have hangfire installed correctly, how do you use it? For this tutorial lets create a very crude task that will render a content ID:

The code to add this task onto the que, would look like this:

IBackgroundJobClient is a hangfire API. To add something to the queue it uses generics. This allows func access to MyTask methods. Is added into the hangfire queue and once executed the method would return a string. This is great but if you looked within the completed job queue you will notice that the name is very undescriptive. The job name just uses reflection to show the class and method of the calling task.

What happens if you had a job to reindex all the content within the website? How could you tell what content has been scheduled and what hasn't?

When working with Epi I would recommend that you change the job name to always render the content id of the content you are processing. To do this you can use the DisplayName attribute. By decorating a method with this attribute you can configure the job name, like so:

Not the {0} relates to the parameters being passed into the task. In this instance, there is the only parameter, id. If I had a second parameter I could render the second parameter in the job name like this:

Doing this will make it a lot easier to figure out what is going on within Hangfire. Another thing to keep in mind is that if you use an interface you may want to decorate the interface with DisaplyName.

Another useful tip when using Hangfire with Epi is to check the queue to see if the content you are working with is either already scheduled or, has been processed recently. This can be done using Hangfires JobStorage API. To check the queue like this you can use the following:

In the code above we are checking the default queue to see if any jobs with the start pages ID are scheduled to be processed. The second of EnqueuedJobs() is the start location. if you want to start at the most recent entry, set this to 0. The third parameter,10, is the number of jobs to check. The larger the value the longer the check will take If you want to check if the home page has recently been processed by Hangfire, you can check the succeeded job queue like this:

Armed with these things you should be able to use Hangfire like a pro, enjoy!