Anyone familiar with Sitefinity knows that the CMS comes with a vast toolbox, and administrators and content editors can create engaging web sites without any need of a programmer or knowledge of .NET. However, with a little imagination, it doesn’t take long to discover how customizing certain elements of Sitefinity can have huge benefits. This extends beyond just creating custom user controls and front facing renderings to throw on a public page. Automating backend processes or running tasks to manage content can save valuable hours of manual content entry and/or free up administrators from tedious management.
There are various classes and interfaces that can be implemented to customize backend features in Sitefinity. In terms of automating CMS processes and executing behind the scenes logic, Scheduled Tasks and Background Tasks are two ways to go. Developers at Americaneagle.com leverage both of these options frequently on custom sites for automating certain pieces of functionality. Scheduled tasks are often used to run regular imports of data, export Sitefinity data on a regular basis, or periodically purge custom files or data that’s in the system.
It doesn’t take much research to find exactly what you need for implementing a Scheduled task. Googling "Sitefinity schedule task" will yield a link straight over to Sitefinity’s own documentation. There are only two components that you need for getting a task implemented:
•Custom task class. This contains the custom logic to run regularly.
•Scheduler or event that kicks off your new task. Scheduling creates an entry in the sf_scheduled_tasks data table and contains relevant scheduling information for Sitefinity.
An additional suggested, but not required, component is a custom configuration class for letting administrators change the frequency of the task, or any additional configurable parameters.
Regarding the class that needs to be implemented for the new task, add a new class to your Sitefinity web application that inherits from Telerik.Sitefinity.Scheduling.ScheduledTask. The class inheriting from ScheduledTask will require you to override TaskName (property for the name of your custom class) and the ExecuteTask method (where should place your business/automated logic). ExecuteTask gets called every time the ExecuteTime is surpassed by the current server time. In order for the task to schedule itself, the ExecuteTask method should contains logic at the end to reschedule itself after a certain amount of time. This is a good item to leave as configurable in the settings.
Once the task is set to reschedule itself, all you need is a way to start the scheduled task initially. Often this can be done in the global.asax, to start the task whenever the web application is started. Personally, I like to create a custom backend page with controls for starting and stopping the scheduled task. Either method works.
Once the method for starting the task is created, your scheduled task is all set to run.
Using scheduled tasks are great and have a lot of usefulness for automating processes in the CMS, but sometimes it can be overkill if you just want to execute logic on demand a single time in the background. This is where background tasks come in.
Background tasks are little harder to find documentation for online, but by exploring through the CMS you can see many cases where they are probably being utilized. For instance, when you rebuild a search index in the CMS, you’re able to rebuild several individually and nothing appears to hang up to the administrator, the index is being rebuilt in the background (at least, it appears that way).
Using the help of the Telerik JustDecompile tool, I’m able to dig into these internal indexing tasks and see that they are implementing IBackgroundTask (Telerik.Sitefinity.BackgroundTasks.IBackgroundTask, specifically) which I am able to implement in my custom code.
From my brief exploration, there appears to just be two requires methods I need to make sure I handle: Run and RunTask.
Just a couple lines of code and my Background task is done. Note that RunTask calls a helper class that does the custom logic that I want, but in terms of getting this background task implemented - this was all I needed.
Running the task is also fairly straight forward. Wherever you want to kick off this task, create a new instance of it and call its Run method. Again, by using JustDecompile I was able to copy most of what Sitefinity implemented for search indexing.
There is some additional handling in there for if the task should run async, but I’ll let you investigate on your own. :)
Both of these task implementations, Background and Scheduled, have given our development teams a lot of flexibility for automating processes which can help create a lot of complex pieces that many of our sites demand.