Version vom 2. Juni 2013, 14:23 Uhr

Hinweis: Anleitung wird gerade von mir erstellt! Bitte nichts dran ändern!

Automatisierung von Batch Programmen mittels Zeitsteuerung

• Automatische zeitgesteuerte Ausführung von PHP Skripten.
• Zeitsteuerungs-Syntax von UNIX cron/crontab.
• Benötigt kein “richtiges” cron, kann parasitär bei Seitenaufrufen ausgeführt werden.
• Alternatives Anstossen mittels “echtem” cron möglich.

Vorwort

Die Erweiterung Cron stammt ursprünglich von Peter Koch (acenes) und wurde von mir übernommen mit dem Ziel, diese für Contao 3 kompatibel zu machen. Die Beschreibung hier bezieht sich nur auf die Cron Version ab 3.0.0 für Contao 3.

Forum

Fragen zur Cron Erweiterung werden im Forum beantwortet: Forum - Sonstige-Erweiterungen
Fehler und Wünsche können im Tracking System gemeldet werden.

Installation

Installation erfolgt über das Extension Repository im Backend der Contao Installation.

Eine manuelle Installation ist möglich, dazu die ZIP Datei vom Extension Repository laden, entpacken und entsprechend übertragen.
Danach wie dabei üblich /contao/install.php aufrufen um ein eventuelles Update der Datenbank durchführen.

Hinweis für ältere TYPOlight Versionen

Nutzer von TYPOlight 2.9/2.8/2.7 nutzen bitte Cron Version 1.1.0 (Direktlink)

Installation als Update

Ein Update erfolgt identisch der Installation.

Achtung: Beim Update von Contao 2 auf Contao 3 muss die Erweiterung vollständig deinstalliert/gelöscht werden, da Contao 3 intern die Tabelle tl_cron nutzt, die bisher die Erweiterung Cron nutzte.

Für die Profis: Deinstallation ohne Löschung der Tabelle tl_cron, diese umbenennen nach tl_crontab, dann Update nach Contao 3 und die neue Version von Cron für Contao 3 installieren. So sollten die eingerichteten Cronjobs erhalten bleiben. Job Pfade müssen aber geprüft werden, falls der Demo Job genutzt wurde.

Auslösen des Schedulers

Backend

Standardmäßig wird der Scheduler bei jeder Backend Seitenaktualisierung ausgelöst.

Frontend

Über ein Frontend Modul (ab Cron 3.1.0), welches aber keine Ausgabe erzeugt und somit das Layout nicht stört, ist die Auslösung auch über Seitenaufrufe des Frontends möglich. Bei Jobs die längere Zeit benötigen ist diese Art der Auslösung ungeeignet. In einer der nächsten Versionen wird es dazu eine Verbesserung geben, entweder auf die Art und Weise wie der Contao interne Frontend-Cron funktioniert oder als Job für diesen. Evaluierung erfolgt demnächst dazu.

Luxus Lösung mit realem Cron

Hat man einen Server zur Verfügung in dem Cronjobs eingerichtet werden können, kann man diesen System Cron nutzen um die Cron Erweiterung darüber auszulösen. Der Vorteil ist, dass der Cronjob genau zur geplanten Zeit gestartet wird, auch wenn niemand auf die Website zugreift. Auch bei Seiten mit sehr hohem Traffic, wird diese Art der Auslösung die Webserver Last etwas senken. (im Vergleich zur FE-Modul Auslösung)

Folgende Zeile in die crontab eintragen, vorher anpassen mit der eigenen Domain natürlich.

* * * * * wget -t 1 -O - http://www.example.com/system/modules/cron/public/CronController.php >/dev/null 2>&1

Cronjobs definieren

Über Backend - System - Scheduler sieht man zunächst die Übersicht bereits eingerichteter Cronjobs. Als Beispiel hier ein Job zum löschen der Music Academy Demo Dateien und der mitgelieferte Demo Job zum löschen der Einträge im System-Log.

Der Job zum löschen der System-Log Einträge im Detail:

Benutzerdefinierte Cronjob Scripte

Die Erweiterung bringt ein Beispielskript "PurgeLog.php" mit im Unterverzeichnis "jobs". Hier kann man schon einiges erkennen wie es läuft. Weiter unten folgt ein weiteres kleines Beispiel.

Allgemeine Überlegungen

