JTL-Workflow wird nicht ausgelöst: systematisch die Ursache finden

Ein Workflow ist eingerichtet, die Bedingungen sehen richtig aus – und trotzdem passiert nichts. Keine E-Mail, kein gesetzter Wert, kein Druck. Das Frustrierende daran: Die JTL-Wawi meldet in der Regel keinen Fehler, wenn ein Workflow gar nicht erst startet.

Die gute Nachricht: Die Ursachen lassen sich fast immer auf eine Handvoll Punkte eingrenzen. Wer sie in einer festen Reihenfolge prüft, findet den Fehler meist schneller als durch Ausprobieren an der Konfiguration.

Grundlagen: Ereignis, Bedingung, Aktion

Jeder JTL-Workflow folgt demselben Aufbau: Ein Ereignis löst ihn aus (zum Beispiel Artikel > Erstellt), optionale Bedingungen schränken ein, wann er greift, und eine oder mehrere Aktionen werden ausgeführt. Sie finden die Verwaltung unter Admin > JTL-Workflows.

Daraus folgt die wichtigste Frage bei der Fehlersuche: Ist der Workflow nicht gestartet, oder ist er gestartet und an einer Bedingung oder Aktion gescheitert? Die Checkliste unten geht genau in dieser Richtung vor – vom Groben zum Feinen.

Die Checkliste in Reihenfolge

1. Sind Workflows überhaupt aktiv?

Prüfen Sie zuerst zwei Schalter:

• Global: Unter Admin > Globale Einstellungen, Reiter Debugger/Protokolle, gibt es die Option Alle Workflows deaktivieren. Ist sie gesetzt, läuft in der gesamten Wawi kein Workflow.
• Einzeln: Jeder Workflow hat die Checkbox Workflow deaktivieren. Sie schaltet ihn ab, ohne ihn zu löschen – und wird nach Tests gern vergessen.

Arbeiten Sie mit mehreren Mandanten, prüfen Sie außerdem, ob Sie im richtigen Mandanten sind. Workflows sind dem jeweiligen Mandanten zugeordnet.

2. Passt das Ereignis zum Objekt und zum Zeitpunkt?

Der häufigste Fehler überhaupt: Das Ereignis feuert, aber zu einem Zeitpunkt, an dem die Bedingung noch nicht erfüllt ist. Klassisches Beispiel: Ein Workflow auf Auftrag > Erstellt mit der Bedingung „bezahlt“. Kommt die Zahlung erst nach dem Anlegen, ist die Bedingung beim Ereignis nicht erfüllt – und der Workflow wird später nicht erneut geprüft. Für solche Fälle braucht es das Ereignis, das zum Zahlungseingang passt.

Prüfen Sie außerdem:

• Richtiges Objekt: Ein Workflow im Ereignisbereich Rechnung reagiert nicht auf Änderungen am Auftrag, auch wenn es inhaltlich um dieselbe Bestellung geht.
• Geltungsbereich: Über dieses Menü legen Sie fest, welche JTL-Anwendungen den Workflow auslösen. Kommt die Änderung aus einer Anwendung, die dort nicht ausgewählt ist, startet er nicht.
• Edition: Je nach gebuchter JTL-Edition kann die Anzahl der Ereignisse und manuellen Ereignisse begrenzt sein.

Änderungen, die direkt per SQL in der Datenbank vorgenommen werden, laufen an der Wawi-Logik vorbei. Verlassen Sie sich nicht darauf, dass sie Workflow-Ereignisse auslösen.

3. Trifft die Bedingung wirklich zu?

Bedingungen lassen sich so verknüpfen, dass alle, nur eine oder keine erfüllt sein müssen. Eine falsch gesetzte Verknüpfung genügt, damit ein Workflow nie greift. Prüfen Sie außerdem Operator und Vergleichswert genau – inklusive Leerzeichen und Groß-/Kleinschreibung.

