Mit Kindprozessen arbeiten
https://www.loom.com/share/08883fb2f3914073aafe1dd5e852793f
1. Einleitung
In Xentral Connect können Flows nicht nur einzeln ausgeführt, sondern auch miteinander verschachtelt werden. Das bedeutet: Ein Flow kann automatisch einen anderen starten – entweder direkt (synchron) oder über die Queue (asynchron). Diese Funktion ist besonders hilfreich, wenn du umfangreiche Prozesse modular aufbauen und wiederverwenden möchtest.
2. Warum Flows verschachteln?
Das Verschachteln von Flows ermöglicht:
Modularisierung: komplexe Abläufe in kleinere, wartbare Teilprozesse zerlegen
Wiederverwendung: Teilprozesse (z. B. Validierungen, Datenimporte, API-Aufrufe) mehrfach nutzen
Struktur und Übersicht: Hauptprozesse („Elternprozesse“) steuern ihre Unterprozesse („Kindprozesse“)
Parallelisierung oder Abhängigkeiten: Prozesse sequenziell oder parallel ausführen
Beispiel: Ein Hauptprozess ruft eine Bestellliste ab, iteriert über alle Einträge und startet für jede Bestellung einen Unterprozess zur Einzelverarbeitung.
3. Eltern- und Kind-Flows in Connect
In der Flow-Übersicht können Flows optisch verschachtelt dargestellt werden (siehe Flow gruppieren, verschieben, verschachteln). Diese Struktur dient zunächst nur der Übersicht, hat aber noch keine funktionale Verknüpfung. Damit ein Flow tatsächlich einen anderen ausführt, muss er über einen internen Trigger oder ein internes Event aufgerufen werden.
4. Variante 1: Interner Trigger
4.1 Zweck
Mit dem internen Trigger kann ein Flow direkt einen anderen starten. Die Ausführung erfolgt dabei in Echtzeit oder über die Queue, je nach Konfiguration.
4.2 Anwendung
Synchron oder asynchron auswählen
Wähle aus, ob du den Flow synchron oder asynchron starten möchtest (“Sofortige Ausführung”):
Sofortige Ausführung (synchron): Der Elternprozess wartet auf die Ausführung des Kind-Flows. Das Ergebnis der Kind-Flows kann im Eltern-Flow weiterverarbeitet werden.
Nutze das Response Element im Kind-Flow, um die Daten zu definieren, die an den Elternprozess zurückgegeben werden sollten.
Asynchrone Ausführung: Die Iteration des Flows wird auf die Queue gelegt. Die Queue entscheidet (je nach Anzahl an Workern), wann der Flow ausgeführt wird. Der Elternprozess wartet nicht auf die Ausführung des Kind-Flows und hat keinen Zugriff auf das Ergebnis.
4.3 Beispiel
Ziel-Flow
Flow, der aufgerufen werden soll
FlowTest2
Parameter
Werte, die übergeben werden
id = 1234, name = "Order_01"
Sofortige Ausführung
führt den Kindprozess ohne Queue-Verzögerung aus
✅ aktiviert
4.4 Erweiterte Steuerung: Wait-for-Children
Wenn der Elternprozess warten soll, bis der Kindprozess abgeschlossen ist, verwende den Operator „Wait-for-Children“.
Füge die Komponente Wait-for-Children nach dem internen Trigger ein.
Wähle, auf welchen Kindprozess gewartet werden soll.
Der Hauptprozess pausiert an dieser Stelle, bis der Kindprozess beendet wurde.
Anwendungsfall: Ein Hauptprozess ruft nacheinander Teilprozesse auf und soll erst fortfahren, wenn der vorherige vollständig abgeschlossen ist.
4.4.1 Abgrenzung zum synchronem Triggern
Das "Wait-for-Children"-Element wird verwendet, wenn ein übergeordneter Prozess (Elternprozess) einen untergeordneten Prozess (Kindprozess) asynchron startet. Vorteile gegenüber synchrone Triggerung:
Pausieren des Elternprozesses:
Wenn ein Kindprozess asynchron getriggert wird, pausiert das "Wait-for-Children"-Element den Elternprozess.
Der Elternprozess läuft erst dann weiter, wenn alle getriggerten Kindprozesse abgeschlossen sind.
Der Elternprozess blockiert die Ressourcen nicht aktiv, sondern ist technisch nur pausiert, bis die Kindprozesse ihre Arbeit beendet haben.
Vermeidung von Timeouts:
Diese Pause verhindert, dass der Elternprozess aufgrund der langen Ausführungszeit der Kindprozesse ein Timeout meldet und abbricht.
Das verbessert die Performance und Stabilität des Ablaufs.
Parallele Abarbeitung der Kind-Jobs:
Die Kindprozesse werden durch das asynchrone Triggern auf die Queue gelegt und können von mehreren Workern parallel abgearbeitet werden.
Warten auf Prozessketten:
Das Element erlaubt es dem Elternprozess, auf eine gesamte Kette von Prozessen zu warten, selbst wenn der ursprünglich gestartete Kindprozess weitere Prozesse triggert.
5. Variante 2: Internes Event
5.1 Zweck
Statt einen Flow direkt auszulösen, kannst du auch ein internes Event erzeugen, das von einem oder mehreren Flows verarbeitet wird. Damit lassen sich mehrere Folgeprozesse parallel starten.
5.2 Anwendung
Füge aus der Komponentenbibliothek den Operator „Event“ hinzu.
Definiere das Event als intern über das Topic “Internal”.
Wähle den Event-Typ aus einer vordefinierten Liste (z. B. New Sales Order).
Definiere optional Parameter, die mit dem Event übergeben werden.
In einem anderen Flow verwende den Trigger „Event Trigger“, um auf dieses Event zu reagieren.
5.3 Unterschiede zum internen Trigger
Ausführung
Asynchron über Queue oder synchron (optional sofort)
Asynchron über Event-Bus
Zielanzahl
Ein einzelner Workflow
Beliebig viele Workflows
Parameterübergabe
Direkt
Über Event-Payload
Wartefunktion (Wait-for-Children)
Ja
Nein
Typischer Einsatz
Steuerungs- oder Prozessketten
Broadcast-Ereignisse (z. B. bei Statusänderungen)
7. Typische Anwendungsfälle
Verarbeitung von Datensätzen in Schleife
Interner Trigger pro Item
Prozesskette mit Abhängigkeiten
Interner asynchroner Trigger + Wait-for-Children
Ein Ereignis löst mehrere Prozesse aus
Event Trigger
Modularisierung großer Workflows
Elternprozess mit Kindprozessen
Echtzeit-Weitergabe von Daten
Interner Trigger mit Sofortausführung
Zuletzt aktualisiert
War das hilfreich?