Türchen 15: Cronjobs im Magento

Bei einem Großteil der Magento-Installationen sind die Cronjobs nicht richtig eingerichtet, wie auch beim Magento Developers Paradise 2012 beklagt wurde. Grund genug für mich, im heurigen Türchen eine Einführung zu geben und so dem einen oder anderen Cronjob zur Geburt zu verhelfen.

Cronjobs in Magento

Magento bringt bereits eine Reihe fertiger Jobs mit. Man muss sie nur noch einrichten, damit sie auch ausgeführt werden.

Für diesen Zweck findet man im Root-Verzeichnis der Magento-Installation das Skript cron.sh. Es ruft cron.php auf, das eine Rumpf-Version der Magento-Applikation startet und die dort definierten Cronjobs ausführt.

Magento verfügt nämlich über eine eigene Cronjob-Verwaltung. Dadurch ist es möglich, die Jobs in PHP zu programmieren und ihren Ablaufplan über die Konfiguration zu steuern.

Ein Hinweis vorab: dieses Türchen bezieht sich auf Linux-Systeme, da die allermeisten Shop-Installationen darauf laufen.

Einrichtung von cron.sh

Im ersten Schritt wird cron.sh für jenen Linux-User ausführbar gemacht, der die Cronjobs aufruft. Je nach Server-Setup müssen die Rechte für den Besitzer, die Gruppe oder für alle freigegeben werden. Generell gilt: je restriktiver die Rechte gesetzt werden können, desto besser.

Im zweiten Schritt trägt man den Job in crontab ein, also die Datei, welche die Aufgaben für cron auflistet. Das geht üblicherweise so:

crontab -e

Mit dem Befehl wird crontab geöffnet. Nun kann man den neuen Job eintragen:

/5 * /var/www/pfad/zu/magento/cron.sh

Diese Zeile bewirkt, dass Magentos Cron-Script alle 5 Minuten aufgerufen wird. Die genaue Syntax könnt ihr dem obigen Wikipedia-Link entnehmen. Achtet darauf, dass ihr crontab mit einer leeren Zeile abschließt, sonst wird der letzte Job in der Regel nicht ausgeführt.

Zudem ist wichtig, dass der User, der die Cronjobs ausführt, die benötigten Rechte hat!

Die Cronjobs sollten jetzt fertig eingerichtet sein. Habt ihr etwas falsch gemacht, dann erhält euer Linux-User Meldungen per Mail und ihr könnt euch auf die Fehlersuche machen.

Überprüfung und Konfiguration

Was tut Magento im Hintergrund? Es erstellt in regelmäßigen Abständen Jobs, die beim Aufruf durch cron ausgeführt werden. Die Konfiguration ist im Magento-Backend unter "System > Configuration > Advanced > System > Cron (Scheduled Tasks) - all the times are in minutes" zu finden:

Diese Einstellungen möchte man wahrscheinlich anpassen. Es ist ärgerlich, wenn fehlgeschlagene Cronjobs nur 10 Stunden archiviert werden und man Montag Morgen im Büro nicht feststellen kann, was denn am Wochenende genau schief gelaufen ist. (Sofern ihr kein automatisiertes Monitoring für Cronjobs verwendet.)

Um zu überprüfen, wie es den Cronjobs ergangen ist, kann man einen Blick in die Datenbank-Tabelle cron_schedule werfen:

Hier werden alle generierten Jobs und ihr Status aufgelistet. Diese Ansicht ist leider nicht komfortabel. Die Cronjobs gehen in Magento dadurch unter.

Cronjob-Verwaltung 2.0

Wenn ich einen neuen Shop aufsetze, ist einer meiner ersten Schritte daher die Installation der Extension Aoe_Scheduler von Fabrizio Branca. Sie kann über modman, Composer oder Magento Connect eingerichtet werden. Ich empfehle modman oder Composer, da auf Magento Connect nicht die aktuelle Version zu finden ist.

Aoe_Scheduler fügt im Backend-Menüpunkt "System > Scheduler" drei neue praktische Ansichten hinzu:

