Kentico CMS provides a great platform for custom applications. With an extremely flexible and extendable architecture, developers can quickly achieve any functionality using any of the Kentico API’s or developing their own custom classes and providers. Kentico CMS allows developers to write custom functionality and execute it on a schedule basis through “Scheduled Tasks.” These tasks can be configured to run at regular intervals of up to 1 minute or on demand, if needed.
TIP
For more information on creating custom tasks, check out the Kentico Developer Guide section on
Scheduler.
Scheduled Tasks
While tasks within Kentico work great, I recently found an issue where a task was not being executed at the interval I had set. After some investigation, I found out some important things about tasks I wanted to share. Scheduled tasks are configured via the CMS Site Manager, where admins can set the interval at which the task should run. This setting actually sets when the task is ready, not when it actually executes. By default, Kentico CMS tasks are configured in such that on any Page “End_Request”, the site will go check for any task that is “ready.” If it has been flagged, Kentico will then execute the task.
Scheduled Task Configuration
For most sites the above configuration will be just fine. Typically, users are very active on the site and therefore the “End_Request” event is happening all the time, ensuring that “ready” tasks are executed. The site I was working on was actually still in development and was not getting very much traffic. That’s when I found the above configuration to not be suitable. My “ready” tasks were never being executed because there were no “End_Requests” events being fired. After scratching my head on this a bit, I decided to dig into the Developer’s Guide and see what I could find.
Kentico Developer's Guide - Web Config Parameters
In the Developer’s Guide was the answer (as is the case most of the time). In the “web.config” section, there are several keys related to the Scheduler and its functionality. Kentico, being such a forward thinking company, had already provided a number of AppSettings keys that can override the default the functionality for the Scheduler and force the site to execute tasks without requiring the “End_Request.” This is accomplished by configuring the site to regularly hit a URL internal to the site. In actuality, the site still does rely on the “End_Request” to process the tasks, however, the new settings don’t require user interaction as the site is constantly hitting itself to fire the vent.
The web.config keys for the configuring the Scheduler are:
| Key |
Description |
Sample Value |
|
CMSUseAutomaticScheduler
|
Indicates if automatic scheduling should be used. When enabled, the scheduler periodically requests the cmspages/scheduler.aspx page which ensures that scheduled tasks are processed regularly, even if there is no website activity.
If turned off (false - by default), tasks are processed at the end of standard page requests.
|
<add key="CMSUseAutomaticScheduler" value="true" />
|
|
CMSRunSchedulerWithinRequest
|
If true (the default value), the scheduler is executed within the standard EndRequest event of a page. If false, the scheduler is executed via the ~/cmspages/scheduler.aspx page.
|
<add key="CMSRunSchedulerWithinRequest" value="false" />
|
|
CMSSchedulerURL
|
URL of the physical location of the scheduler.aspx page.
The default value is ~/cmspages/scheduler.aspx
|
<add key="CMSSchedulerURL" value="https://domain/cmspages/scheduler.aspx" />
|
|
CMSSchedulerAcceptAllCertificates
|
If true, all security certificates (including not valid ones) will be accepted when accessing the scheduler.aspx page via a secured protocol.
The default value is false.
|
<add key="CMSSchedulerAcceptAllCertificates" value="true" />
|
|
CMSSchedulerUserName
|
Sets the user name under which the scheduler.aspx page should be accessed (e.g. when using windows authentication).
The default value is "" (blank username).
|
<add key="CMSSchedulerUserName" value="office\myname" />
|
|
CMSSchedulerPassword
|
Sets the password for the user name under which the scheduler.aspx page should be accessed.
The default value is "" (blank password).
|
<add key="CMSSchedulerPassword" value="mypassword123" />
|
|
CMSLogActivityImmediatelyToDB
|
If false, activities are logged to temporary files on the server disk, which are then regularly processed by a scheduled task. Otherwise, activities are logged immediately to the database.
The default value is false.
Please note that logging activities directly to the database may cause performance issues on high‑traffic websites.
|
<add key="CMSLogActivityImmediatelyToDB" value="true"/>
|
Kentico has provided notes on each of these settings to clearly identify their purpose. These settings can quickly be added to a site to change the behavior of the Scheduler and execute tasks at their designated interval, regardless of site traffic. I think it’s worth noting that you can even added the ability to provide an AD username / password to pass to the “Scheduler processing page” if the site is configured to use Windows Authentication.
TIP
I recommend adding code to write to the event log within your task to make sure your code is executing at the scheduled interval. I typically wrap this in a variable I set in the task parameters so I can enable / disable it quickly.
Scheduled Task Event Log
I have used scheduled tasks in nearly all of the Kentico sites I’ve developed. They provide a quick and easy way to execute functionality and integration. The ability to completely manipulate and configure the scheduler process is yet another example of the functionality and flexibility of Kentico CMS.
Hope this helps you schedule your code easier and good luck!