Besonders tückisch sind Bedingungen über Erweiterte Eigenschaften verwalten, die mit DotLiquid arbeiten. Hier vergleicht die Wawi das Ergebnis des Liquid-Ausdrucks – und das ist oft nicht das, was man erwartet: ein kleingeschriebener Filter, der stillschweigend ignoriert wird, eine Leerzeile vor dem Wert, ein Variablenpfad, der leer bleibt. Die typischen Fallen haben wir im Artikel Liquid in JTL-Wawi: die häufigsten Stolperfallen gesammelt.

Lassen Sie sich das Liquid-Ergebnis zum Test als Text ausgeben, zum Beispiel per Aktion in die Historie oder ein freies Feld eines Testobjekts. Erst wenn Sie den tatsächlichen Wert sehen, wissen Sie, womit die Bedingung vergleicht.

4. Hat ein vorheriger Workflow abgebrochen?

Hängen mehrere Workflows am selben Ereignis, werden sie gemeinsam abgearbeitet. Ist bei einer Aktion Bei Fehler Workflow abbrechen aktiv, werden laut JTL-Guide im Fehlerfall auch nachfolgende Workflows nicht mehr ausgeführt. Der Fehler sitzt dann nicht in Ihrem Workflow, sondern in einem davor. Prüfen Sie daher die übrigen Workflows desselben Ereignisses und deren Reihenfolge.

5. Läuft der Workflow nur einmal pro Objekt?

Bei zeitversetzten Workflows gibt es die Option Nur letzten ausführen. Ist sie aktiv, führt die Wawi mehrere gleiche zeitversetzte Workflows für dasselbe Objekt nur einmal aus. Wer einen Workflow zum Testen mehrfach am selben Objekt auslöst, sieht deshalb unter Umständen nur einen Durchlauf.

6. Zeitgesteuert? Dann muss der Worker laufen

Standardmäßig steht der Ausführungsplan auf Sofort. Haben Sie einen Zeitpunkt oder eine Verzögerung eingestellt, übernimmt der JTL-Wawi Worker (Hintergrunddienst) die Ausführung. Läuft er nicht, bleiben genau diese Workflows liegen – sofort ausgeführte Workflows funktionieren weiter. Das ist ein sehr typisches Bild.

Der Worker wird über die Verknüpfung im Windows-Startmenü oder auf dem Server gestartet; laut JTL-Guide lässt er sich auch als Windows-Dienst einrichten, der beim Systemstart mitläuft. Prüfen Sie, ob er tatsächlich auf dem vorgesehenen Rechner läuft und mit dem richtigen Mandanten verbunden ist.

Ob Workflows auf den Worker warten, zeigt eine lesende Abfrage auf die Warteschlange. Viele Einträge mit einem Startdatum weit in der Vergangenheit sprechen dafür, dass der Worker nicht arbeitet:

SELECT COUNT(*)          AS Anzahl,
       MIN(dStartDate)   AS AeltesterStart
  FROM dbo.tWorkflowQueue;

Workflows per INSERT in diese oder andere Tabellen anzustoßen, ist kein Weg für die Fehlersuche. Ein falscher Eintrag kann Aktionen an den falschen Objekten auslösen. Das sollten nur Fachleute mit genauer Kenntnis der Datenbank tun.

7. Benutzer- und Mandantenkontext

Manche Aktionen hängen von Einstellungen ab, die nicht im Workflow selbst stehen. Die Aktion E-Mail senden etwa benötigt die Einstellungen unter Admin > Firmen- / E-Mail-Einstellungen. Läuft ein Workflow über den Worker, arbeitet er auf dem Rechner und im Kontext, in dem der Worker gestartet wurde – Netzwerkpfade für Ausgaben oder Programme der Aktion Ausführen müssen von dort erreichbar sein.

Das Protokoll lesen

