Sections

ColdFusion CFEXECUTE

Mike's Notes

I am learning to use <cfexecute> to enable Pipi to use the command line to control its host server autonomously.
  • The server has no public access.
  • How to do this safely?
    • See notes from
    • Adobe Help
    • CFDocs
    • Ben Nadel (2020)
    • Brian Harvey - Heartland Web Development (2015)
  • Code examples below in yellow

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

11/05/2025

CFExecute

By: 
Adobe Help: 

Executes a ColdFusion developer-specified process on a server computer.


<cfexecute
name = "application name"
arguments = "command line arguments"
outputFile = "output filename"
errorFile = "filename to store error output"
timeout = "timeout interval"
variable = "variable name"
errorVariable = "variable name">
...
</cfexecute>

CFExecute

By: 
CFDocs: 

name (string)

Absolute path of the application to execute.

On Windows, you must specify an extension; for example, C:\myapp.exe.

arguments (any)

Command-line variables passed to application. If specified as string, it is processed as follows:

  • Windows: passed to process control subsystem for parsing.
  • UNIX: tokenized into an array of arguments. The default token separator is a space; you can delimit arguments that have embedded spaces with double quotation marks.
If passed as array, it is processed as follows:
  • Windows: elements are concatenated into a string of tokens, separated by spaces. Passed to process control subsystem for parsing.
  • UNIX: elements are copied into an array of exec() arguments

outputfile (string)

File to which to direct program output. If no outputfile or variable attribute is specified, output is displayed on the page from which it was called.

If not an absolute path (starting with a drive letter and a colon, or a forward or  backward slash), it is relative to the CFML temporary directory, which is returned 

by the GetTempDirectory function.

variable (string)

Variable in which to put program output. If no outputfile or variable attribute is specified, output is displayed on page from which it was called.

timeout (numeric)

Default: 0

Length of time, in seconds, that CFML waits for output from the spawned program.

errorVariable (string)

The name of a variable in which to save the error stream output.

errorFile (string)

The pathname of a file in which to save the error stream output. If not an absolute path (starting a with a drive letter and a colon, or a forward or backward slash), it is relative to the ColdFusion temporary directory, which is returned by the GetTempDirectory function.

