Testlauf & virtuelles Dateisystem

Was ein Testlauf ist

Ein Testlauf lässt deinen Workflow ganz normal durchlaufen, ohne dass dabei in der echten Welt etwas passiert. Aktionen, die nur lesen, laufen mit echten Daten. Aktionen, die etwas verändern würden — eine Datei speichern, eine Mail senden, einen Eintrag löschen — werden nicht wirklich ausgeführt, sondern liefern dir nur eine Vorschau, was passiert wäre.

So kannst du gefahrlos ausprobieren, ob ein Workflow das Richtige tut, bevor du ihn scharf schaltest. Am Ende eines Testlaufs ist im echten System nichts verändert worden. Flower unterscheidet dabei selbstständig zwischen lesenden und verändernden Schritten — du musst nichts dafür einstellen.

Den Testlauf startest du am bequemsten über den Test-Lauf-Knopf im Editor. Wer mit der Kommandozeile arbeitet, hängt an den Lauf-Befehl die Option für den Simulations-Modus an.

• Lesen geschieht echt — mit realistischen Daten, damit die Probe aussagekräftig ist.
• Verändern geschieht nur als Vorschau — kein Speichern, kein Versand, kein Löschen in echt.
• Am Ende bleibt das echte System unverändert.
• Gestartet per Test-Lauf-Knopf im Editor oder per Simulations-Option in der Kommandozeile.

Das virtuelle Dateisystem (Overlay)

Bei Datei-Operationen legt Flower im Testlauf eine unsichtbare Zwischenschicht über deine echten Ordner — ein sogenanntes Overlay. Lesende Schritte greifen weiter auf die echten Dateien zu, damit du mit realen Inhalten arbeitest. Schreibende Schritte (Anlegen, Ändern, Löschen, Verschieben) landen dagegen nur in dieser virtuellen Schicht.

Das Praktische daran: Liest dein Workflow später im selben Testlauf eine Datei, die er vorher verändert hat, sieht er die simulierte Fassung — als wäre sie wirklich geschrieben worden. Der Ablauf bleibt also in sich stimmig, ganz so wie im echten Betrieb. Trotzdem bleibt deine echte Festplatte und das Netzlaufwerk komplett unberührt.

• Lesen: läuft echt auf der echten Datei.
• Schreiben/Ändern/Löschen/Verschieben: passiert nur in der virtuellen Overlay-Schicht.
• Spätere Lese-Schritte im selben Testlauf sehen die simulierte Version — der Ablauf bleibt konsistent.
• Das echte Dateisystem wird nicht angefasst.

trigger:
  - typ: manuell
ablauf:
  - datei.verschieben:
      von: C:/Eingang/rechnung.pdf
      nach: C:/Archiv/rechnung.pdf
  - datei.existiert:
      pfad: C:/Archiv/rechnung.pdf
      ergebnis: ist_da

Externe Sendungen als Vorschau

Schickt dein Workflow etwas nach draußen — eine E-Mail, eine Nachricht, eine Benachrichtigung — dann wird im Testlauf nichts versendet. Stattdessen öffnet das Modul ein Vorschau-Fenster mit der vollständigen Nachricht: Empfänger, Betreff, Inhalt und Anhänge. Du siehst genau, was beim echten Lauf rausgegangen wäre.

Danach läuft der Workflow ganz normal weiter, als wäre der Versand erfolgreich gewesen. So testest du auch lange Abläufe komplett durch, ohne dass jemand versehentlich eine Test-Mail bekommt.

Bei offenen Schnittstellen, bei denen Flower nicht erkennen kann, ob ein Aufruf nur liest oder etwas verändert — etwa allgemeine Web-/REST-Aufrufe oder freie Datenbank-Abfragen — fragt dich das Modul pro Aufruf: Soll es echt ausführen (sinnvoll bei reinen Lese-Aufrufen) oder soll eine Antwort vorgegeben werden, die du selbst einträgst?

• Mail/Nachricht/Notification: Vorschau-Fenster statt Versand, Workflow läuft danach weiter.
• Eindeutige Schreib-Aktionen (z. B. Mail senden) werden ohne Nachfrage simuliert.
• Eindeutige Lese-Aktionen (z. B. Excel-Zelle lesen) laufen ohne Nachfrage echt.
• Offene Aufrufe (Web/REST, freie Datenbank-Abfragen): Nachfrage pro Aufruf — echt ausführen oder Antwort vorgeben.

trigger:
  - typ: manuell
ablauf:
  - für-jede:
      liste: empfaenger
      als: person
      ablauf:
        - office.outlook.mail.senden:
            an: person.email
            betreff: Monatsbericht
            text: Anbei der aktuelle Bericht.

Testmodus-Schalter am Trigger

