Flow-Organisation

Eine durchdachte Organisation der Flows ist entscheidend fuer die langfristige Wartbarkeit eines LowCode-Projekts. Diese Seite zeigt bewaehrte Konventionen fuer Benennung, Strukturierung und Dokumentation.

Naming Conventions

Tabs benennen

Verwenden Sie sprechende, konsistente Namen fuer Ihre Tabs:

Empfohlenes Praefix-Schema:

• API - ... fuer REST-Endpunkte
• Engine - ... fuer Engine-Integrationen
• UI - ... fuer Dashboard-Flows
• Util - ... fuer Hilfsfunktionen
• Config - ... fuer Konfigurationsflows
• ETW - ... fuer External-Task-Worker

Nodes benennen

Jede Node sollte einen beschreibenden Namen erhalten:

Schlecht:                         Gut:
[function]                       [function: E-Mail validieren]
[http in]                        [http in: POST /api/benutzer]
[switch]                         [switch: Status pruefen]
[change]                         [change: Antwort vorbereiten]
[debug]                          [debug: Validierungsergebnis]

Function Nodes

Benennen Sie Function Nodes nach der ausgefuehrten Aktion, nicht nach technischen Details:

Schlecht:                         Gut:
[function: map]                  [function: Benutzer transformieren]
[function: check]                [function: Berechtigung pruefen]
[function: process]              [function: Auftrag berechnen]

Tab-Struktur

Organisieren Sie Ihre Tabs nach fachlichen Bereichen. Eine bewaehrte Struktur fuer ein typisches ProcessCube®-Projekt:

Tab 1: Config - Globale Einstellungen
Tab 2: API - Benutzerverwaltung
Tab 3: API - Auftragsverwaltung
Tab 4: Engine - Auftragsworkflow
Tab 5: Engine - Genehmigungsprozess
Tab 6: ETW - PDF-Erzeugung
Tab 7: ETW - E-Mail-Versand
Tab 8: UI - Dashboard Startseite
Tab 9: UI - Auftragsformular
Tab 10: Util - Fehlerbehandlung

Faustregel: Ein Tab sollte maximal 20-30 Nodes enthalten. Wird ein Tab groesser, sollte er aufgeteilt werden.

Subflows

Subflows kapseln wiederverwendbare Logik in einer eigenen, wiederverwendbaren Node.

Wann Subflows einsetzen

• Gleiche Logik wird in mehreren Flows benoetigt
• Ein Abschnitt hat klar definierte Ein-/Ausgabe
• Die Logik ist in sich abgeschlossen (z.B. Validierung, Formatierung)

Subflow-Beispiel: Standardisierte Fehlerantwort

// Subflow: "API Fehlerantwort"
// Input: msg.statusCode, msg.errorMessage
msg.payload = {
    success: false,
    error: {
        code: msg.statusCode || 500,
        message: msg.errorMessage || "Interner Serverfehler"
    },
    timestamp: new Date().toISOString()
};
msg.headers = { "Content-Type": "application/json" };
return msg;

Verwendung:

[http in: POST /api/daten] → [function: Validierung] → [http response]
                                     ↓ (Fehler)
                             [Subflow: API Fehlerantwort] → [http response]

Subflow mit Umgebungsvariablen

Subflows koennen eigene Umgebungsvariablen definieren, die bei jeder Instanz konfigurierbar sind:

// Subflow: "Datenbank-Abfrage" mit Umgebungsvariable TABLE_NAME
const tableName = env.get("TABLE_NAME");
const query = `SELECT * FROM ${tableName} WHERE active = true`;
msg.payload = query;
return msg;

Link Nodes

Link Nodes verbinden Flows ueber Tab-Grenzen hinweg, ohne lange, unuebersichtliche Wires zu zeichnen.

Best Practices fuer Link Nodes

1. Konsistente Benennung: Verwenden Sie das Schema [Quelle] → [Ziel]
2. Richtung angeben: Praefix IN: oder OUT: zur Verdeutlichung
3. Zusammengehoerige Paare gleich benennen

Tab "API - Bestellungen":
  [http in: POST /api/bestellung] → [function: Validierung] → [link out: Bestellung → Workflow]

Tab "Engine - Bestellworkflow":
  [link in: Bestellung → Workflow] → [process-start: Bestellprozess]

Comment Nodes

Comment Nodes dokumentieren den Zweck eines Flow-Abschnitts direkt im Editor.

Empfohlene Verwendung

[comment: ============================================]
[comment: Bestellverarbeitung                         ]
[comment: Validiert eingehende Bestellungen und       ]
[comment: startet den Genehmigungsworkflow.           ]
[comment: Letztes Update: 2025-01-15                  ]
[comment: ============================================]

Platzieren Sie Comment Nodes oberhalb des zugehoerigen Flow-Abschnitts.

Groups

Groups fassen zusammengehoerige Nodes visuell zusammen.

Groups erstellen

1. Nodes auswaehlen, die zusammengehoeren
2. Rechtsklick, “Group” und dann “Group selection”
3. Group benennen (z.B. “Validierung”, “Datenbank-Zugriff”)

Empfohlene Group-Einteilung

Gut vs. schlecht organisiert

Schlecht organisiert

• Alle Nodes auf einem einzigen Tab
• Keine Namen an den Nodes
• Kreuz und quer verlaufende Verbindungen
• Keine Comments oder Groups
• Duplizierte Logik statt Subflows

Gut organisiert

• Fachlich getrennte Tabs mit sprechenden Namen
• Jede Node mit beschreibendem Label
• Geradliniger Flow-Verlauf von links nach rechts
• Comment Nodes zur Dokumentation
• Groups fuer visuelle Zusammenfassung
• Subflows fuer wiederverwendbare Logik
• Link Nodes fuer tab-uebergreifende Verbindungen

Checkliste fuer neue Flows

Pruefen Sie bei jedem neuen Flow die folgenden Punkte:

• Alle Nodes haben einen aussagekraeftigen Namen
• Der Tab hat ein Praefix und einen fachlichen Namen
• Comment Nodes dokumentieren den Zweck
• Zusammengehoerige Nodes sind in Groups zusammengefasst
• Wiederverwendbare Logik ist in Subflows ausgelagert
• Fehlerbehandlung ist mit Catch Nodes implementiert
• Der Flow verlaeuft uebersichtlich von links nach rechts

Weiterführende Informationen

• Node-RED Grundlagen — Grundlegende Konzepte
• Best Practices — Allgemeine Entwicklungsrichtlinien
• Migration & Versionierung — Flows versionieren