Fehler und Prozessverläufe sehen Sie laut JTL-Guide unter Admin > Hintergrundprozesse. Für eine gezielte Auswertung, etwa „Was ist mit Auftrag X passiert?“, hilft das Workflow-Protokoll in der Datenbank. Die folgende Abfrage nutzen wir bereits im Artikel zu eigenen Workflow-Aktionen; hier ergänzt um einen Filter auf ein Objekt:

DECLARE @kObjektPk int = 12345;   -- interne ID des Objekts, z. B. kAuftrag

SELECT TOP 50 l.dDatum, w.cName AS Workflow, l.nTyp, l.kObjektPk, l.cLog
  FROM dbo.tWorkflowLog l
  LEFT JOIN dbo.tWorkflow w ON w.kWorkflow = l.kWorkflow
 WHERE l.kObjektPk = @kObjektPk
 ORDER BY l.dDatum DESC;

Die Auswertung ist eindeutig: Kein Eintrag heißt, der Workflow ist für dieses Objekt nicht gestartet – zurück zu den Punkten 1, 2 und 6. Ein Eintrag mit Fehlertext heißt, er ist gestartet und an einer Aktion gescheitert. Beachten Sie, dass die Wawi Workflow-Protokolle standardmäßig nach einer bestimmten Frist automatisch löscht; sehr alte Vorgänge finden Sie deshalb unter Umständen nicht mehr.

Testmethode: gezielt an einem Testobjekt auslösen

Statt auf das nächste echte Ereignis zu warten, testen Sie direkt in der Workflow-Verwaltung: Über Workflow testen wählen Sie ein Testobjekt und starten mit Workflow simulieren einen Testlauf. Mit Workflow ausführen können Sie den Workflow anschließend tatsächlich für dieses Objekt starten.

Für wiederkehrende Tests eignen sich zusätzlich manuelle Workflow-Ereignisse. Sie legen sie in einer Ereignisgruppe mit dem Zusatz „Manuell“ an, etwa Artikel – Manuell, markieren dann im jeweiligen Bereich ein oder mehrere Objekte und lösen das Ereignis über das Auswahlmenü aus. Für Warenlagereingang, Warenlagerausgang und Eingangsrechnungen gibt es laut JTL-Guide keine manuellen Ereignisse.

Workflow ausführen und manuelle Ereignisse lösen die echten Aktionen aus. Verwenden Sie ein Testobjekt, bei dem eine versendete E-Mail oder ein geänderter Wert keinen Schaden anrichtet.

Fehlerbild auf einen Blick

Wenn Sie nicht weiterkommen

Notieren Sie Workflow-Name, Ereignis, ein konkretes betroffenes Objekt, den Zeitpunkt und den Protokolleintrag (oder dessen Fehlen). Mit diesen Angaben ist die Ursache meist schnell eingegrenzt. Wenn Sie dabei Unterstützung wünschen, hilft Ihnen PC-Mixx als zertifizierter JTL-Servicepartner bei der Analyse.

Häufige Fragen

Quellen

JTL-Guide

• JTL-Workflows – Übersicht
• Einleitung zur Workflow-Verwaltung – Ereignisse, Geltungsbereich, Bedingungen, Aktionen, Ausführungsplan, Worker, Nur letzten ausführen, Bei Fehler Workflow abbrechen, Hintergrundprozesse, Workflow testen
• Manuelle Workflow-Ereignisse
• Globale Debug-Einstellungen anpassen – Alle Workflows deaktivieren, Löschfristen der Protokolle
• Workflow: Einkaufsliste bestücken – Start des Workflows per Uhrzeit, Worker als Voraussetzung
• Abgleiche mit JTL-Worker 2.0 automatisieren – Worker als Windows-Dienst

PC-Mixx Wissen

• Liquid in JTL-Wawi: die häufigsten Stolperfallen
• Eigene Workflow-Aktionen in JTL-Wawi: Custom Workflows per SQL