1. Überblick über die Cronjobs und ihre Konfiguration
2. Die Liste der nächsten Jobs als Tabelle
3. Eine graphische Darstellung der gelaufenen und geplanten Jobs

Anbei ein paar Screenshots, mit denen man einen guten Eindruck gewinnt.

Die Extension birgt folgende Vorteile:

• Aktivieren/Deaktivieren der Cronjobs ohne Eingriffe in Config-XML-Dateien
• Übersicht über die Konfiguration und den Status der diversen Jobs
• Kommandozeilen-Script und Web-Service-API-Befehle zum Erzeugen und Ausführen von Jobs
• Ein "heartbeat"-Cronjob, der für die Überwachung der Cronjob-Funktionalität in Monitoring-Systemen verwendet werden kann

Besonders die Timeline-View erweist sich als hilfreich, da fehlgeschlagene Cronjobs farblich hervorgehoben werden und die Laufzeit der Jobs auf einen Blick ersichtlich ist. Beim Hovern über die Jobs erhält man weitere Details.

Magento-Standard-Cronjobs

Nun ist es an der Zeit, die von Magento mitgelieferten Jobs durchzugehen, nicht benötigte zu deaktivieren und die Ablaufpläne (falls nötig) anzupassen. Sehen wir uns an, welche Jobs die Magento Community Edition 1.7 bietet.

Backup

Code	Cron Expression	Model
system_backup		backup/observer::scheduledBackup

Auf Wunsch führt Magento mit dem Job "system_backup" Sicherungen der Datenbank, Media- und/oder Code-Dateien durch. Damit das Backup erstellt wird, muss es über den Menüpunkt "System > Configuration > Advanced > System > Scheduled Backup Settings" konfiguriert werden.

Wer sich über das seit 1.7 erhältliche Backup-/Rollback-Feature informieren möchte, findet dazu einen Beitrag in meinem Blog. Falls ihr die Daten auf anderen Wegen sichert, könnt ihr den Job ruhig über Fabrizios Extension deaktivieren. Auf irgendeine Weise muss aber gesichert werden.

Cache

Code	Cron Expression	Model
core_clean_cache	30 2 * * *	core/observer::cleanCache

Der Job "core_clean_cache" leert veraltete Cache-Einträge. Es wird also nicht alles gelöscht. Und kaum, dass ich das geschrieben habe, muss ich es relativieren. Welche Einträge betroffen sind, hängt nämlich von den eingesetzten Cache-Backends und einigen Settings ab. Gute Informationen zur Cache-Problematik liefert Fabrizio.

CAPTCHAs

Code	Cron Expression	Model
captcha_delete_expired_images	*/10 * * * *	captcha/observer::deleteExpiredImages
captcha_delete_old_attempts	*/30 * * * *	captcha/observer::deleteOldAttempts

CAPTCHAs sind verschnörkelte Buchstaben- und Zahlenfolgen, auf die man bei Web-Formularen immer wieder stößt. Sie sollen Shopbetreiber vor Unmengen an Spam-Mails schützen. Die Option, CAPTCHAs in diversen Backend- und Frontend-Formularen einzubinden, wurde ebenfalls mit Magento 1.7 in Magento integriert (siehe CAPTCHAs in Magento 1.7). Leicht zu erkennen ist die Aufgabe der Jobs: einerseits werden nicht mehr benötigte CAPTCHA-Bild-Dateien gelöscht, andererseits alte Einträge in der Log-Datenbank zu (fehlgeschlagenen) CAPTCHA-Lösungsversuchen. Wer CAPTCHAs nicht im Einsatz hat, kann diese Cronjobs deaktivieren.

Google Sitemap

Code	Cron Expression	Model
sitemap_generate		sitemap/observer::scheduledGenerateSitemaps

