Trigger (Auslöser)

Was ist ein Trigger?

Ein Trigger (deutsch: Auslöser) ist der Startpunkt eines Workflows. Er legt fest, wann Flower einen Ablauf ausführt: ob Sie ihn von Hand starten, ob er zu einer festen Uhrzeit läuft, ob eine neue Datei in einem Ordner ihn anstößt oder ob eine eingehende E-Mail ihn auslöst.

Jeder Workflow beginnt in seiner YAML mit der Sektion trigger:. Darunter steht der Ablauf (ablauf:), also die Schritte, die abgearbeitet werden, sobald der Trigger feuert. Ein Workflow kann auch mehrere Trigger haben — er läuft dann, sobald einer davon feuert.

Beim Auslösen stellt der Trigger dem Ablauf Variablen bereit. Ein Datei-Trigger setzt zum Beispiel die Variablen datei und pfad, ein Mail-Trigger setzt absender, betreff und inhalt. Diese Werte verwenden Sie anschließend in den Schritten Ihres Workflows.

• Ein manuell-Trigger startet den Workflow per Knopf, Desktop-Verknüpfung oder Kommandozeile.
• Ein zeitplan-Trigger startet den Workflow zeitgesteuert (täglich, wöchentlich, stündlich …).
• Die Ordner-Trigger neue-datei, geänderte-datei, gelöschte-datei und umbenannte-datei reagieren auf Datei-Ereignisse.
• Der webhook-Trigger reagiert auf einen eingehenden Web-Aufruf (HTTP).
• Modul-Trigger kommen von einzelnen Modulen — etwa der Mail-Eingang aus Outlook oder IMAP.

Manueller Start

Der manuell-Trigger löst nie von allein aus — Sie starten ihn selbst: über einen Knopf im Editor, über eine Desktop-Verknüpfung oder über die Kommandozeile. Im Editor können Sie einen manuell-Trigger per Ziehen auf den Desktop ablegen; daraus entsteht eine Verknüpfung, mit der jeder den Workflow per Doppelklick startet.

Der manuell-Trigger selbst kennt keine Eingabe-Maske. Wenn Ihr Workflow Eingaben vom Nutzer braucht, fragen Sie diese im Ablauf über das dialog-Modul ab. So bleibt der Trigger schlank und die Eingaben sind ein normaler Workflow-Schritt.

Ein manueller Trigger setzt die Variablen zeitpunkt und nutzer, damit Sie im Ablauf wissen, wann und von wem der Workflow gestartet wurde.

trigger:
  - typ: manuell
    name: "Auftrag anlegen"

ablauf:
  - dialog:
      aktionen:
        - eingabe:
            titel: "Auftrag anlegen"
            felder:
              - { name: kunde,  typ: text, label: "Kundenname" }
              - { name: betrag, typ: zahl, label: "Auftragsbetrag" }

  - aufruf: "auftrag-anlegen-intern.flower"
    inputs:
      kunde:  kunde
      betrag: betrag

Zeitgesteuert (Zeitplan)

Der zeitplan-Trigger lässt einen Workflow automatisch zu festen Zeiten laufen. Sie wählen einen Rhythmus über wann: — etwa täglich, wöchentlich, monatlich, werktags, wochenende oder die Intervalle stündlich, minütlich und sekündlich — und bei den Tages-Rhythmen eine uhrzeit:.

Bei wöchentlich geben Sie zusätzlich den wochentag: an, bei monatlich den tag: (auch tag: letzter für den letzten Tag des Monats). Die zeitzone: ist optional und steht standardmäßig auf der System-Zeitzone. Für freie Abstände gibt es alle:, zum Beispiel alle: "30 sekunden".

Flower verzichtet bewusst auf die kryptische Cron-Syntax — das strukturierte Format deckt die typischen Büro-Zeitpläne verständlich ab. Ein zeitplan-Trigger setzt die Variable zeitpunkt.

• wann: täglich | wöchentlich | monatlich | werktags | wochenende | stündlich | minütlich | sekündlich
• uhrzeit: "09:00" bei den Tages-Rhythmen; bei Intervallen entfällt sie.
• wöchentlich braucht wochentag:, monatlich braucht tag: (Zahl oder letzter).
• alle: setzt einen festen Abstand, z.B. alle: "30 sekunden".

trigger:
  - typ: zeitplan
    wann: werktags
    uhrzeit: "09:00"
    zeitzone: "Europe/Berlin"

ablauf:
  - office.excel:
      bereich-lesen:
        datei: "C:\\Berichte\\umsatz.xlsx"
        bereich: "A1:D20"
        ergebnis: zahlen

  - office.outlook.mail:
      senden:
        an: "leitung@firma.de"
        betreff: "Tagesreport"
        inhalt: zahlen

Ordner-Ereignisse

Vier Trigger reagieren auf Dateien in einem Ordner: neue-datei, geänderte-datei, gelöschte-datei und umbenannte-datei. Jedes Ereignis ist ein eigener Trigger-Typ — es gibt kein Auswahlfeld für die Ereignis-Art. Wer auf mehrere Ereignisse desselben Ordners reagieren will, legt einfach mehrere Trigger an.

