Ever need to write some disconnected process at a scheduled interval? Any time you need to run a scheduled process you can use the DNN Scheduler for your specific job. In this article I'm going to provide an example and show you how to code your own scheduler class for DotNetNuke. We'll also cover configuring the scheduler service and some options it provides.

Introduction

In this specific project I needed to write a service that would go out and spider RSS feeds that I define and populate an index with the contents. Since my DNN site is hosted at provider, it makes it hard for me to use a separate application to perform the spider and index population. The ideal situation would be to have everything included in my DNN base install.

For this specific spider operation, I needed to specify specific intervals for the RSS feeds to be checked and then populate the index. Currently this happens every couple hours, but the schedule would need to be independent of the spider and indexing code. These requirements are provided by the DNN scheduler.

Writing a Scheduler Class

In this specific example, I'm going to focus on what code you need to write in order to use the scheduler service provided by DNN, and not the actual RSS spider or indexing code. Our scheduler class is going to call our spider and index methods contained in a separate class.

Do enable my module to interface with the DNN scheduler, I created a class called ScheduledIndex.vb and added it to my module project. It's really a pretty simple class by itself. The main thing is we're going to inherit from the DotNetNuke.Services.Scheduling.SchedulerClient, and create a new method:

Imports System.Configuration
Imports DotNetNuke
Imports System.Web

Namespace Santry.Modules.RSSFullText
    Public Class ScheduledIndex
        Inherits DotNetNuke.Services.Scheduling.SchedulerClient

        Public Sub New(ByVal objScheduleHistoryItem As _
          DotNetNuke.Services.Scheduling.ScheduleHistoryItem)
            MyBase.New()
            Me.ScheduleHistoryItem = objScheduleHistoryItem
        End Sub
 

All your classes that are going to use the scheduler will look just like this code above. The real work is going to be in the DoWork method. And in this case, I'm going to call my spider routine (HTTPCheck), and then my indexing routine (AddDocumentsToIndex). Remember the focus here is the teaching you how to use the scheduler and not the spidering or indexing so the code isn't provided for that.

Public Overrides Sub DoWork()
    Try
        'run indexing events.
        Me.Progressing()
        'run process
        Dim hTTPCheck As hTTPCheck = New hTTPCheck
        hTTPCheck.SelectAllRss()
        Dim BBBDb As New BBBDatabase
        BBBDb.AddDocumentsToIndex(False, "vwrssfeeds")
        ' BBBDb = Nothing
        Me.ScheduleHistoryItem.AddLogNote("RSS Incremental Build Suceeded")
        Me.ScheduleHistoryItem.Succeeded = True
    Catch ex As Exception
        Me.ScheduleHistoryItem.Succeeded = False
        Me.ScheduleHistoryItem.AddLogNote("Index build failed. " & ex.ToString)
        Me.Errored(ex)
    End Try
End Sub

End Class
End Namespace

Adding to the Scheduler

We're not done yet, we still need to set up a scheduled task and point it to our class.

First you need to go to the Host menu of DNN (login as a super user), then select Schedule from the menu options.

Here you will see a list of all scheduled tasks currently configured on your DNN portal. To add a new item and point it to your new class, just click on the "Add Item to Schedule" link at the bottom of the page, or select it from the menu options. Here you will see the Edit Schedule configuration form (see Figure 1).

Figure 1: Adding an Item to the Scheduler Service in DNN.

You can see from the form in the figure you need to first add the full namespace to the class you want to schedule. In this case it is the ScheduledIndex class (as in the code sample above), which is contained in my project (in this case with a namespace of Santry.Modules.RSSFullText). And the second value in the same textbox is the name of the actual DLL file located within the bin directory of your DNN install.

Then enter in values for the additional items in the form. Remember they may not all apply as in the example above:

1. Full Class Name and Assembly (as described above).

2. Schedule Enable - This option enables you to turn off and on the item that is scheduled. In this case I may not want the index to run if I do a manual build on the index so two process aren't hitting the index at the same time causing an error.

3. Time Lapse - How much time between each time the process is run.

4. Retry Frequency - How many times should the scheduler try again between failures.

5. Retain Schedule History - Enables you to view the log messages of your method. Use to check success or failure, or any other messages you want to track.

6. Run on Event - Default is nothing, or you can run on Application_OnStart, you define other events.

7. Catch Up Enabled - In case the item can't run, like the server being rebooted, you can check this to catch up on missed schedules, unchecked it will just continue on.

8. Object Dependencies - You can require processes to be ran before this scheduled item preventing any conflicts of having multiple scheduled items accessing the same resources.

9. Run on Servers - For web farms you may want the process to run only once, then specify a single server for the job to run.

Things to Remember

Since the scheduler is a multi-threaded process that runs outside of the context of the Web request (when ran in *Timer Method which is the default), you can't use some objects that you might use when doing module development. For example anything that relies on Request variables aren't going to work since this isn't being triggered by a user request.

*Timer Mode vs. Request Mode

DNN supports two methods for scheduling items (accessible in the Host Settings page under Advanced Settings | Other Settings). The timer method allows the scheduled item to run outside of the user request in a multi-threaded mode. This is ideal in that it is running outside of the user request and the user notices no lag due to some scheduled process being ran in conjunction with their request. The other mode is User Method meaning the scheduled item is ran during a user request. This method enables you to use the request methods of the current context, but it can slow things down considerably for the user experience since the operations are ran within a users request.