Cron-Zeitpläne und Webhooks decken die Grundlagen ab. Dieses Recipe jeden Morgen um 8 Uhr ausführen. Diesen Workflow auslösen, wenn ein Drittsystem einen POST-Request sendet. Das deckt viele Anwendungsfälle ab.
Aber echte Automatisierung muss auf Ereignisse reagieren — ein Workflow, der fertig wird, eine E-Mail, die ankommt, Daten, die sich in einem verbundenen Tool ändern, ein bestimmtes Element, das auf einer Webseite erscheint. Auf einem Timer zu pollen und zu hoffen, dass Sie das Ereignis erwischen, ist verschwenderisch und langsam. Darauf zu warten, dass jemand auf der anderen Seite einen Webhook einrichtet, setzt voraus, dass die andere Seite Webhooks unterstützt.
JieGou unterstützt jetzt vier ereignisgesteuerte Trigger-Typen, die die bestehenden Cron- und Webhook-Optionen ergänzen. Jeder einzelne überwacht eine bestimmte Art von Ereignis und löst Ihr Recipe oder Ihren Workflow aus, wenn es eintritt.
Die vollständige Trigger-Landschaft
JieGou unterstützt sieben Trigger-Typen in zwei Kategorien:
| Trigger | Modell | Rate Limit | Anwendungsfall |
|---|---|---|---|
| Cron-Zeitplan | Timer | N/A | Stündlich, täglich um 9 Uhr usw. ausführen |
| Webhook | Push | 12/Min pro Trigger | Externes System sendet HTTP POST |
| Run abgeschlossen | Push | 6/Min pro Trigger, 30/Min pro Account | Recipes/Workflows verketten |
| Connector geändert | Poll (60s-24h) | Pro Poll-Intervall | Auf CRM-, Tabellen- oder Datenbankänderungen reagieren |
| E-Mail empfangen | Poll (Standard 300s) | 5 Nachrichten pro Zyklus | Eingehende E-Mail löst Triage aus |
| Slack-Nachricht | Push | Pro Slack Events API | Kanalnachricht löst Extraktion aus |
| Browser-Ereignis | Push | 20/Min pro Benutzer | DOM-Änderung löst Untersuchung aus |
Cron- und Webhook-Trigger sind in allen Tarifen verfügbar. Die vier neuen ereignisgesteuerten Trigger sind ab dem Pro-Tarif verfügbar.
Run-Completion-Verkettung
Typ: run_completed | Modell: Push-basiert über In-Process-Event-Bus
Das häufigste Automatisierungsmuster ist “wenn X fertig ist, starte Y.” Ein Zusammenfassungs-Recipe ist abgeschlossen, also sollte ein Verteilungs-Workflow starten. Ein Datenanreicherungs-Workflow ist fertig, also sollte ein Scoring-Recipe gegen die Ergebnisse laufen.
Run-Completion-Verkettung handhabt dies ohne Polling. Es verwendet einen In-Process-Event-Bus — wenn ein Run fertig ist, wird das Ereignis sofort ausgelöst, nicht beim nächsten Poll-Zyklus.
Konfigurationsoptionen:
- Überwachungsziel: Ein bestimmtes Recipe, ein bestimmter Workflow oder “jeder Run in diesem Account”
- Statusfilter: Nur bei Erfolg, nur bei Fehler oder bei beidem auslösen
- Output-Mapping: Drei Modi zum Extrahieren von Daten aus der Payload des abgeschlossenen Runs
Die drei Output-Mapping-Modi geben Ihnen Kontrolle darüber, welche Daten in den ausgelösten Run fließen:
- Passthrough — Die gesamte Event-Payload wird zur Eingabe. Nützlich, wenn das nachgelagerte Recipe den vollständigen Kontext erwartet.
- Field-Mapping — Spezifische Felder mit Punkt-Pfad-Notation extrahieren (z.B.
event.output.summarywird dem Eingabefeldsummaryzugeordnet). - Template —
{{variable}}-Substitution mit verschachtelter Pfadunterstützung für komplexere Transformationen verwenden.
Das Rate Limit beträgt 6 Trigger pro Minute pro Trigger — bewusst die Hälfte der Webhook-Rate von 12/Min. Dies verhindert Kaskadenstürme, bei denen eine Kette von Triggern zu Hunderten gleichzeitiger Runs eskaliert. Die accountweite Obergrenze von 30/Min bietet einen zusätzlichen Schutz.
Beispiel-Pipeline: Ein Content-Erstellungs-Recipe generiert einen Blog-Entwurf. Bei Erfolg wird ein Verteilungs-Workflow ausgelöst, der in Social-Media-Kanälen postet und E-Mail-Versand plant. Nach Abschluss der Verteilung wird ein Reporting-Recipe ausgelöst, das Engagement-Metriken aggregiert. Drei Recipes, voll automatisiert, kein Cron-Zeitplan, der raten muss, wann jede Phase fertig ist.
Connector-Datenänderungserkennung
Typ: connector_changed | Modell: Poll-basiert über Cloud Scheduler
Nicht jedes System sendet Webhooks, wenn sich Daten ändern. CRM-Datensätze werden still aktualisiert. Tabellenzellen ändern sich ohne Benachrichtigung. Datenbankzeilen werden von Hintergrundjobs geändert.
Connector-Änderungserkennung pollt Ihre verbundenen Datenquellen in konfigurierbaren Intervallen (60 Sekunden bis 24 Stunden) und löst aus, wenn sich die Daten tatsächlich ändern.
Wie die Änderungserkennung funktioniert:
- Jeder Poll-Zyklus ruft die aktuellen Daten vom Connector ab
- Das System berechnet einen SHA-256-Hash der Antwort
- Der Hash wird mit dem zuvor gespeicherten Hash verglichen
- Wenn die Hashes abweichen, wird der Trigger ausgelöst
Der erste Poll nach der Einrichtung speichert den Hash, ohne auszulösen. Dies vermeidet Fehlalarme — Sie möchten nicht, dass jeder Trigger im Moment der Konfiguration auslöst, nur weil “die Daten anders als nichts sind.”
Änderungstyp-Filter:
- Jede Änderung — Jeder Unterschied in den gehashten Daten
- Neue Datensätze — Löst nur aus, wenn die Datensatzanzahl steigt
- Spezifische Feldänderungen — Bestimmte Felder überwachen und Änderungen an anderen ignorieren
Field-Mapping mit Transformationen: Wenn der Trigger auslöst, können Sie Connector-Felder auf Recipe-Eingaben mit integrierten Transformationen abbilden — string, number, boolean, json_parse und date_iso. Ein CRM-Feld “Deal-Wert”, das als String gespeichert ist, kann automatisch als Zahl geparst werden, bevor es Ihr Scoring-Recipe erreicht.
Beispiel: Ein CRM-Connector überwacht das “Leads”-Objekt. Wenn ein neuer Lead erscheint oder der Status eines bestehenden Leads auf “Qualifiziert” wechselt, löst der Trigger einen Lead-Scoring-Workflow aus, der den Lead aus drei Datenquellen anreichert und einen Prioritäts-Score zuweist.
E-Mail empfangen
Typ: email_received | Modell: Poll-basiert über Gmail OAuth
E-Mail bleibt der Einstiegspunkt für eine überraschende Anzahl von Geschäftsprozessen. Support-Anfragen, Lieferantenrechnungen, Warnmeldungen, Genehmigungsantworten — sie alle kommen in einem Posteingang an.
Der E-Mail-Trigger integriert sich über OAuth-MCP-Tools mit Gmail und pollt nach neuen Nachrichten, die Ihren Kriterien entsprechen.
Konfiguration:
- Gmail-Abfragesyntax zum Filtern — z.B.
from:alerts@example.com subject:urgentoderlabel:support-inbox is:unread - Poll-Intervall: Standard 300 Sekunden, konfigurierbar
- Max. Nachrichten pro Zyklus: Bis zu 5 (konfigurierbar) — verhindert, dass ein Rückstau von 200 E-Mails 200 gleichzeitige Runs erzeugt
- Wasserzeichen-Tracking über
lastProcessedEmailId— das System merkt sich die letzte verarbeitete E-Mail, sodass es dieselbe Nachricht nie erneut verarbeitet, selbst wenn sie noch der Abfrage entspricht
E-Mail-zu-Eingabe-Mapping extrahiert strukturierte Daten aus jeder E-Mail:
| E-Mail-Feld | Wird zugeordnet zu |
|---|---|
subject | Text-Eingabefeld |
sender | Text-Eingabefeld |
body | Text- oder Langtext-Eingabefeld |
date | Datums-Eingabefeld |
headers | JSON-Eingabefeld |
Beispiel: Support-E-Mails, die label:support-inbox is:unread entsprechen, lösen einen Triage-Workflow aus. Der Workflow klassifiziert das Problem nach Kategorie und Dringlichkeit, entwirft eine Antwort unter Verwendung relevanter KB-Artikel und leitet hochprioritäre Probleme über Slack an das Bereitschaftsteam weiter.
Slack-Nachricht
Typ: slack_message | Modell: Push-basiert über Slack Events API
Manche Teams führen ihren gesamten Betrieb über Slack. Statusaktualisierungen, Kundeneskalationen, Deployment-Benachrichtigungen, Entscheidungsanfragen — alles passiert in Kanälen.
Der Slack-Nachricht-Trigger nutzt die Slack Events API, um Nachrichten in Echtzeit zu empfangen. Kein Polling, keine Verzögerung.
Filterung:
- Channel-ID — Erforderlich. Der Trigger überwacht einen bestimmten Kanal.
- Schlüsselwort- oder Regex-Muster — Optional. Nur Nachrichten, die dem Muster entsprechen, lösen den Trigger aus.
- Automatische Rauschfilterung — Der Trigger ignoriert Bot-Nachrichten, Nachrichtenbearbeitungen und Systemnachrichten. Er filtert nach
event.type === 'message'ohnesubtype, sodass Sie nur echte, von Menschen verfasste Nachrichten erhalten.
Slack-zu-Eingabe-Mapping:
| Slack-Feld | Wird zugeordnet zu |
|---|---|
text | Nachrichteninhalt |
user | Slack-Benutzer-ID |
channel | Channel-ID |
timestamp | Nachrichten-Zeitstempel |
Beispiel: Ein #action-items-Kanal empfängt den ganzen Tag über Nachrichten. Jede Nachricht löst ein Extraktions-Recipe aus, das Aktionspunkte identifiziert, Verantwortliche basierend auf @-Erwähnungen zuweist, Fälligkeitsdaten aus natürlicher Sprache setzt (“bis Freitag”) und eine strukturierte Zusammenfassung zurück in einen #action-tracker-Kanal postet.
Browser-Ereignisüberwachung
Typ: browser_event | Modell: Push-basiert über Browser-Extension
Dieser unterscheidet sich von den anderen. Statt einen Service oder Posteingang zu überwachen, beobachtet er, was im Browser selbst passiert — das DOM einer Webseite.
Die Browser-Extension überwacht Seiten auf bestimmte Bedingungen und löst einen Trigger aus, wenn sie eintreten. Fünf DOM-Bedingungstypen werden unterstützt:
| Bedingung | Was überwacht wird |
|---|---|
element_appears | Ein CSS-Selektor trifft auf ein Element, das vorher nicht da war |
element_disappears | Ein zuvor getroffenes Element wird entfernt |
text_changes | Der Textinhalt eines getroffenen Elements ändert sich |
attribute_changes | Ein Attribut (class, data-* usw.) eines getroffenen Elements ändert sich |
url_changes | Die Seiten-URL ändert sich (unterstützt Wildcard-Muster) |
URL-Musterabgleich mit Wildcard-Unterstützung stellt sicher, dass der Trigger nur auf relevanten Seiten auslöst — https://monitoring.example.com/dashboard/* löst nicht auf irrelevanten Tabs aus.
CSS-Selektor-Targeting mit Datenextraktion: Die extractSelectors-Konfiguration ordnet Eingabefelder CSS-Selektoren zu. Wenn der Trigger auslöst, liest die Extension die aktuellen Text- oder Attributwerte von diesen Selektoren und übergibt sie als strukturierte Eingabe.
Debounce: DOM-Änderungen können verrauscht sein — eine einzelne Benutzeraktion könnte Dutzende Mutationen verursachen. Der konfigurierbare Debounce (Minimum 1.000ms, Standard 5.000ms) fasst schnelle Änderungen zu einem einzelnen Trigger-Ereignis zusammen. Das Rate Limit von 20 Browser-Ereignissen pro Minute pro Benutzer bietet einen zusätzlichen Schutz.
Beispiel: Ein Monitoring-Dashboard zeigt ein rotes Warnbanner, wenn ein Service beeinträchtigt ist. Der Trigger überwacht element_appears auf .alert-banner.critical. Wenn er auslöst, extrahiert er den Warntext und den betroffenen Servicenamen über extractSelectors und löst dann einen Untersuchungs-Workflow aus, der Logs abfragt, aktuelle Deployments prüft und eine Incident-Zusammenfassung entwirft.
Architektur: Steckbare Event-Source-Handler
Alle sieben Trigger-Typen teilen denselben Ausführungspfad. Die Architektur verwendet ein steckbares Event-Source-Handler-Muster:
- Jeder Quelltyp implementiert das
EventSourceHandler-Interface - Eine Registry ordnet Quelltyp-Strings (
run_completed,connector_changedusw.) Handler-Instanzen zu - Push-basierte Trigger (Run-Completion, Slack, Browser) liefern Ereignisse direkt; poll-basierte Trigger (Connector, E-Mail) laufen auf Cloud-Scheduler-Intervallen
- Beide Pfade konvergieren in
trigger-base.ts— dieselbe Ausführungslogik, die Webhook-Trigger verarbeitet, verarbeitet Event-Trigger
Dieser gemeinsame Pfad bedeutet, dass Event-Trigger dieselbe Deduplizierung, Eingabeauflösung und Ausführungshistorie wie Webhooks erhalten. Deduplizierungsschlüssel verhindern, dass dasselbe Ereignis einen Trigger zweimal auslöst — kritisch für push-basierte Quellen, bei denen Netzwerk-Retries doppelte Ereignisse liefern könnten.
Observability ist über drei Prometheus-Metriken integriert:
event_triggers_total— Zähler nach Quelltyp und Statusevent_trigger_duration_seconds— Histogramm der Trigger-zu-Ausführung-Latenzevent_polling_total— Zähler für poll-basierte Trigger, der Zyklen mit und ohne Änderungen verfolgt
Ausführungshistorie
Jeder Trigger pflegt eine pro-Trigger Run-Historie. Die Historienansicht zeigt:
- Farbcodierte Quelltyp-Badges — Webhook-ausgelöste Runs schnell von E-Mail- oder Browser-ausgelösten Runs unterscheiden
- Erweiterbare Zeilen — In jeden Eintrag klicken, um die rohe Event-Payload und die aufgelöste Eingabe zu sehen, die an das Recipe oder den Workflow übergeben wurde
- Links zu resultierenden Runs — Direkt vom Trigger-Ereignis zum Recipe- oder Workflow-Run springen, den es ausgelöst hat
Das macht Debugging unkompliziert. Wenn ein Connector-Änderungstrigger ausgelöst hat, aber der resultierende Workflow unerwartete Ausgaben produziert hat, können Sie in drei Klicks vom Trigger-Ereignis zur aufgelösten Eingabe zum Ausführungs-Trace navigieren.
Verfügbarkeit
Ereignisgesteuerte Trigger (Run-Completion, Connector geändert, E-Mail empfangen, Slack-Nachricht und Browser-Ereignis) sind ab dem Pro-Tarif verfügbar. Webhook- und Cron-Trigger sind in allen Tarifen verfügbar. Alle Features ansehen oder kostenlose Testversion starten.