Genau genommen handelt es sich bei den Sitemap-XML-Dateien, die "sitemap_generate" erstellt, ja gar nicht um eine reine Google-Sitemap-Datei. Yahoo und co. verwenden diesen Standard ebenso. Aufgrund der Marktmacht von Google hat sich aber auch Magento zur Bezeichnung "Google Sitemap" hinreißen lassen. Sei's drum: es geht um die Erzeugung der Sitemap-Datei, die üblicherweise sitemap.xml heißt und im root-Verzeichnis der Magento-Installation abgelegt wird. Sie hilft Suchmaschinen, die Seiten des Angebots zu finden und entsprechend der Wünsche des Betreibers zu priorisieren. Damit Sitemap-Dateien automatisch angelegt werden, müssen zwei Schritte erfolgen:

1. Die Sitemaps müssen im Hauptmenüpunkt "Catalog > Google Sitemap" angelegt werden.
2. Der Cronjob muss in "System > Configuration > Catalog > Google Sitemap" aktiviert und konfiguriert werden.

Katalog

Code	Cron Expression	Model
catalog_product_index_price_reindex_all	0 2 * * *	catalog/observer::reindexProductPrices
catalogrule_apply_all	0 1 * * *	catalogrule/observer::dailyCatalogUpdate
catalog_product_alert		productalert/observer::process

Jobs, die den Produktkatalog betreffen, sind auf verschiedene Module verteilt. "catalogrule_apply_all" berechnet Produktpreisänderungen aufgrund der Katalogpreisregeln. Berücksichtigt wird ein 3-Tage-Intervall bestehend aus dem vorangegangenen, dem aktuellen und dem nächsten Tag. "catalog_product_index_price_reindex_all" sorgt dann dafür, dass die Produktpreise auf dem laufenden Stand sind. Die Preise sollten bei einer automatischen Indizierung sowieso stimmen, doch solange keine anderen Parameter dagegen sprechen (Laufzeit des Jobs, Caching), kann eine Neuindizierung nicht schaden. Über "catalog_product_alert" werden Hinweis-Mails versendet, wenn sich Produktpreise ändern oder ein nicht lagerndes Produkt wieder verfügbar ist. Ob diese Funktionen zur Verfügung stehen, wird in "System > Configuration > Catalog > Catalog > Product Alerts" bzw. "System > Configuration > Catalog > Catalog > Product Alerts Run Settings" konfiguriert.

Logs

Code	Cron Expression	Model
log_clean		log/cron::logClean

Magento erzeugt Unmengen an Log-Daten. Wer nicht aufpasst, kann bald in zig Gigabyte (GB) an Datenbankeinträgen untergehen. Das verlängert Backup- und Rollback-Operationen. Nicht zuletzt kann die Performance darunter leiden. Um das zu verhindern, veranlasst man in "System > Configuration > Advanced > System > Log Cleaning" die Bereinigung der Log-Tabellen um alte Datensätze. Wer diese Daten weiterhin benötigt, kann eigene Jobs schreiben, welche die Daten rechtzeitig wegschreiben, bevor "log_clean" sie ins digitale Nirvana schickt.

Magento Mobile

Code	Cron Expression	Model
xmlconnect_notification_send_all	*/5 * * * *	xmlconnect/observer::scheduledSend

Mage_XmlConnect ist eines dieser Module, mit denen die meisten Entwickler nie in Berührung kommen. Im Prinzip dient es dem Betrieb von Magento Mobile Apps. Wer eine solche App eingerichtet hat, sollte daher den Cronjob aktiviert lassen.

Newsletter

Code	Cron Expression	Model
newsletter_send_all	*/5 * * * *	newsletter/observer::scheduledSend

"newsletter_send_all" kommt zum Einsatz, wenn Newsletter über die Magento-eigene Funktion verschickt werden. Der Job wird benötigt, da Magento die Mails verteilt versendet, um u.a. die Gefahr zu senken, dass der Server als Spam-Server eingestuft wird. Achtung: im Magento-Standard ist hard kodiert, dass pro Durchlauf maximal je 20 E-Mails gesendet werden. Große Mail-Listen benötigen daher geraume Zeit, um verschickt zu werden und der Einsatz ist so nur mäßig sinnvoll.