Der Test-Lauf-Knopf ist für das gezielte Ausprobieren im Editor gedacht. Wenn du aber sehen willst, wie sich ein Workflow verhält, wenn er von selbst durch ein Ereignis ausgelöst wird — eine neue Datei im Ordner, eine eingehende Mail, ein Zeitplan — dann nutzt du den Testmodus-Schalter am Trigger.

Jeder registrierte Trigger hat zwei voneinander unabhängige Schalter. Der erste (aktiv/inaktiv) entscheidet, ob der Trigger überhaupt scharf ist. Der zweite ist der Testmodus (an/aus): Steht er auf an, läuft jeder durch diesen Trigger gestartete Workflow simuliert — mit virtuellem Dateisystem und Sendungs-Vorschau. Steht er auf aus, läuft er echt.

So kannst du einen Trigger scharf schalten und ihn zunächst im Testmodus beobachten: Das echte Ereignis löst den Workflow aus, du siehst die Vorschauen, aber es passiert nichts Bleibendes. Erst wenn du zufrieden bist, schaltest du den Testmodus aus. Neu registrierte Trigger starten übrigens immer inaktiv und mit Testmodus aus.

• Schalter 1 — aktiv/inaktiv: ist der Trigger scharf?
• Schalter 2 — Testmodus an/aus: läuft der ausgelöste Workflow simuliert oder echt?
• Testmodus an + aktiv: echtes Ereignis löst aus, aber alles bleibt eine Vorschau.
• Schalter werden über Editor und Kommandozeile gesetzt; ein manueller Trigger lässt sich darüber auch von Hand auslösen.

trigger:
  - typ: neue-datei
    pfad: C:/Eingang
ablauf:
  - datei.verschieben:
      von: trigger.datei
      nach: C:/Archiv

Prüf-Modus — Schritt für Schritt durchgehen

Der Prüf-Modus ist ein Debug-Werkzeug zum genauen Hinschauen. Anders als der Testlauf hält er den Workflow vor jeder verändernden Aktion an und zeigt dir ein Fenster: Es beschreibt, was die Aktion gleich tun würde, und listet die einfließenden Werte mit Wert und Herkunft auf (kommt der Wert vom Trigger, vom Vorgänger-Schritt, aus einem Standardwert?). So findest du falsch verdrahtete Felder oder Umwandlungs-Fehler genau an der Stelle, an der sie wirken.

Du schaltest den Prüf-Modus im Workflow-Kopf mit dem Schlüssel prüfen ein. Bei jeder verändernden Aktion wählst du Erlauben (die Aktion läuft, der Workflow geht weiter bis zur nächsten) oder Ablehnen (der Lauf wird sofort abgebrochen). Fehlt der Schlüssel oder steht er auf nein, läuft der Workflow ohne Nachfragen durch — das ist der Normalfall im Produktivbetrieb.

Wichtig: Prüf-Modus und Testlauf sind unabhängig voneinander. Du kannst einen echten Lauf Schritt für Schritt freigeben oder einen simulierten Testlauf in Ruhe durchsteppen. Der Prüf-Modus ist ein Debug-Helfer, kein Sicherheits-Tor des Normalbetriebs.

• Einschalten über prüfen: ja im Workflow-Kopf; Standard ist aus.
• Hält vor jeder verändernden Aktion an und zeigt die einfließenden Werte samt Herkunft.
• Erlauben führt die Aktion aus, Ablehnen bricht den Lauf ab.
• Unabhängig vom Testlauf: kombinierbar mit echtem oder simuliertem Lauf.

prüfen: ja
trigger:
  - typ: manuell
ablauf:
  - office.excel.zeile-anhängen:
      datei: C:/Berichte/liste.xlsx
      werte: [Heute, Erledigt]

Was im Protokoll steht

Damit du später nie verwechselst, ob ein Lauf echt gewirkt hat oder nur eine Probe war, markiert Flower jeden Testlauf im Audit-Protokoll. Der Start-Eintrag eines simulierten Laufs trägt einen Vermerk, dass es sich um eine Simulation handelt; echte Läufe sind entsprechend als echt gekennzeichnet.

Dadurch bleibt im Nachhinein eindeutig nachvollziehbar, welche protokollierten Schreib-Aktionen tatsächlich etwas verändert haben und welche nur simuliert waren. Lehnst du im Prüf-Modus eine Aktion ab, wird der Lauf als abgebrochen festgehalten.

• Simulierte Läufe sind im Protokoll als Simulation gekennzeichnet, echte Läufe als echt.
• So bleibt echte und simulierte Wirkung im Nachhinein klar unterscheidbar.
• Im Prüf-Modus abgelehnte Läufe werden als abgebrochen protokolliert.