Scheduled tasks

By far the easiest to grasp and play with; we normally schedule things like backups, or report generations.

We can also use the task scheduler (under Unix at least) to repetitively launch a Bot as well, and let the Bot decide if there's a job to do or not. If not, just exit back with a success exit code.

As you can see, these are by far the simplest of bots, and I strongly suggest you always attempt to resolve your automation scheduling through a task scheduler like cron. Beyond that, we're entering specialisation world.

The most basic form of task scheduling under any OS and the king of scheduling tasks; cron for Unix variants and Task Scheduler for Windows which both allows you to schedule tasks in time on specific workstations and servers.

Under Unix one has the ability to schedule a task in time with a very flexible granularity. From minutes to years, down to specific days of the week. The system also includes a number of important variables that can be set in the crontab entries as you edit them. Some of the important ones are; MAILTO which sets an email address to receive the output of scripts (make sure your Bot doesn’t output anything when successful, no news is good news.), the PATH variable, which allows your Bot to execute scripts and applications within it, the PATH differs from your normal user, by default PATHs under crontab entries don’t include /usr/local/ paths.

Under Windows things are presented relatively the same way. In a calendar format, with the ability to program tasks at specific times, dates, day of week and so on. On Windows some additional options are present to re-launch tasks, emit warnings and such, but this depends on which version of the APIs are installed, and are seldom-used.

Overall, task scheduling is normally quite convenient to automate tasks every X minutes. The Bot executing the task should simply poll and lookup for incoming jobs to execute, and if none are present, exit successfully to return to sleep until the next call. In my experience, this is the best method to avoid programmer headaches with code cleanliness and the dreaded resource crashes, as it allows each task to start afresh on each iteration and allows for better coordination of resources.

The only issue with Cron/Scheduled tasks is a lack of dependency logic, each job is its own master, and if you must depend on a scheduled framework, then each task must be “complete” on its own. Tasks are more difficult to split up, and as for the monitoring, well, you’re at the mercy of the audit trail generated through your scripts and the emails sent by the scheduling services. This works great for parsimonious tasks, ran once a day (backups, file synchronisations, temp file cleanup, little things like that.)

There are better ways to manage Jobs at the enterprise level. Although the task scheduler remains an important part of our proposed framework, we’ll use it like it should be used, to regulate Message polling events inside our own framework. It remains a very efficient OS-level tool to automate our own engine, as usually the scheduler doesn’t expand additional resources while doing nothing. Any other looping methodologies would involve a costlier sleep operation from a userland program, which should be avoided at all costs if only for security reasons.

So, think of Cron as the metronome in our framework. We’ll look at how we can tune our metronome later on, to make things more efficient.