Sie geben den pfad: zum überwachten Ordner an. Mit rekursiv: ja werden auch Unterordner einbezogen (Standard ist nein). Mit filter: schränken Sie über Glob-Muster wie "*.pdf" ein, welche Dateien zählen. Die stabilitäts-wartezeit: (z.B. 5s) lässt Flower warten, bis eine Datei fertig geschrieben ist und nicht mehr wächst — sinnvoll bei großen oder langsam kopierten Dateien.

Ordner-Trigger setzen die Variablen datei (Dateiname), pfad und zeitpunkt. So weiß Ihr Workflow genau, welche Datei das Ereignis ausgelöst hat, und kann sie direkt weiterverarbeiten.

• neue-datei, geänderte-datei, gelöschte-datei, umbenannte-datei — je ein eigener Trigger.
• pfad: ist der überwachte Ordner; rekursiv: ja bezieht Unterordner ein.
• filter: ist eine Liste von Glob-Mustern, z.B. "*.pdf".
• stabilitäts-wartezeit: wartet, bis die Datei vollständig geschrieben ist.

trigger:
  - typ: neue-datei
    pfad: "C:\\Eingang"
    rekursiv: nein
    filter:
      - "*.pdf"
    stabilitäts-wartezeit: 5s

ablauf:
  - aufruf: "pdf-zu-excel.flower"
    inputs:
      pdf_pfad: datei

Webhook und Modul-Trigger

Der webhook-Trigger startet einen Workflow, wenn ein anderes System einen Web-Aufruf (HTTP) an Flower schickt — etwa ein Online-Formular oder eine Fremd-Software. Über pfad: legen Sie die Adresse fest, über methode: die erlaubten HTTP-Methoden (Standard POST) und über netzwerk: ob nur der eigene Rechner (lokal), das lokale Netz (lan) oder alle erreichen dürfen. Mit auth: sichern Sie den Webhook gegen unbefugte Aufrufe ab. Ein webhook-Trigger setzt körper, kopf, methode und zeitpunkt.

Modul-Trigger bringen einzelne Module mit. Das Outlook-Mail-Modul liefert zum Beispiel den Eingang-Trigger, ein IMAP-Modul den neue-mail-Trigger. Im typ: schreiben Sie sie in der Punkt-Form modul.trigger-name, etwa office.outlook.mail.eingang. Diese Trigger setzen Mail-Variablen wie absender, betreff, inhalt und anhänge.

Mail-Trigger lassen sich mit einem filter: präzise eingrenzen: nach absender (auch mit Platzhaltern wie *@partner.de), nach betreff-enthält oder nur-mit-anhang: ja. So feuert der Workflow nur bei den E-Mails, die wirklich relevant sind.

• webhook: pfad:, methode:, netzwerk: (lokal | lan | alle) und auth: zur Absicherung.
• Der Webhook-Port ist dienstweit (Standard 8765, nur lokal), nicht pro Workflow.
• Modul-Trigger nutzen die typ:-Form modul.trigger-name, z.B. office.outlook.mail.eingang.
• Mail-Trigger filtern nach absender, betreff-enthält und nur-mit-anhang.

trigger:
  - typ: office.outlook.mail.eingang
    konto: standard
    ordner: posteingang
    filter:
      betreff-enthält: "Auftrag"
      nur-mit-anhang: ja

ablauf:
  - wenn: anhänge ist nicht leer
    dann:
      - datei:
          speichern:
            quelle: anhänge
            ziel: "C:\\Auftraege"
    sonst:
      - benachrichtigung:
          anzeigen:
            text: "Auftragsmail ohne Anhang von absender"

Trigger-Schalter: aktiv und Testmodus

Damit ein Trigger überhaupt überwacht oder ausgelöst wird, muss der Workflow im Hintergrund-Dienst registriert sein. Flower durchsucht keine Ordner von allein — Sie registrieren einen Workflow ausdrücklich, danach legt der Dienst für jeden seiner Trigger einen Eintrag an. Jeder neue Eintrag startet im Zustand inaktiv mit Testmodus aus.

Jeder Trigger hat zwei unabhängige Schalter. Schalter 1 (aktiv / inaktiv) bestimmt, ob der Trigger scharf ist. Bei inaktiv überwacht der Dienst das Ereignis nicht und der Trigger feuert nicht. Schalter 2 (Testmodus an / aus) bestimmt, ob ein ausgelöster Lauf simuliert wird (an) oder echt ausgeführt wird (aus). Im Testmodus zeigt Flower, was passieren würde, ohne reale Aktionen wie Mailversand oder Dateiänderungen wirklich auszuführen.

Ereignis-Trigger (Datei, Zeitplan, Webhook, Modul-Trigger) feuern autonom, sobald ihr Ereignis eintritt — sie lassen sich nicht von Hand auslösen, weil sonst die Trigger-Variablen fehlen würden. Der manuell-Trigger feuert nie von allein; ist er inaktiv und Sie lösen ihn trotzdem aus, passiert nichts außer einem Eintrag im Service-Log. Die Schalter setzen Sie im Editor oder über die Kommandozeile.

• Schalter 1 — aktiv / inaktiv: ob der Trigger scharf ist.
• Schalter 2 — Testmodus an / aus: simulierter Lauf (an) oder echter Lauf (aus).
• Neue Trigger starten immer als inaktiv mit Testmodus aus.
• Ereignis-Trigger feuern nur autonom; der manuell-Trigger nur durch den Nutzer.
• Direkte Test-Läufe aus dem Editor brauchen keine Registrierung.