terminateOnTimeout (boolean

Default: false

Lucee 4.5+ Terminate the process after the specified timeout is reached. Ignored if timeout is not set or is 0.

directory (string)

Lucee 5.3.8+ The working directory in which to execute the command

Running CFExecute From A Given Working Directory In Lucee CFML 5.2.9.31

By: Ben Nadel
bennadel.com: 05/04/2020

When you invoke the CFExecute tag in ColdFusion, there is no option to execute the given command from a particular working directory. That's why I recently looked at using the ProcessBuilder class to execute commands in ColdFusion. That said, the default community response to anyone who runs into a limitation with the CFExecute tag is generally, "Put your logic in a bash-script and then execute the bash-script.". I don't really know anything about bash scripting (the syntax looks utterly cryptic); so, I thought, it might be fun to try and create a bash script that will proxy arbitrary commands in order to execute them in a given working directory in Lucee CFML 5.2.9.31.

The goal here is to create a bash script that will take N-arguments in which the 1st argument is the working directory from which to evaluate the rest (2...N) of the arguments. So, instead of running something like:

ls -al path/to/things

... we could run something like:

my-proxy path/to ls -al things

In this case, we'd be telling the my-proxy command to execute ls -al things from within the path/to working directory. To hard-code this example as a bash script, we could write something like this:

cd path/to # Change working directory.

ls -al ./things # Run ls command RELATIVE to WORKING DIRECTORY.

The hard-coded version illustrates what we're trying to do; but, we want this concept to by dynamic such that we could run any command from any directory. To this end, I've created the following bash script, execute_from_directory.sh, through much trial and error:

#!/bin/sh

# In the current script invocation, the first argument needs to be the WORKING DIRECTORY
# from whence the rest of the script will be executed.
working_directory=$1

# Now that we have the working directory argument saved, SHIFT IT OFF the arguments list.
# This will leave us with a "$@" array that contains the REST of the arguments.
shift

# Move to the target working directory.
cd "$working_directory"

# Execute the REST of command from within the new working directory.
# --
# NOTE: The $@ is a special array in BASH that contains the input arguments used to
# invoke the current executable.
"$@"

CAUTION: Again, I have no experience with bash script. As such, please take this exploration with a grain of salt - a point of inspiration, not a source of truth!

What this is saying, as best as I think I understand it, is take the first argument as the desired working directory. Then, use the shift command to shift all the other arguments over one (essentially shifting the first item off of the arguments array). Then, change working directory and execute the rest of the arguments from within the new working directory.

Because we are using the special arguments array notation, "$@", instead of hard-coding anything, we should be able to pass-in an arbitrary set of arguments. I think. Again, I have next to no experience here.

Once I created this bash-script, I had to change the permissions to allow for execution:

chmod +x execute_from_directory.sh

To test this from the command-line, outside of ColdFusion, I tried to list out the files in my images directory - path/to/my-cool-images - using a combination of working directories and relative paths:

wwwroot# ./execute_from_directory.sh path/to ls -al ./my-cool-images

total 17740
drwxr-xr-x 11 root root     352 Apr 11 11:28 .
drwxr-xr-x  4 root root     128 Apr 15 10:07 ..
-rw-r--r--  1 root root 1628611 Dec  1 20:04 broad-city-yas-queen.gif
-rw-r--r--  1 root root  188287 Mar  4 14:09 cfml-state-of-the-union.jpg
-rw-------  1 root root 3469447 Jan 28 16:59 dramatic-goose.gif
-rw-------  1 root root 2991674 Dec 14 15:39 engineering-mistakes.gif
-rw-r--r--  1 root root  531285 Dec  1 21:10 monolith-to-microservices.jpg
-rw-r--r--  1 root root  243006 Dec 24 12:34 phoenix-project.jpg
-rw-r--r--  1 root root 1065244 Jan 22 14:41 rob-lowe-literally.gif
-rw-r--r--  1 root root 7482444 Mar 25 10:15 thanos-inifinity-stones.gif
-rw-r--r--  1 root root  239090 Dec 29 13:08 unicorn-project.jpg

As you can see, I was able to execute the ls command from within the path/to working directory! Woot woot!

To test this from ColdFusion, I'm going to recreate my zip storage experiment; but, instead of using the ProcessBuilder class, I'm going to use the CFExecute tag to run the zip command through my execute_from_directory.sh bash script:

<cfscript>
// Reset demo on subsequent executions.
cleanupFile( "./images.zip" );
// ------------------------------------------------------------------------------- //
// ------------------------------------------------------------------------------- //
// Normally, CFExecute has no sense of a "working directory" during execution.
// However, by proxying our command-line execution through a Shell Script (.sh), we
// can CD (change directory) to a given directory and then dynamically execute the
// rest of the commands.
executeFromDirectory(
// This is the WORKING DIRECTORY that will become the context for the rest of
// the script execution.
expandPath( "./path/to" ),
// This is the command that we are going to execute from the WORKING DIRECTORY.
// In this case, we will execute the ZIP command using RELATIVE PATHS that are
// relative to the above WORKING DIRECTORY.
"zip",
// These are the arguments to pass to the ZIP command.
[
// Regulate the speed of compression: 0 means NO compression. This is setting
// the compression method to STORE, as opposed to DEFLATE, which is the
// default method. This will apply to all files within the zip - if we wanted
// to target only a subset of file-types, we could have used "-n" to white-
// list a subset of the input files (ex, "-n .gif:.jpg:.jpeg:.png").
"-0",
// Recurse the input directory.
"-r",
// Define the OUTPUT file (our generated ZIP file).
expandPath( "./images.zip" ),
// Define the INPUT file - NOTE that this path is RELATIVE TO THE WORKING
// DIRECTORY! By using a relative directory, it allows us to generate a ZIP
// in which the relative paths become the entries in the resultant archive.
"./my-cool-images",
// Don't include files in zip.
"-x *.DS_Store"
]
);
echo( "<br />" );
echo( "Zip file size: " );
echo( numberFormat( getFileInfo( "./images.zip" ).size ) & " bytes" );
echo( "<br /><br />" );
// ------------------------------------------------------------------------------- //
// ------------------------------------------------------------------------------- //
/**
* I execute the given series of commands from the given working directory. The
* standard output is printed to the page. If an error is returned, the page request
* is aborted.
* @workingDirectory I am the working directory from whence to execute commands.
* @commandName I am the command to execute from the working directory.
* @commandArguments I am the arguments for the command.
*/
public void function executeFromDirectory(
required string workingDirectory,
required string commandName,
required array commandArguments
) {
// The Shell Script that's going to proxy the commands is expecting the working
// directory to be the first argument. As such, let's create a normalized set of
// arguments for our proxy that contains the working directory first, followed by
// the rest of the commands.
var normalizedArguments = [ workingDirectory ]
.append( commandName )
.append( commandArguments, true )
;
execute
name = expandPath( "./execute_from_directory.sh" ),
arguments = normalizedArguments.toList( " " )
variable = "local.successOutput"
errorVariable = "local.errorOutput"
timeout = 10
terminateOnTimeout = true
;
if ( len( errorOutput ?: "" ) ) {
dump( errorOutput );
abort;
}
echo( "<pre>" & ( successOutput ?: "" ) & "</pre>" );
}
/**
* I delete the given file if it exists.
* @filename I am the file being deleted.
*/
public void function cleanupFile( required string filename ) {
if ( fileExists( filename ) ) {
fileDelete( filename );
}
}
</cfscript>


As you can see, I've created an executeFromDirectory() User-Defined Function (UDF) which takes, as its first argument, the working directory from which we are going to execute the rest of the commands. Then, instead of executing the zip command directly, we are proxying it through our bash script.

And, when we run the above ColdFusion code, we get the following output:



Very cool! It worked! As you can see from the zip debug output, the entries in the archive are based on the relative paths from the working directory that we passed to our proxy.


Now that I know that the ProcessBuilder class exists, I'll probably just go with that approach in the future. That said, it was exciting (and, honestly, very frustrating) for me to write my first real bash-script to allow the CFExecute tag to execute commands from a given working directory in Lucee CFML. Bash scripting seems.... crazy; but, it also seems something worth learning a bit more about.

You Might Also Enjoy Some of My Other Posts

Run commands via SSH to a remote server using ColdFusion, Putty and Plink

By: Brian Harvey
Heartland Web Development: 27 April 2015

In order to create a real time dynamic IP whitelist solution for a client I needed to be able to SSH into a pfSense fiewall using ColdFusion and kick off a few .sh files to update the firewall's ip whitelist. ColdFusion doesn't have the ability to SSH directly, but by using <cfexecute>, Putty and Plink you can get the job done.

Here is how to do it:

1.  Download Putty and Plink. 
Putty is an SSH client for windows, and Plink is a command line interface to Putty.

2. Launch Putty and create a "stored session" to the target server. I named my stored session "firewall".  Now log into the remote server using the saved session so that an authentication key is generated and stored in Putty. Once you have generated an authentication key and are logged in you can exit your session and close Putty.



3. Now you can run <cfexecute> to SSH into the remote server and run .sh files.


<cfexecute name="C:\WINDOWS\system32\cmd.exe"

      arguments="/c C:\plink.exe -v root@firewall -pw MyPassword /cf/conf/putconfig.sh"  timeout="5">

</cfexecute>

There was one "gotcha" I discovered with running the command using ColdFusion.  I was able to run the plink command all day long from the cmd prompt:

C:\plink.exe -v root@firewall -pw MyPassword /cf/conf/putconfig.sh.

But when I tried to run it as an argument in <cfexecute> it would fail.  I was stumped until I came across this blog post by Ben Forta.

Ben points out that in Windows, you need to insert "/c" as the first argument in the string in order to tell Windows to to spin up a command interpreter to run and terminate upon completion. 

This Works:  arguments="/c C:\plink.exe -v root@firewall -pw MyPassword /cf/conf/putconfig.sh"  timeout="5"

This Doesn't Work:  arguments="C:\plink.exe -v root@firewall -pw MyPassword /cf/conf/putconfig.sh"  timeout="5"

That little extra had me spinning my wheels for the better part of a day until I ran across Ben's post.

ColdFusion CFSCHEDULE

Mike's Notes

Here are some notes on using the ColdFusion tag CFSchedule. It is copied from the websites of Charlie Arehart and Ben Nadel, both CFML experts.
  • Pipi has used <cfschedule> as a system timer since version 4 (2005)
  • Here is more information about using this system tag 
  • The sample code is in yellow

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subjects > CFML
  • Home > Handbook > 

Last Updated

18/04/2025

CF Scheduled Tasks: more than you may know, and should

By: Charlie Arehart
carehart.org: 31/07/2023

CF Scheduled tasks based on the open-source Quartz framework, since CF10

  • Its format (like cron format for Spring f/w) adds a leading “second” value
  • Format is: second, minute, hour, day of month, month, day of week, year
  • “second” value is required, as are the rest, but “year” is optional
  • quartz-scheduler.org/documentation/quartz-2.2.2/tutorials/crontrigger.html
  • Free online tool
  • freeformatter.com/cron-expression-generator-quartz.html
  • Quartz version in CF2023 is 2.4.0
  • quartz.properties settings (in cfusion\lib\quartz) unchanged from cf10-2023
  • Customize quartz: Advanced users can customize Quartz using quartz.properties available in cfusion\lib\quartz

more in CF Scheduled Tasks: more than you may know, and should (pdf of 31 July 2023 presentation)

Creating A Database-Driven Scheduled Task Runner In ColdFusion

By: Ben Nadel
bennadel.com: 11/06/2023

While Dig Deep Fitness won't have much in the way of asynchronous processing (at least initially), there are some "cleanup" tasks that I need to run. As such, I've created a scheduled task as part of the application bootstrapping. This approach has served me well over the years: I create a single ColdFusion scheduled task that pulls task data out of the database and acts as the centralized ingress to all the actual tasks that need to be run.

As much as possible, I like to own the logic in my application. Which means moving as much configuration into the Application.cfc as is possible. Thankfully, ColdFusion allows for a whole host of per-application settings such as SMTP mail servers, database datasources, file mappings, etc. By using the CFSchedule tag, we can include ColdFusion scheduled task configuration right there in the onApplicationStart() event handler.

Here's a snippet of my onApplicationStart() method that sets up the single ingress point for all of my scheduled tasks. The ingress task is designed to run every 60-seconds.


component {
 public void function onApplicationStart() {

  // ... truncated code ...

  var config = getConfigSettings( useCacheConfig = false );

cfschedule(
  action = "update",
  task = "Task Runner",
  group = "Dig Deep Fitness",
  mode = "application",
  operation = "HTTPRequest",
  url = "#config.scheduledTasks.url#/index.cfm?event=system.tasks",
  startDate = "1970-01-01",
  startTime = "00:00 AM",
  interval = 60 // Every 60-seconds.
);

// ... truncated code ...

  }
}

The action="update" will either create or modify the scheduled task with the given name. As such, this CFSchedule tag is idempotent, in that it is safe to run over-and-over again (every time the application gets bootstrapped).

The CFSchedule tag has a lot of options. But, I don't really care about most of the features. I just want it to run my centralized task runner (ie, make a request to the given url) once a minute; and then, I'll let my ColdFusion application handle the rest of the logic. For me, this reduces the amount of "magic"; and leads to better maintainability over time.

To manage the scheduled task state, I'm using a simple database table. In this table, the primary key (id) is the name of the ColdFusion component that will implement the actual task logic. Tasks can either be designated as daily tasks that run once at a given time (ex, 12:00 AM); or, they can be designated as interval tasks that run once every N-minutes.


CREATE TABLE `scheduled_task` (
`id` varchar(50) NOT NULL,
`description` varchar(50) NOT NULL,
`isDailyTask` tinyint unsigned NOT NULL,
`timeOfDay` time NOT NULL,
`intervalInMinutes` int unsigned NOT NULL,
`lastExecutedAt` datetime NOT NULL,
`nextExecutedAt` datetime NOT NULL,
PRIMARY KEY (`id`) USING BTREE,
KEY `byExecutionDate` (`nextExecutedAt`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

This table can get more robust depending on your application needs. For example, at work, we include a "parameters" column that allows data to be passed from one task execution to another. For Dig Deep Fitness, I don't need this level of robustness (yet).

My single CFSchedule tag is setup to invoke a URL end-point. The end-point does nothing but turn around and call my Task "Workflow" component:

<cfscript>

scheduledTaskWorkflow = request.ioc.get( "lib.workflow.ScheduledTaskWorkflow" );

// ------------------------------------------------------------------------------- //

// ------------------------------------------------------------------------------- //

taskCount = scheduledTaskWorkflow.executeOverdueTasks();

</cfscript>

<cfsavecontent variable="request.template.primaryContent">

<cfoutput>
<p>
Executed tasks: #numberFormat( taskCount )#
</p>
</cfoutput>

</cfsavecontent>


As you can see, this ColdFusion template turns around and calls executeOverdueTasks(). This method looks at the database for overdue tasks; and then invokes each one as a separate HTTP call. Unlike Lucee CFML, which can have nested threads, Adobe ColdFusion cannot have nested threads (as of ACF 2021). As such, in order to allow for each separate task to spawns its own child threads (as needed), I need each task to be executed as a top-level ColdFusion page request.

Here's the part of my ScheduledTaskWorkflow.cfc that relates to the centralized ingress / overall task runner:


// ---
// PRIVATE METHODS.
// ---

/**
* Each task is triggered as an individual HTTP request so that it can run in its own
* context and spawn sub-threads if necessary.
*/
private void function makeTaskRequest( required struct task ) {

// NOTE: We're using a small timeout because we want the tasks to all fire in
// parallel (as much as possible).
cfhttp(
result = "local.results",
method = "post",
url = "#scheduledTasks.url#/index.cfm?event=system.tasks.executeTask",
timeout = 1
) {

cfhttpparam(
type = "formfield",
name = "taskID",
value = task.id
);
cfhttpparam(
type = "formfield",
name = "password",
value = scheduledTasks.password
);
}

}
The scheduledTaskService.getOverdueTasks() call is just a thin wrapper around a database call to get rows where the nextExecutedAt value is less than now. Each overdue task is then translated into a subsequent CFHttp call to an end-point that executes a specific task. Note that I am passing through a password field in an attempt to secure the task execution.

The end-point for the specific task just turns around and calls back into this workflow:


// ---
// PUBLIC METHODS.
// ---

/**
* I execute any overdue scheduled tasks.
*/
public numeric function executeOverdueTasks() {

var tasks = scheduledTaskService.getOverdueTasks();

for ( var task in tasks ) {

makeTaskRequest( task );

}

return( tasks.len() );

}

<cfscript>
scheduledTaskWorkflow = request.ioc.get( "lib.workflow.ScheduledTaskWorkflow" );
// ------------------------------------------------------------------------------- //
// ------------------------------------------------------------------------------- //
param name="form.taskID" type="string";
param name="form.password" type="string";
scheduledTaskWorkflow.executeOverdueTask( form.taskID, form.password );
</cfscript>

<cfsavecontent variable="request.template.primaryContent">
<cfoutput>

<p>
Executed task: #encodeForHtml( form.taskID )#
</p>

</cfoutput>
</cfsavecontent>

Here's the part of my ScheduledTaskWorkflow.cfc that relates to the execution of a single task. Remember that the taskID in this case is the filename for the ColdFusion component that implements the logic. I'm using my dependency injection (DI) framework to access that component dynamically in the Inversion of Control (IoC) container:


ioc.get( "lib.workflow.task.#task.id#" )

The workflow logic is fairly straightforward - I get the task, check to see if it's overdue, execute it, and then update the nextExecutedAt date (depending on weather it's a daily task or an interval task).


component {

// Define properties for dependency-injection.
// ... truncated ...

component {

// Define properties for dependency-injection.
// ... truncated code ...

// ---
// PUBLIC METHODS.
// ---

/**
* I execute the overdue scheduled task with the given ID.
*/
public void function executeOverdueTask(
required string taskID,
required string password
) {

if ( compare( password, scheduledTasks.password ) ) {

throw(
type = "App.ScheduledTasks.IncorrectPassword",
message = "Scheduled task invoked with incorrect password."
);

}

var task = scheduledTaskService.getTask( taskID );
var timestamp = clock.utcNow();

if ( task.nextExecutedAt > timestamp ) {

return;

}

lock
name = "ScheduledTaskWorkflow.executeOverdueTask.#task.id#"
type = "exclusive"
timeout = 1
throwOnTimeout = false
{

// Every scheduled task must implement an .executeTask() method.
ioc
.get( "lib.workflow.task.#task.id#" )
.executeTask( task )
;

if ( task.isDailyTask ) {

var lastExecutedAt = clock.utcNow();
var tomorrow = timestamp.add( "d", 1 );
var nextExecutedAt = createDateTime(
year( tomorrow ),
month( tomorrow ),
day( tomorrow ),
hour( task.timeOfDay ),
minute( task.timeOfDay ),
second( task.timeOfDay )
);

} else {

var lastExecutedAt = clock.utcNow();
var nextExecutedAt = lastExecutedAt.add( "n", task.intervalInMinutes );

}

scheduledTaskService.updateTask(
id = task.id,
lastExecutedAt = lastExecutedAt,
nextExecutedAt = nextExecutedAt
);

} // END: Task lock.

}

}

And that's all there is to it. Now, whenever I need to add a new scheduled task, I simply:

Create a ColdFusion component that implements the logic (via an .executeTask() method).

Add a new row to my scheduled_task database table with the execution scheduling properties.

Like I said earlier, I've been using this approach for years and I've always been happy with it. It reduces the "magic" of the scheduled task, and moves as much of the logic in the application where it can be seen, maintained, and included within the source control.

From Adobe help

"Provides a programmatic interface to the ColdFusion scheduling engine. Can run a CFML page at scheduled intervals, with the option to write the page output to a static HTML page. This feature enables you to schedule pages that publish data, such as reports, without waiting while a database transaction is performed to populate the page.

ColdFusion does not invoke Application.cfc methods, when invoking a task's event handler methods."

<cfschedule 
action = "create|modify|run|update|pause|resume|delete|pauseall|resumeall|list" 
task = "task name" 
endDate = "date" 
endTime = "time" 
file = "filename" 
interval = "seconds" 
operation = "HTTPRequest" 
password = "password" 
path = "path to file" 
port = "port number" 
proxyPassword = "password" 
proxyPort = "port number" 
proxyServer = "host name" 
proxyUser = "user name" 
publish = "yes|no" 
resolveURL = "yes|no" 
isDaily = "yes|no" 
overwrite = "yes|no" 
startDate = "date" 
startTime = "time" 
url = "URL" 
username = "user name"> 
group="group1" 
oncomplete="how to handle exception" 
eventhandler="path_to_event_handler" 
onException="refire|pause|invokeHandler" 
cronTime="time" 
repeat="number" 
priority="integer" 
exclude="date|date_range|comma-separated_dates" 
onMisfire = "" 
cluster="yes|no 
mode="server|application" 
retryCount="number" 
OR
<cfschedule
action="create"
task = "task name">

OR 
<cfschedule 
action = "modify" 
task = "task name"> 


OR 
<cfschedule 
action = "delete" 
task = "task name"> 

OR 

<cfschedule 
action = "run" 
task = "task name"> 

OR 

<cfschedule
action = "pauseAll"
group=groupname
> 

OR

<cfschedule
action = "pauseAll"
> 

OR

<cfschedule
action = "resumeAll"
mode = "server|application"
> 

OR

<cfschedule
action = "resumeAll"
group=groupname
> 

OR

<cfschedule
action = "resumeAll"
> 


OR 

<cfschedule 
action = "list" 
mode = "server|application" 
result = "res">

<cfschedule
action = "create|modify|run|update|pause|resume|delete|pauseall|resumeall|list"
task = "task name"
endDate = "date"
endTime = "time"
file = "filename"
interval = "seconds"
operation = "HTTPRequest"
password = "password"
path = "path to file"
port = "port number"
proxyPassword = "password"
proxyPort = "port number"
proxyServer = "host name"
proxyUser = "user name"
publish = "yes|no"
resolveURL = "yes|no"
isDaily = "yes|no"
overwrite = "yes|no"
startDate = "date"
startTime = "time"
url = "URL"
username = "user name">
group="group1"
oncomplete="how to handle exception"
eventhandler="path_to_event_handler"
onException="refire|pause|invokeHandler"
cronTime="time"
repeat="number"
priority="integer"
exclude="date|date_range|comma-separated_dates"
onMisfire = ""
cluster="yes|no
mode="server|application"
retryCount="number" 

OR

<cfschedule
action="create"
task = "task name">

OR 

<cfschedule
action = "modify"
task = "task name"> 

OR 

<cfschedule
action = "delete"
task = "task name"> 

OR 

<cfschedule
action = "run"
task = "task name"> 

OR 

<cfschedule
action = "pauseAll"
group = "groupname"> 

OR

<cfschedule
action = "pauseAll"> 

OR

<cfschedule
action = "resumeAll"
mode = "server|application"> 

OR

<cfschedule
action = "resumeAll"
group = "groupname"> 

OR

<cfschedule
action = "resumeAll"> 

OR 

<cfschedule
action = "list"
mode = "server|application"
result = "res">

Using Scheduler

A great demo of using a CFC

<cfschedule 
action = "create|modify|run|update|pause|resume|delete|pauseall|resumeall|list" 
task = "task name" 
endDate = "date" 
endTime = "time" 
file = "filename" 
interval = "seconds" 
operation = "HTTPRequest" 
password = "password" 
path = "path to file" 
port = "port number" 
proxyPassword = "password" 
proxyPort = "port number" 
proxyServer = "host name" 
proxyUser = "user name" 
publish = "yes|no" 
resolveURL = "yes|no" 
isDaily = "yes|no" 
overwrite = "yes|no" 
startDate = "date" 
startTime = "time" 
url = "URL" 
username = "user name"> 
group="group1" 
oncomplete="how to handle exception" 
eventhandler="path_to_event_handler" 
onException="refire|pause|invokeHandler" 
cronTime="time" 
repeat="number" 
priority="integer" 
exclude="date|date_range|comma-separated_dates" 
onMisfire = "" 
cluster="yes|no 
mode="server|application" 
retryCount="number" 
OR
<cfschedule
action="create"
task = "task name">

OR 
<cfschedule 
action = "modify" 
task = "task name"> 


OR 
<cfschedule 
action = "delete" 
task = "task name"> 

OR 

<cfschedule 
action = "run" 
task = "task name"> 

OR 

<cfschedule
action = "pauseAll"
group=groupname
> 

OR

<cfschedule
action = "pauseAll"
> 

OR

<cfschedule
action = "resumeAll"
mode = "server|application"
> 

OR

<cfschedule
action = "resumeAll"
group=groupname
> 

OR

<cfschedule
action = "resumeAll"
> 


OR 

<cfschedule 
action = "list" 
mode = "server|application" 
result = "res">
<cfschedule 
action = "create|modify|run|update|pause|resume|delete|pauseall|resumeall|list" 
task = "task name" 
endDate = "date" 
endTime = "time" 
file = "filename" 
interval = "seconds" 
operation = "HTTPRequest" 
password = "password" 
path = "path to file" 
port = "port number" 
proxyPassword = "password" 
proxyPort = "port number" 
proxyServer = "host name" 
proxyUser = "user name" 
publish = "yes|no" 
resolveURL = "yes|no" 
isDaily = "yes|no" 
overwrite = "yes|no" 
startDate = "date" 
startTime = "time" 
url = "URL" 
username = "user name"> 
group="group1" 
oncomplete="how to handle exception" 
eventhandler="path_to_event_handler" 
onException="refire|pause|invokeHandler" 
cronTime="time" 
repeat="number" 
priority="integer" 
exclude="date|date_range|comma-separated_dates" 
onMisfire = "" 
cluster="yes|no 
mode="server|application" 
retryCount="number" 
OR
<cfschedule
action="create"
task = "task name">

OR 
<cfschedule 
action = "modify" 
task = "task name"> 


OR 
<cfschedule 
action = "delete" 
task = "task name"> 

OR 

<cfschedule 
action = "run" 
task = "task name"> 

OR 

<cfschedule
action = "pauseAll"
group=groupname
> 

OR

<cfschedule
action = "pauseAll"
> 

OR

<cfschedule
action = "resumeAll"
mode = "server|application"
> 

OR

<cfschedule
action = "resumeAll"
group=groupname
> 

OR

<cfschedule
action = "resumeAll"
> 


OR 

<cfschedule 
action = "list" 
mode = "server|application" 
result = "res">

Example Code from CFDocs

Tell ColdFusion to run 'importData.cfm' daily at 7AM

<cfschedule
 action="update"
 task="importMyCSVFileToDB"
 operation="HTTPRequest"
 startDate="5/12/2016"
 startTime="7:00 AM"
 url="http://www.mydomain.com/scheduled/importData.cfm"
 interval="daily" />

Use cron time format to schedule a task

<cfschedule
 action="update"
 task="myTaskName"
 cronTime="0 */2 3-10,21-23 * * ?" />