Webhook oder Zeitplan: den richtigen Auslöser für Ihren Ablauf wählen

Jeder automatische Ablauf beginnt mit einem Auslöser — dem Ereignis, das ihn startet. Die Wahl des Auslösers entscheidet darüber, wie schnell Ihr Ablauf reagiert, wie zuverlässig er arbeitet und wie aufwendig die Fehlersuche später wird. Diese Anleitung geht die drei praktisch relevanten Varianten durch.

Die drei Arten von Auslösern

• Zeitplan: Der Ablauf startet zu festen Zeiten, etwa jeden Werktag um 7:00 Uhr.
• Webhook: Ein fremdes System ruft eine Adresse Ihres Ablaufs auf, sobald etwas passiert ist. Der Ablauf startet innerhalb von Sekunden.
• Polling: Der Ablauf fragt in einem festen Takt bei einem System nach, ob es etwas Neues gibt — technisch ein Zeitplan mit anschließender Abfrage.

Alle drei führen zum selben Ergebnis. Sie unterscheiden sich in der Verzögerung, in der Last, die sie erzeugen, und in dem, was Sie im Fehlerfall tun müssen.

Wann ein Zeitplan genügt

Ein Zeitplan ist die richtige Wahl, wenn die Aufgabe an eine Uhrzeit gebunden ist und nicht an ein Ereignis. Typische Fälle:

• Der tägliche Bericht, der um 7:00 Uhr im Postfach liegen soll.
• Die wöchentliche Erinnerung an offene Aufgaben.
• Der monatliche Abgleich zweier Datenbestände.

Zeitpläne haben einen praktischen Vorteil: Sie sind vorhersehbar. Wenn ein Lauf fehlschlägt, wissen Sie genau, wann der nächste stattfindet, und können den Fehler dazwischen beheben.

Zwei Punkte sind dabei zu beachten. Erstens die Zeitzone: Prüfen Sie, ob der Zeitplan in UTC oder in Ortszeit gilt — sonst verschiebt sich der Lauf zweimal im Jahr mit der Sommerzeit. Zweitens die Laufzeit: Ein Ablauf, der eine große Liste verarbeitet, sollte fertig sein, bevor der nächste Lauf beginnt.

Wann ein Webhook die bessere Wahl ist

Ein Webhook ist richtig, wenn ein Ereignis den Ablauf starten soll und Verzögerung stört: eine neue Bestellung, ein ausgefülltes Formular, ein aktualisierter Datensatz im CRM.

Der Ablauf erhält dabei eine eigene Adresse. Diese tragen Sie im auslösenden System ein; sobald dort etwas passiert, wird die Adresse mit den Daten des Ereignisses aufgerufen. Ein typischer Aufruf sieht etwa so aus:

{
  "event": "order.created",
  "order": {
    "id": "A-10421",
    "total": 149.9,
    "currency": "EUR",
    "customer": {
      "email": "[email protected]",
      "company": "Beispiel GmbH"
    }
  }
}

Aus diesen Feldern bauen Sie die folgenden Schritte auf — etwa order.customer.email für den Versand einer Bestätigung und order.total für die Verzweigung, ab der eine Freigabe nötig ist.

Drei Regeln haben sich in der Praxis bewährt:

1. Behandeln Sie die Adresse wie ein Geheimnis. Wer sie kennt, kann Ihren Ablauf starten. Geben Sie sie nur im auslösenden System an.
2. Rechnen Sie mit doppelten Aufrufen. Viele Systeme wiederholen einen Aufruf, wenn die erste Antwort ausbleibt. Prüfen Sie deshalb früh im Ablauf, ob der Vorgang schon bearbeitet wurde — die Ereignis- oder Bestell-ID eignet sich dafür.
3. Prüfen Sie die Daten, bevor Sie sie verwenden. Ein Feld kann fehlen oder leer sein. Eine Bedingung direkt nach dem Auslöser erspart Ihnen fehlgeschlagene Läufe weiter hinten.

Polling: der Kompromiss

Manche Systeme bieten keine Webhooks an. Dann bleibt nur die regelmäßige Abfrage: Der Ablauf startet zum Beispiel alle fünfzehn Minuten und fragt, ob seit dem letzten Lauf neue Einträge hinzugekommen sind.

Damit das zuverlässig funktioniert, brauchen Sie ein Merkmal, an dem sich „neu" festmachen lässt — einen Zeitstempel oder eine aufsteigende ID. Filtern Sie auf dieses Merkmal, statt sich auf die Reihenfolge der Ergebnisse zu verlassen.

Bei Zauberflow kostet Sie eine kurze Abfragefrequenz nichts extra, weil nicht pro Ausführung abgerechnet wird. Die einzige Grenze, die zählt, ist die des angefragten Systems: Halten Sie dessen Nutzungsbedingungen und Ratenbegrenzungen ein.

Auslöser testen, bevor der Ablauf live geht

Ein Ablauf sollte nie ungetestet live gehen. Bewährtes Vorgehen:

1. Lösen Sie das Ereignis im Quellsystem einmal echt aus — eine Testbestellung, eine Testformularantwort.
2. Sehen Sie sich die empfangenen Daten an und bauen Sie die folgenden Schritte auf den tatsächlichen Feldnamen auf, nicht auf den erwarteten.
3. Lassen Sie den Ablauf zunächst in einen unkritischen Kanal schreiben, etwa in eine Testtabelle statt ins Buchhaltungssystem.
4. Prüfen Sie das Ausführungsprotokoll: Jeder Lauf ist dort mit Ein- und Ausgabe je Schritt einsehbar.
5. Erst danach schalten Sie auf das Zielsystem um.

Checkliste

• Hängt die Aufgabe an einer Uhrzeit? → Zeitplan
• Hängt sie an einem Ereignis, und das Quellsystem bietet Webhooks? → Webhook
• Hängt sie an einem Ereignis, aber es gibt keine Webhooks? → Polling mit Zeitstempel-Filter
• In allen Fällen: doppelte Verarbeitung ausschließen, Felder vor der Verwendung prüfen, erst in einen Testkanal schreiben.

Wenn Sie das einmal sauber aufgesetzt haben, läuft der Ablauf im Alltag ohne Zutun — und Sie sehen bei jedem Lauf im Protokoll, was passiert ist.