PayPal

Code	Cron Expression	Model
paypal_fetch_settlement_reports		paypal/observer::fetchReports

Wer PayPal direkt über Magento einbindet, kann "paypal_fetch_settlement_reports" einsetzen, um die Settlement Reports automatisiert abzuholen. Das Konfigurationsmenü für die Settlement Reports findet man rekordverdächtig gut versteckt unter "System > Configuration > Sales > Payment Methods > PayPal All-in-One Payment Solutions > PayPal Payments Advanced (Includes Express Checkout) > Required PayPal Settings > Basic Settings - PayPal Payments Advanced > Advanced Settings > Settlement Report Settings". Zuerst trägt man die SFTP-Zugangsdaten ein, dann konfiguriert man unter "Scheduled Fetching" den Job. Alle ohne diese Zahlmethode deaktivieren den Eintrag und freuen sich, dass sie nicht mit Grubenlampe und Spitzhacke 10 Ebenen tief in die Konfiguration eintauchen müssen.

Quotes & Warenkorb

Code	Cron Expression	Model
persistent_clear_expired	0 0 * * *	persistent/observer::clearExpiredCronJob
sales_clean_quotes	0 0 * * *	sales/observer::cleanExpiredQuotes

Wer unter "System > Configuration > Customers > Persistent Shopping Cart" den persistenten Warenkorb aktiviert hat, kann mit "persistent_clear_expired" dafür sorgen, dass abgelaufene Sessions aus der Datenbank entfernt werden. "sales_clean_quotes" kümmert sich darum, dass Quotes gelöscht werden, die zu einer Order geführt haben und älter sind als die in "System > Configuration > Sales > Checkout > Shopping Cart > Quote Lifetime (days)" angegebenen Tage. Richtig gelesen: aktive Quotes, also Warenkörbe, die noch nicht in eine Bestellung umgewandelt wurden, werden von Standard-Magento nie gelöscht. Auch hier können ähnlich wie bei Logs Unmengen von Datenleichen entstehen. Wir kommen gleich noch zu einer Extension, die diesen Umstand bereinigt.

Verkäufe und Reporting

Code	Cron Expression	Model
aggregate_sales_report_bestsellers_data	0 0 * * *	sales/observer::aggregateSalesReportBestsellersData
aggregate_sales_report_invoiced_data	0 0 * * *	sales/observer::aggregateSalesReportInvoicedData
aggregate_sales_report_order_data	0 0 * * *	sales/observer::aggregateSalesReportOrderData
aggregate_sales_report_refunded_data	0 0 * * *	sales/observer::aggregateSalesReportRefundedData
aggregate_sales_report_shipment_data	0 0 * * *	sales/observer::aggregateSalesReportShipmentData
aggregate_sales_report_coupons_data	0 0 * * *	salesrule/observer::aggregateSalesReportCouponsData
aggregate_sales_report_tax_data	0 0 * * *	tax/observer::aggregateSalesReportTaxData

Aufgabe dieser Jobs ist das Aggregieren diverser Daten rund um Verkäufe und die Bestellabwicklung. Wenn Händler die Reports in Magento nicht verwenden, würde ich diese Jobs deaktivieren. Immer häufiger werden die Analysen in externen ERP-Systemen oder Data-Warehouses vollzogen, womit die ohnehin nicht problemlos funktionierende Reporting-Funktion obsolet wird. Falls die Reporting-Funktion eingesetzt wird, kann es abhängig vom Datenvolumen und Besucheraufkommen des Shops sinnvoll sein, die Jobs zeitversetzt laufen zu lassen.

Währungen

Code	Cron Expression	Model
currency_rates_update	0 0 * * *	directory/observer::scheduledUpdateCurrencyRates

Dieser Task zur Aktualisierung der Währungskurse wird unter "System > Configuration > General > Currency Setup > Scheduler Import Settings" aktiviert. Auch hier gilt: wer das Feature nicht verwendet, kann es guten Gewissens über Aoe_Scheduler deaktivieren.

