Die Automation läuft, aber die Bestätigungs-E-Mail kommt erst Minuten später an. Wer „jede Minute prüfen" eingestellt hat, hält das für Echtzeit – ist es aber nicht.
Der Zeitplan-Trigger (der startet einen Workflow, also eine automatisierte Ablaufkette, nach einem festen Zeitplan) läuft im Minutentakt, trotzdem landen neue Ereignisse verspätet im Workflow. Gleichzeitig sammeln sich viele Läufe ohne neues Ergebnis im Ausführungsprotokoll.
Der Grundbegriff dahinter ist der Unterschied zwischen Polling und Webhook. Beim Polling fragt ein System eine Quelle in festen Abständen ab, ob es Neues gibt – meist mit einer GET-Anfrage, also einer reinen Leseanfrage an die API (die Schnittstelle eines fremden Systems). Ein Webhook meldet sich selbst: Das fremde System schickt eine POST-Anfrage mit den Ereignisdaten an eine vorher hinterlegte URL. Polling ist so aktuell wie der Abstand zwischen zwei Abfragen; ein Webhook trifft im Moment des Ereignisses ein.
Ein Bestellsystem soll bei jeder neuen Bestellung automatisch eine Rechnung anlegen. Bietet es einen Webhook für neue Bestellungen, meldet es sich selbst. Bietet es nur eine API, fragt ein Zeitplan-Trigger etwa alle fünf Minuten nach – die Bestellung landet je nach Takt erst Minuten später im Workflow. Ein enger Takt erzeugt zudem unnötige Anfragen und kann ein Rate-Limit auslösen, also die erlaubte Höchstzahl an Anfragen; dann antwortet die API mit dem Statuscode 429.
So prüft man es: Zuerst in der Dokumentation des Systems nach „Webhooks" suchen und prüfen, welche Ereignisse es meldet. Fehlt ein Webhook, bleibt Polling – dann den größten Takt wählen, den die Verzögerung noch erlaubt.
Polling heißt nicht schlechter, sondern Nachschlagen auf Abruf. Wer Ereignisse ohne Verzögerung braucht, verlangt eine Meldung statt einer Frage.
📌 Polling · Webhook · Rate-Limit
📚 Automatisierung von Grund auf · Tag 3 von 30
#Automatisierung #Webhooks #workflow
Der Zeitplan-Trigger (der startet einen Workflow, also eine automatisierte Ablaufkette, nach einem festen Zeitplan) läuft im Minutentakt, trotzdem landen neue Ereignisse verspätet im Workflow. Gleichzeitig sammeln sich viele Läufe ohne neues Ergebnis im Ausführungsprotokoll.
Der Grundbegriff dahinter ist der Unterschied zwischen Polling und Webhook. Beim Polling fragt ein System eine Quelle in festen Abständen ab, ob es Neues gibt – meist mit einer GET-Anfrage, also einer reinen Leseanfrage an die API (die Schnittstelle eines fremden Systems). Ein Webhook meldet sich selbst: Das fremde System schickt eine POST-Anfrage mit den Ereignisdaten an eine vorher hinterlegte URL. Polling ist so aktuell wie der Abstand zwischen zwei Abfragen; ein Webhook trifft im Moment des Ereignisses ein.
Ein Bestellsystem soll bei jeder neuen Bestellung automatisch eine Rechnung anlegen. Bietet es einen Webhook für neue Bestellungen, meldet es sich selbst. Bietet es nur eine API, fragt ein Zeitplan-Trigger etwa alle fünf Minuten nach – die Bestellung landet je nach Takt erst Minuten später im Workflow. Ein enger Takt erzeugt zudem unnötige Anfragen und kann ein Rate-Limit auslösen, also die erlaubte Höchstzahl an Anfragen; dann antwortet die API mit dem Statuscode 429.
So prüft man es: Zuerst in der Dokumentation des Systems nach „Webhooks" suchen und prüfen, welche Ereignisse es meldet. Fehlt ein Webhook, bleibt Polling – dann den größten Takt wählen, den die Verzögerung noch erlaubt.
Polling heißt nicht schlechter, sondern Nachschlagen auf Abruf. Wer Ereignisse ohne Verzögerung braucht, verlangt eine Meldung statt einer Frage.
📌 Polling · Webhook · Rate-Limit
📚 Automatisierung von Grund auf · Tag 3 von 30
#Automatisierung #Webhooks #workflow
3 Tage vor