Generell sollte man versuchen, kleine Jobs wann immer möglich zu schaffen, die nicht lange laufen. Zum Beispiel statt der Schaffung eines großen Jobs, das 3 Dinge tut, ist es besser, 3 kleinere Jobs zu schaffen. Auf diese Weise kann die Last in 3 verschiedenen Seitenaufrufe vom Scheduler verteilt werden.
Die Laufzeit eines Jobs sollte kurz bleiben, weil der Benutzer eine Sanduhr so lange zu sehen bekommt bis dieser fertig ist. Wenn es zu lange dauert wird man denken, es gibt ein Problem mit der Website oder mit dem Computer und bricht die Anfrage ab oder schließt gar den Browser.

Das globale Array $cronJob

Es gibt eine globales Array $cronjob die einem hilft den Job in sinnvolle Stücke aufzuteilen, und einige Informationen und Kontrolle bietet:

$cronJob['id']

ID in der Job Table tl_crontab.
Dieser Parameter kann nur gelesen werden, eine Änderung hat keine Auswirkung.

$cronJob['title']

Titel des Jobs.
Dieser Parameter kann nur gelesen werden, eine Änderung hat keine Auswirkung.

$cronJob['lastrun']

Zeitstempel der letzten Ausführung. Der Wert ist 0 wenn unbekannt bzw. noch nie ein Start erfolgte.
Dieser Parameter kann nur gelesen werden, eine Änderung hat keine Auswirkung.

$cronJob['endtime']

Ab dieser Zeit sollt der Job stoppen, z.B. in dem keine neuen Aktionen mehr ausgeführt werden.
Dieser Parameter kann nur gelesen werden, eine Änderung hat keine Auswirkung.

$cronJob['runonce']

"true": der Job wird nach komplettem Durchlauf deaktiviert.
Das kann im Job selbst geändert werden:

• Setzen auf "true" : der Job wird nach komplettem Durchlauf deaktiviert..
• Setzen auf "false": der Job wird nach komplettem Durchlauf nicht deaktiviert.

Setzt man $cronJob['completed'] auf "false", wird der Job nicht deaktiviert auch wenn $cronJob['runonce'] auf "true" gesetzt ist.

$cronJob['logging']

"true": die Protokollierung des Jobs ist eingeschaltet, für Testzwecke gedacht.
"false": nur Fehler werden protokolliert, so sollte der Job im Normalfall eingestellt sein.
Dieser Wert kann vom Job geändert werden, führt aber eventuell zur Verwirrung der Nutzer:

• Setzen auf "true" : die Protokollierung des Jobs ist eingeschaltet.
• Setzen auf "false": die Protokollierung des Jobs ist abgeschaltet, bis auf Fehlermeldungen.

$cronJob['completed']

Dieser Status ist per Default "true" und bedeutet, wenn der Job fertig ist wird dieser als erledigt markiert und wird neu geplant.
Benötigt der Job zu viel Zeit und man hat die Möglichkeit diesen abzubrechen und beim nächsten Aufruf an der Stelle weiter zu machen, setzt man diesen Status auf "false" und beendet den Job. Dadurch wird der alte Zeitplan beibehalten und beim nächsten Scheduler Aufruf der Job wieder gestartet, um die Arbeit abzuschließen.

Beispiel Script

Script liegt hier unter system/modules/cron/jobs/PurgeLog.php

<?php 
 
/**
 * Initialize the system
 */
define('TL_MODE', 'BE');
require_once('../../../initialize.php');
 
/**
 * Class PurgeLog
 * 
 * @copyright  Glen Langer 2012..2013 <http://www.contao.glen-langer.de>
 * @author     Glen Langer (BugBuster)
 * @package    Cron
 */
class PurgeLog extends Backend
{
 
    /**
     * Initialize the controller
     */
    public function __construct()
    {
    	parent::__construct();
    } // __construct
 
    /**
     * Implement the commands to run by this batch program
     */
    public function run()
    {
        global  $cronJob; // from CronController
 
        //At this time the job should be defered,
        //no new actions should be started after this time.
        if (time() >= $cronJob['endtime'])
        {
            $cronJob['completed'] = false;
            return;
        }
 
        $this->Database->prepare("DELETE FROM `tl_log`")->executeUncached();
        if ($cronJob['logging'])
        {
            $this->log('System log purged by cron job.', 'PurgeLog run()', TL_GENERAL);
        }
    } // run
 
} // class PurgeLog
 
/**
 * Instantiate log purger
 */
$objPurge = new PurgeLog();
$objPurge->run();

--BugBuster 16:01, 30. Mär. 2013 (CET)