Ablaufpläne der Standard-Jobs verändern

Nachdem wir nun feststellen können, welche Cronjobs für uns relevant sind, geht es an die Ablaufplanung (wer es lieber englisch hat: "scheduling"). Einige Jobs bieten die Möglichkeit, die Ablaufpläne über Einträge in "System > Configuration" zu verändern. Wer Tasks umplanen möchte, welche diese Option nicht bieten oder wer Änderungen direkt über Files warten will, kann das in der Datei config.xml seiner Extension tun:

<?xml version="1.0" encoding="UTF-8"?>
<config>
    <!-- Restliche Konfiguration -->
    <crontab>
        <jobs>
            <catalog_product_index_price_reindex_all>
                <schedule>
                    <cron_expr>30 1 * * *</cron_expr>
                </schedule>
            <catalog_product_index_price_reindex_all>
        </jobs>
    </crontab>
</config>

Einfach den Code des Cronjobs verwenden und eine Schedule festlegen, schon ist die Sache erledigt. Außerdem muss man dafür sorgen, dass die eigene Extension nach dem entsprechenden Magento-Modul geladen wird.

Eigene Cronjobs hinzufügen

Eigene Cronjobs lassen sich denkbar einfach festlegen. Nötig sind nur:

• der Name ("code") für den Cronjob
• eine Schedule (in Form einer Cron-Expression oder eines Hinweises, in welchem "System > Config"-Eintrag man die Cron-Expression findet)
• das Model und die Methode, die aufgerufen werden sollen.

Mit diesem Code werden zwei Jobs mit jeweils einer Art de Schedule-Definition eingerichtet:

<?xml version="1.0" encoding="UTF-8"?>
<config>
    <!-- Restliche Konfiguration -->
    <crontab>
        <jobs>
            <webguys_cronjob_one>
                <schedule>
                    <cron_expr>0 */2 * * *</cron_expr>
                </schedule>
                <run>
                    <model>webguys_example/observer::cronjobOne</model>
                </run>
            </webguys_cronjob_one>
            <webguys_cronjob_two>
                <schedule>
                    <config_path>webguys/example/cronjob_two</config_path>
                </schedule>
                <run>
                    <model>webguys_example/observer::cronjobTwo</model>
                </run>
            </webguys_cronjob_two>
        </jobs>
    </crontab>
</config>

Nützliche Extensions

Zum Abschluss Hinweise auf einige Extensions, die ich regelmäßig bei Magento-Shops für die Datenwartung nutze und bei denen Cronjobs eine wichtige Rolle spielen:

• Aoe_AsyncCache: schreibt Lösch-Befehle für den Cache in eine Queue, anstatt sofort zu löschen (asynchrones Cache-Löschen). Dadurch wird der Cache seltener gelöscht und bestimmte Operationen wie der Backend-Login beschleunigt. Der Cronjob für die tatsächliche Löschung der Cache-Einträge wird standardmäßig alle 15 Minuten ausgeführt.
• Aoe_CacheCleaner: leert verschiedene Teile des Caches (den gesamten Cache, den Magento-Cache, JS/CSS, Katalogbilder). Die Schedule ist für jeden Teil getrennt konfigurierbar.
• Aoe_QuoteCleaner: löscht alte Warenkörbe / Quotes unabhängig davon, ob sie in eine Bestellung überführt wurden. Wie oben erwähnt ist das sinnvoll, um die Datenmenge nicht zu stark ansteigen zu lassen. Wie lange man hofft verwaiste Warenkörbe noch reaktivieren zu können, ist mitunter eine Marketing-Frage. Wenn der Warenkorb trotz aller Bemühungen z.B. sechs Monate unberührt geblieben ist, kann man die Quote aber wohl ohne Bedenken löschen.

Fazit

Dieser Überblick hilft hoffentlich dem/der einen oder anderen, die saubere Basis für ein gesundes Shopsystem zu legen. Falls ihr Tipps für die Nutzung von Cronjobs oder weitere Extensions habt, freue ich mich über eure Kommentare.