Unterabläufe

Ab OPC Router 5.7 kann ein Flow Teile seiner Verarbeitung in Unterabläufe auslagern: eigenständige, kleine Abläufe, die nicht durch einen Trigger, sondern von einem Transferobjekt des aufrufenden Flows gestartet werden. Damit lassen sich Abläufe bedingt ausführen (IF/THEN/ELSE), gegen Fehler absichern (Try/Catch), nur bei Wertänderungen ausführen (Change Gate) und einmal definierte Verarbeitungsschritte aus beliebig vielen Flows wiederverwenden (Funktion).

Diese Seite beschreibt das gemeinsame Konzept aller Unterablauf-Varianten: was ein Unterablauf ist, wie Werte hinein- und herausgelangen, wie Unterabläufe veröffentlicht und zur Laufzeit ausgeführt werden und was beim Kopieren, Exportieren und Löschen geschieht. Die Eigenschaften der einzelnen Transferobjekte stehen auf den jeweiligen Detailseiten.

Begriffe

In der Oberfläche begegnen Ihnen für dasselbe Konzept die Bezeichnungen Unterablauf, Subflow und Sub-Flow. Die wiederverwendbare Variante heißt in der Toolbox Funktion (FX); einige Schaltflächen (z. B. FB öffnen) und Einstellungen verwenden noch die ältere Bezeichnung Funktionsbaustein (FB) – gemeint ist immer dasselbe.

Die Idee

Ein normaler Flow beginnt mit einem Trigger und arbeitet seine Transferobjekte der Reihe nach ab. Ein Unterablauf ist ebenfalls ein Flow – aber ohne Trigger. An seiner Stelle steht ein Transferobjekt im aufrufenden Flow, der Aufrufer. Erreicht der Transfer des Haupt-Flows den Aufrufer, startet dieser den Unterablauf, übergibt ihm Werte, wartet auf das Ergebnis und arbeitet anschließend mit den Rückgabewerten weiter.

Aus Sicht des Haupt-Flows verhält sich der Aufrufer wie jedes andere Transferobjekt: Er hat Eingänge, die Sie verdrahten, und Ausgänge, deren Werte Sie weiterverwenden. Was dazwischen geschieht, projektieren Sie im Unterablauf – mit denselben Transferobjekten und Plug-ins wie sonst auch. Ein Unterablauf entspricht damit einem Unterprogramm bzw. einer Funktion in der Programmierung: eine abgeschlossene Verarbeitungseinheit mit definierten Eingängen und Rückgabewerten.

Die Aufrufer

Vier Transferobjekte aus der Toolbox-Gruppe Tools & ETL rufen Unterabläufe auf. Sie folgen demselben Prinzip und unterscheiden sich darin, wann sie den Unterablauf ausführen und wie viele Unterabläufe sie besitzen:

Aufrufer	Unterabläufe	Der Unterablauf läuft, wenn …	Typischer Einsatz
Bedingung (IF)	THEN (Pflicht), ELSE (optional)	… die Bedingung wahr ist (THEN) bzw. falsch ist (ELSE).	Verzweigung: „Nur wenn die Temperatur über 80 °C liegt, Alarm schreiben."
Fehlerbehandlung (Try/Catch)	TRY (Pflicht), CATCH (optional)	… immer (TRY); schlägt TRY endgültig fehl, läuft CATCH mit den Fehlerinformationen.	Absicherung: „Datenbank schreiben; bei Fehler bis zu dreimal wiederholen, dann Ersatzweg nehmen."
Change Gate	ON OPEN (ein Unterablauf)	… sich mindestens ein überwachter Wert relevant geändert hat (das Gate „öffnet").	Entlastung: „Nur bei tatsächlicher Wertänderung in die Cloud senden, nicht in jedem Zyklus."
Funktion (FX)	eine wiederverwendbare Funktion	… der Transfer den Aufruf erreicht – immer.	Wiederverwendung: „Dieselbe Umrechnung in 20 Flows nutzen, aber nur einmal pflegen."

Bedingung, Fehlerbehandlung und Change Gate besitzen ihre Unterabläufe privat als Zweige; die Funktion (FX) verweist auf eine wiederverwendbare Definition (siehe Zweige und Funktionen).

Aufbau eines Unterablaufs

Jede Unterablauf-Konstruktion besteht aus denselben vier Bestandteilen:

Bestandteil	Ort	Aufgabe
Aufrufer	Transferobjekt im aufrufenden Flow	Entscheidet, ob und wann der Unterablauf läuft, übergibt die Eingangswerte, wartet auf das Ergebnis und stellt die Rückgabewerte an seinen Ausgängen bereit.
Unterablauf	Eigener, versteckter Flow	Enthält die eigentliche Verarbeitung. Wird ausschließlich vom Aufrufer gestartet.
Scope-Eingang	Erstes Objekt im Unterablauf	Stellt die vom Aufrufer übergebenen Eingangswerte als Ausgangs-Items im Unterablauf bereit. Von hier aus verdrahten Sie die Werte in die Transferobjekte des Unterablaufs.
Scope-Rückgabe	Letztes Objekt im Unterablauf	Sammelt die Ergebnisse an seinen Eingangs-Items und liefert sie an den Aufrufer zurück.

Scope-Eingang und Scope-Rückgabe heißen zusammen Scope-Brücken. Sie sind feste Bestandteile jedes Unterablaufs: Sie werden automatisch angelegt, sind immer sichtbar – auch ohne deklarierte Ein-/Ausgänge – und können weder gelöscht noch kopiert oder eingefügt werden. Welche Items sie tragen, bestimmt der Kontrakt.

Was in einem Unterablauf anders ist

Bereich	Verhalten im Unterablauf
Trigger	Nicht zulässig. Das Ablegen eines Triggers aus der Toolbox oder das Einfügen aus der Zwischenablage wird abgewiesen.
Manueller Start	Nicht möglich. Unterabläufe erscheinen nicht in der Flow-Liste und können weder produktiv geschaltet noch von Hand gestartet werden.
Flow-Einstellungen	Ausgeblendet. Speicher für Statusdaten, Priorität, Flow-Timeout, Trigger-Verknüpfung, Sprache der Wertumwandlung und Store and Forward bestimmt der aufrufende Flow.
Scope-Brücken	Fest. Können weder gelöscht noch kopiert oder eingefügt werden – auch nicht über Rückgängig/Wiederholen.
Transferobjekte	Uneingeschränkt. Alle Transferobjekte und Plug-ins stehen zur Verfügung – auch weitere Aufrufer (Verschachtelung).

Unterablauf im Designer öffnen

Ein geöffneter Unterablauf erscheint als eigener Reiter neben dem Haupt-Flow, mit farbiger Markierung am oberen Rand. Ein Hinweisbanner über dem Diagramm zeigt, wozu er gehört:

• bei einem Zweig das Zweig-Kürzel (z. B. THEN, ELSE, TRY, CATCH) und Zweig von mit dem Namen des übergeordneten Flows als Link – bei einer Bedingung zusätzlich den Bedingungsausdruck;
• bei einer Funktion Wiederverwendbare Funktion und, wenn aus einer Aufrufstelle geöffnet, Aufgerufen von mit Link zum aufrufenden Flow.

Im Banner hinterlegen Sie einen Kommentar zum Unterablauf. Er erscheint als Tooltip an der Öffnen-Schaltfläche des Aufrufers (z. B. THEN öffnen, TRY öffnen, Subflow öffnen, FB öffnen) und macht den Zweck erkennbar, ohne den Unterablauf zu öffnen.

Zweige und Funktionen

Unterabläufe gibt es in zwei Ausprägungen, die sich in Besitz, Ablageort und Lebenszyklus unterscheiden.

Zweige (privat)

Die Unterabläufe von Bedingung, Fehlerbehandlung und Change Gate heißen Zweige. Ein Zweig gehört genau einem Aufrufer in genau einem Flow.

• Zweige werden am Diagramm-Knoten des Aufrufers erzeugt und geöffnet: Die Aktionsleiste zeigt z. B. THEN erstellen / THEN öffnen, TRY erstellen / CATCH erstellen, beim Change Gate Subflow erstellen / Subflow öffnen. Das Erstellen legt den Zweig mit seinen Scope-Brücken an und verknüpft ihn sofort mit dem Aufrufer; das Öffnen wechselt in einen neuen Reiter.
• Zweige erscheinen nirgends als eigenständige Flows – nicht im Flow-Baum, nicht in der Vorlagen-Oberfläche, nicht im Status-Baum und nicht als eigene Einträge im Veröffentlichen-Baum. Erreichbar sind sie nur über ihren Aufrufer.
• Zweige folgen ihrem Flow beim Umbenennen, Verschieben, Kopieren, Exportieren und Löschen (siehe Kopieren, Exportieren, Importieren und Löschen).
• Der Kontrakt wird am Aufrufer deklariert und auf alle seine Zweige synchronisiert: THEN und ELSE bzw. TRY und CATCH tragen denselben Kontrakt (CATCH zusätzlich die reservierten Fehler-Eingänge).

Im Konfigurationsspeicher liegen Zweige in versteckten, systemverwalteten Ordnern mit der Endung .Scopes neben ihrem Flow. Bearbeiten Sie diese Ordner nicht von Hand. Passen Zweige und Aufrufer nicht mehr zusammen (z. B. nach manuellem Verschieben von Dateien), zeigt der Editor des Aufrufers dies an und bietet Zweige reparieren bzw. Nicht referenzierte Zweige löschen an (beim Change Gate Subflow reparieren / Nicht referenzierte Subflows löschen).

Funktionen (wiederverwendbar)

Eine Funktion (FX) ist ein Unterablauf ohne festen Besitzer: Sie wird einmal als Funktions-Definition angelegt und von beliebig vielen Aufrufstellen in beliebig vielen Flows verwendet.

• Definitionen liegen in der Vorlagen-Oberfläche („Templates & FBs", Würfel-Symbol) und lassen sich dort wie Vorlagen in Gruppen ordnen.
• Der Kontrakt gehört der Definition. Jede Aufrufstelle übernimmt ihn unverändert; eigene Items außerhalb des Kontrakts gibt es an der Aufrufstelle nicht.
• Eine Definition, die noch von Aufrufstellen verwendet wird, kann nicht gelöscht werden – ebenso wenig eine Vorlagen-Gruppe, die eine verwendete Definition enthält.
• Funktionen dürfen weitere Funktionen aufrufen und Bedingungen, Fehlerbehandlungen oder Change Gates mit eigenen Zweigen enthalten. Ringverweise sind nicht zulässig (siehe Verschachtelung).

Zweig oder Funktion?

Verwenden Sie einen Zweig, wenn die Verarbeitung nur an genau dieser Stelle gebraucht wird. Verwenden Sie eine Funktion, wenn dieselbe Verarbeitung an mehreren Stellen oder in mehreren Flows benötigt wird – Sie pflegen sie dann an einer Stelle. Beide Formen lassen sich frei kombinieren: Eine Funktion kann innerhalb eines Zweigs aufgerufen werden und selbst Zweige enthalten.

Kontrakt: Eingänge und Ausgänge

Der Kontrakt legt fest, welche Werte in den Unterablauf hinein- und aus ihm herausgelangen:

• Eingänge – Werte, die der Aufrufer übergibt. Jeder Eingang erscheint als verdrahtbares Eingangs-Item am Aufrufer und als Ausgangs-Item am Scope-Eingang.
• Ausgänge – Werte, die der Unterablauf zurückliefert. Jeder Ausgang erscheint als Eingangs-Item an der Scope-Rückgabe und als Ausgangs-Item am Aufrufer.

Aufrufer	Richtung	Unterablauf
Eingang „Temperatur“	→	Scope-Eingang: Ausgangs-Item „Temperatur“
Eingang „Anlage“	→	Scope-Eingang: Ausgangs-Item „Anlage“
Ausgang „Freigabe“	←	Scope-Rückgabe: Eingangs-Item „Freigabe“

Jedes Kontrakt-Element hat einen innerhalb des Kontrakts eindeutigen Namen und einen Datentyp: String, Boolean, Byte, Int16, Int32, Int64, Float, Double, DateTime – jeweils auch als Array (z. B. Double Array). Übergebene Werte werden beim Aufruf in den Kontrakt-Datentyp umgewandelt; nicht umwandelbare Werte lassen den Transfer fehlschlagen. Arrays werden als Ganzes übergeben und zurückgegeben.

Wie ein Eingang seinen Wert erhält

1. Verdrahteter Wert – ein per Pfeil im Haupt-Flow gelieferter Wert hat immer Vorrang.
2. Fester Wert – ein direkt am Aufrufer eingetragener Wert (bei der Funktion (FX) im Reiter Eingänge; Array-Werte kommagetrennt, z. B. 1, 2, 3). Er gilt, solange der Eingang nicht verdrahtet ist.
3. Kein Wert – der Eingang bleibt zur Laufzeit leer. Der Editor weist beim Speichern darauf hin.

Wie ein Ausgang seinen Wert erhält

1. Rückgabewert – der Wert, den der Unterablauf über die Scope-Rückgabe geliefert hat.
2. Standardwert – der am Aufrufer je Ausgang hinterlegte Wert. Er greift, wenn der ausgeführte Unterablauf keinen Wert für diesen Ausgang liefert, und für alle Ausgänge, wenn kein Unterablauf ausgeführt wurde (Bedingung falsch ohne ELSE, Gate geschlossen, TRY endgültig fehlgeschlagen ohne CATCH).
3. Kein Wert – lief ein Unterablauf und ist weder Rückgabe- noch Standardwert vorhanden, schlägt der Transfer mit einer entsprechenden Meldung fehl. Wurde kein Unterablauf ausgeführt, bleibt der Ausgang leer.

Kontrakt bearbeiten

Der Kontrakt lässt sich an zwei Stellen bearbeiten – im Editor des Aufrufers (Zweige) bzw. im Funktionsdialog (Funktionen) und direkt an den Scope-Brücken im Unterablauf. Beide Wege wirken auf dasselbe Modell: Eine Änderung am Scope-Eingang eines THEN-Zweigs erscheint nach dem Speichern am Bedingungs-Transferobjekt und im ELSE-Zweig; eine Änderung am Scope-Eingang einer Funktion wirkt auf jede Aufrufstelle.

Beim Anwenden werden die Brücken-Items neu erzeugt. Bestehende Verdrahtungen im Unterablauf bleiben erhalten, solange die Namen unverändert sind; ein umbenanntes oder entferntes Element verschwindet samt Verdrahtung. Items, die der Aufrufer automatisch bereitstellt (z. B. die reservierten Fehler-Eingänge des CATCH-Zweigs), können an der Brücke nicht bearbeitet werden.

Variablen in Unterabläufen

Neben dem Kontrakt, der Werte pro Aufruf transportiert, kennen Unterabläufe Scope-Variablen. Sie funktionieren wie Vorlagen-Variablen: Eine Variable wird mit Name, Datentyp und Standardwert deklariert und in den Eigenschaften der Transferobjekte des Unterablaufs als Platzhalter {Name} verwendet – z. B. in einem OPC-Pfad, einem Tabellennamen, einem Topic oder einer Formel.

Der Unterschied zum Kontrakt: Ein Kontrakt-Eingang liefert einen Wert, der über Pfeile verdrahtet wird. Eine Variable ersetzt Konfigurationstext an Stellen, die sich nicht verdrahten lassen.

Im Unterablauf „Wert protokollieren“ ersetzt die Variable {Anlage} zum Beispiel an zwei Stellen Konfigurationstext:

Transferobjekt	Eigenschaft	Eingetragener Wert
Datenbank schreiben	Tabelle	Log_{Anlage}
OPC lesen	Pfad	ns=2;s={Anlage}.Ist

Deklaration

Variablen werden am Besitzer deklariert – im Reiter Variablen des Bedingungs-, Try/Catch- oder Change-Gate-Transferobjekts bzw. im Funktionsdialog der Funktion. Auch eine direkt im Unterablauf-Designer angelegte Variable wird automatisch in den Aufrufer und die Geschwister-Zweige übernommen. Als Datentyp stehen die Vorlagen-Variablentypen sowie Plug-in-Anbindungen zur Verfügung.

Belegung: statisch oder verdrahtet

Der Aufrufer belegt jede Variable auf eine von zwei Arten:

Belegung am Aufrufer	Verhalten
Wert gesetzt (statisch)	Gilt fest für diese Aufrufstelle und wird beim Veröffentlichen in die Ausführungskopie eingesetzt. Zur Laufzeit entsteht kein Aufwand.
Wert leer (verdrahtet)	Die Variable wird als verdrahtbares Eingangs-Item am Aufrufer bereitgestellt. Der Wert wird bei jedem Aufruf neu übergeben und eingesetzt. Ohne Verdrahtung greift der Standardwert der Variablen.

So lässt sich derselbe Unterablauf pro Aufrufstelle statisch auf eine Anlage festlegen oder pro Aufruf dynamisch mit dem Anlagennamen aus dem Trigger versorgen.

Plug-in-Anbindungen als Variablenwert

Hat eine Variable ein Plug-in als Datentyp, verweist sie auf eine Anbindung dieses Plug-ins (z. B. eine bestimmte Datenbank-Anbindung). Als Wert geben Sie den Namen der Anbindung an (Groß-/Kleinschreibung unerheblich); die interne Id wird ebenfalls akzeptiert. Ein Unterablauf kann so je Aufrufstelle mit einer anderen Anbindung arbeiten. Eine unbekannte Anbindung führt zu einem Transferfehler, der den gesuchten Namen nennt.

Unterabläufe in Vorlagen

Unterabläufe können Teil einer Vorlage sein; Vorlagen-Variablen ({Name}) dürfen auch innerhalb der Zweige und Funktionen verwendet werden. Beim Erstellen einer Instanz bietet der Dialog alle Variablen an, die die Vorlage einschließlich ihrer Unterabläufe verwendet; jede Instanz erhält beim Veröffentlichen eigene Ausführungskopien mit ihren Variablenwerten. Ist ein Name sowohl als Scope-Variable am Aufrufer als auch als Vorlagen-Variable vorhanden, gilt beim Veröffentlichen: statischer Wert am Aufrufer > Wert der Vorlagen-Instanz > Standardwert der Deklaration.

Keine Unterabläufe in dynamischen Vorlagen-Instanzen

Dynamische Instanzen (aus einer Datenbank erzeugte Instanzen) erhalten beim Veröffentlichen keine Ausführungskopien ihrer Unterabläufe. Ein Bedingungs-, Try/Catch-, Change-Gate- oder Funktionsaufruf in einer dynamischen Instanz kann zur Laufzeit nicht ausgeführt werden.

Verschachtelung und maximale Aufruftiefe

Unterabläufe dürfen verschachtelt werden: Ein Zweig kann Bedingungen, Fehlerbehandlungen, Change Gates und Funktionsaufrufe enthalten, eine Funktion kann weitere Funktionen aufrufen (z. B. FX → FX, IF → FX oder TRY → IF). Die Zweige eines verschachtelten Aufrufers gehören dem Zweig, in dem er liegt, und folgen ihm wie Zweige ihrem Haupt-Flow.

Zwei Grenzen schützen vor unkontrollierter Rekursion:

• Ringverweise – ein Unterablauf ruft sich direkt oder indirekt selbst auf – sind nicht zulässig. Sie werden bereits bei der Projektierung erkannt (Funktionsauswahl, Einfügen aus der Zwischenablage; die Meldung nennt die Verweiskette) und zur Laufzeit abgewiesen.
• Die maximale Aufruftiefe begrenzt, wie tief Aufrufe ineinander geschachtelt sein dürfen. Sie ist eine Experten-Einstellung in den Optionen der Runtime im Bereich Laufzeit unter Maximale Aufruftiefe für Unterabläufe (IF/FB) (Standardwert 16; nur im Expertenmodus sichtbar). Wird die Tiefe überschritten, meldet der Aufrufer einen Fehler, statt weiter zu verschachteln.

Veröffentlichen

Unterabläufe werden nie direkt veröffentlicht. Beim Veröffentlichen eines Flows erzeugt der OPC Router für jede Verwendung eines Unterablaufs eine eigene, versteckte Ausführungskopie – eine je Zweig und eine je Aufrufstelle einer Funktion (zehn Aufrufstellen derselben Funktion ergeben zehn Kopien). Dabei werden die statischen Variablenwerte des Aufrufers fest eingesetzt; verdrahtete Variablen behalten ihre Platzhalter, weil sie pro Aufruf gefüllt werden.

Weil jede Verwendung ihre eigene Kopie besitzt, wirkt eine Änderung an einem Zweig oder einer Funktion erst mit dem nächsten Veröffentlichen des aufrufenden Flows (gestuftes Ausrollen wie bei Vorlagen-Instanzen). Nicht erneut veröffentlichte Flows laufen mit ihrer bisherigen Kopie weiter; nach einer Funktionsänderung zeigt der Veröffentlichen-Baum alle aufrufenden Flows als geändert an. Entfällt eine Verwendung, wird die Kopie mit dem nächsten Veröffentlichen automatisch aus der Laufzeit entfernt.

Wie Ausführungskopien im Veröffentlichen-Baum dargestellt und gemeinsam mit ihrem Flow veröffentlicht werden, beschreibt Veröffentlichen und Status.

Ausführung zur Laufzeit

Ablauf eines Aufrufs

Erreicht der Transfer des Haupt-Flows den Aufrufer, geschieht Folgendes:

1. Der Aufrufer entscheidet, ob ein Unterablauf läuft (Bedingung auswerten, Gate prüfen) und welcher (THEN oder ELSE, TRY oder CATCH). Läuft keiner, werden die Standardwerte der Ausgänge angewendet und der Transfer fährt fort.
2. Der Aufrufer sammelt die Eingangswerte (verdrahteter vor festem Wert) und wandelt sie in die Kontrakt-Datentypen um. Verdrahtete Scope-Variablen werden in die Ausführungskopie eingesetzt.
3. Die Ausführungskopie wird gestartet: Der Scope-Eingang stellt die Werte bereit, die Transferobjekte des Unterablaufs werden wie in einem normalen Flow der Reihe nach ausgeführt.
4. Die Scope-Rückgabe sammelt die Ergebnisse. Der Aufrufer übernimmt sie an seine Ausgänge; für fehlende Werte greifen die Standardwerte.
5. Der Haupt-Flow fährt fort. Der Aufruf ist Teil desselben Transfers – der Haupt-Flow wartet, bis der Unterablauf beendet ist (synchroner Aufruf).

Der Unterablauf läuft im selben Ausführungskontext wie der Haupt-Flow: ein Transfer, ein Arbeits-Thread für die gesamte Verschachtelung; die Flow-Einstellungen des Haupt-Flows gelten auch für seine Unterabläufe.

Ein Aufruf pro Kopie

Pro Ausführungskopie läuft zu jedem Zeitpunkt höchstens ein Aufruf. Ein zweiter Aufruf derselben Kopie – etwa weil derselbe Flow durch einen schnellen Trigger mehrfach parallel läuft – wartet, bis der erste beendet ist. Verschiedene Aufrufstellen derselben Funktion beeinflussen sich dagegen nicht: Sie besitzen eigene Kopien und laufen unabhängig voneinander.

Zeitlimit

Jeder Aufruf hat ein festes Zeitlimit von 30 Sekunden. Wird es überschritten, meldet der Aufrufer einen Fehler (Aufrufstatus Timeout) und der Unterablauf wird abgebrochen, bevor der nächste Aufruf dieselbe Kopie verwenden darf. Reagiert ein Schritt des Unterablaufs nicht auf den Abbruch, wartet der OPC Router eine Nachfrist von 5 Sekunden, gibt die Kopie anschließend frei und schreibt eine Warnung ins Protokoll.

Bei verschachtelten Aufrufen teilen sich alle Ebenen das Zeitbudget des äußersten Aufrufers: Ein innerer Aufruf kann nicht länger dauern, als der äußere noch Zeit hat. Lang laufende Verarbeitungen gehören deshalb in einen eigenen Flow, nicht in einen Unterablauf.

Fehlerverhalten

Was ein Fehler im Unterablauf für den Haupt-Flow bedeutet, hängt vom Aufrufer ab:

Aufrufer	Fehler im Unterablauf bedeutet …
Bedingung (IF)	Der Transfer des Haupt-Flows schlägt fehl. Die Statusdetails nennen Zweig, fehlgeschlagenen Schritt und Fehlermeldung.
Fehlerbehandlung (Try/Catch)	Der TRY-Zweig wird ggf. wiederholt, danach läuft CATCH. Hat CATCH den Fehler behandelt (oder gibt es keinen CATCH-Zweig), bleibt der Haupt-Flow erfolgreich. Nur ein Fehler im CATCH-Zweig lässt den Transfer fehlschlagen.
Change Gate	Der Transfer des Haupt-Flows schlägt fehl.
Funktion (FX)	Der Transfer des Haupt-Flows schlägt fehl; die Meldung nennt Funktion und Grund.

Die Fehlerbehandlung (Try/Catch) ist damit das Mittel, Fehler aus Unterabläufen – auch aus Funktionsaufrufen und Bedingungen im TRY-Zweig – abzufangen, statt den gesamten Flow abbrechen zu lassen.

Aufrufstatus

Jeder Aufruf endet mit einem Aufrufstatus, der in den Transferdetails des Aufrufers angezeigt wird:

Status	Bedeutung
Ok	Der Unterablauf wurde erfolgreich ausgeführt.
Skipped	Kein Unterablauf ausgeführt (Bedingung falsch ohne ELSE, Gate geschlossen, nicht ausgewählter Zweig). Kein Fehler.
Failed	Der Unterablauf endete mit einem Fehler.
Timeout	Das Zeitlimit wurde überschritten; der Unterablauf wurde abgebrochen.
Rejected	Der Aufruf wurde nicht angenommen – etwa weil die Ausführungskopie nicht veröffentlicht ist, die maximale Aufruftiefe überschritten wäre oder ein Ringverweis erkannt wurde.
ConnectionNotReady	Der Unterablauf ist nicht bereit, z. B. weil eine benötigte Plug-in-Anbindung deaktiviert ist oder noch keine Verbindung hat.

Ein Flow gilt erst als bereit, wenn auch die Plug-ins seiner Unterabläufe bereit sind. Über die Experten-Einstellung Ausführung erlauben, wenn Subflow-PlugIns nicht bereit sind in den Flow-Einstellungen des Haupt-Flows lässt sich diese Prüfung für einzelne Flows abschalten – etwa wenn ein selten durchlaufener ELSE-Zweig ein Plug-in nutzt, dessen Ausfall den Haupt-Flow nicht blockieren soll.

Deaktivierte und nicht veröffentlichte Flows

Eine Ausführungskopie ist genau dann aktiv, wenn ihr aufrufender Flow aktiv ist; ein deaktivierter Flow deaktiviert auch alle seine Unterabläufe. Wird ein Aufrufer ausgeführt, dessen Kopie noch nicht veröffentlicht ist (z. B. eine neu hinzugefügte Funktion vor dem nächsten Veröffentlichen), endet der Aufruf mit einem Fehler, der zum Veröffentlichen des Flows auffordert.

Status und Diagnose

Unterabläufe erscheinen nicht als eigene Einträge im Status-Baum; stattdessen trägt der aufrufende Flow ein Badge, sobald einer seiner Unterabläufe Fehler oder Abbrüche meldet. Die Transferdetails des Aufrufers zeigen Aufrufstatus, ausgeführten Zweig, Dauer, Rückgabewerte und Fehlermeldung; über die Aktionsleiste des Aufrufer-Knotens öffnen Sie das Status-Diagramm des Unterablaufs als zusätzlichen Reiter – auch verschachtelt. Details unter Veröffentlichen und Status.

Kopieren, Exportieren, Importieren und Löschen

Weil Zweige privat und Funktionen wiederverwendbar sind, verhalten sie sich bei diesen Aktionen unterschiedlich:

Aktion	Zweige (IF, Try/Catch, Change Gate)	Funktion (FX)
Aufrufer kopieren/einfügen (Zwischenablage)	Die Kopie erhält keine Zweige und teilt niemals die Zweige des Originals – legen Sie die Zweige neu an.	Die Aufrufstelle verweist weiter auf dieselbe Definition. Beim Einfügen in ein anderes Projekt wird die Definition nicht mitkopiert – nutzen Sie dafür den Datei-Export.
Flow duplizieren	Die Zweige werden mit Inhalt kopiert und mit dem neuen Flow verknüpft.	Die Aufrufstellen verweisen weiter auf dieselbe Definition.
Flow umbenennen / verschieben	Die Zweige folgen dem Flow.	Keine Auswirkung auf die Definition.
Flow exportieren (Datei)	Die Zweige werden mit exportiert.	Die referenzierten Definitionen werden mit exportiert.
Flow importieren	Die Zweige werden mit importiert und neu verknüpft.	Die Definitionen werden mit importiert; Aufrufstellen bleiben zugeordnet. Existiert die Definition bereits, wird sie je nach Import-Option überschrieben oder als umbenannte Kopie angelegt, auf die die importierten Aufrufstellen verweisen (siehe Export und Import).
Aufrufer löschen	Die Zweige werden gelöscht.	Die Aufrufstelle wird gelöscht, die Definition bleibt bestehen.
Flow löschen	Die Zweige werden vollständig mitgelöscht, einschließlich verschachtelter Zweige.	Die Definition bleibt bestehen.
Definition löschen	–	Nur möglich, wenn keine Aufrufstelle mehr auf sie verweist.
Vorlage aus Flow erstellen / Instanz erstellen	Die Zweige werden Teil der Vorlage; jede Instanz erhält beim Veröffentlichen eigene Ausführungskopien mit ihren Variablenwerten.	Aufrufstellen verweisen weiter auf dieselbe Definition.

Bereits veröffentlichte Ausführungskopien werden von keiner dieser Aktionen unmittelbar berührt. Die Laufzeit übernimmt Änderungen erst mit dem nächsten Veröffentlichen des jeweiligen Flows – einschließlich des Aufräumens nicht mehr verwendeter Kopien.

Empfehlungen für den Einsatz

• Klein und benannt. Halten Sie Unterabläufe überschaubar und geben Sie Zweigen über den Kommentar im Banner einen sprechenden Zweck.
• Kontrakt bewusst wählen. Übergeben Sie nur, was der Unterablauf wirklich braucht. Konfigurationsunterschiede zwischen Aufrufstellen (Anlage, Tabelle, Anbindung) gehören in Scope-Variablen, nicht in den Kontrakt.
• Statisch, wo möglich. Statische Variablenwerte werden beim Veröffentlichen eingesetzt und kosten zur Laufzeit nichts. Verdrahten Sie eine Variable nur, wenn sich ihr Wert von Aufruf zu Aufruf ändert.
• Standardwerte setzen, wenn der Haupt-Flow auch ohne ausgeführten Unterablauf sinnvoll weiterarbeiten soll (Bedingung falsch, Gate geschlossen, TRY fehlgeschlagen).
• Fehler gezielt abfangen. Legen Sie fehleranfällige Schritte – Datenbank, Webservice, Dateizugriff – in den TRY-Zweig einer Fehlerbehandlung und protokollieren Sie im CATCH-Zweig CatchError und CatchFailedTransferObject. Aktivieren Sie die Wiederholung nur für Schritte, die mehrfach ausgeführt unschädlich sind.
• Zeitlimit im Blick. Ein Unterablauf muss innerhalb von 30 Sekunden abgeschlossen sein.
• Nach Funktionsänderungen alle Aufrufer veröffentlichen. Erst das Veröffentlichen der betroffenen Flows macht die neue Fassung überall wirksam.
• Keine Unterabläufe in dynamischen Vorlagen-Instanzen. Dynamische Instanzen erhalten keine Ausführungskopien.

Glossar

Begriff	Bedeutung
Unterablauf (Subflow, Sub-Flow)	Eigenständiger Flow ohne Trigger, der ausschließlich von einem Aufrufer gestartet wird.
Aufrufer	Transferobjekt im Haupt-Flow, das einen Unterablauf startet: Bedingung (IF), Fehlerbehandlung (Try/Catch), Change Gate, Funktion (FX).
Zweig	Privater Unterablauf, der genau einem Aufrufer gehört (THEN, ELSE, TRY, CATCH, ON OPEN).
Funktion (FX), Funktionsbaustein (FB)	Wiederverwendbarer Unterablauf mit eigener Definition in der Vorlagen-Oberfläche, aufrufbar aus beliebig vielen Flows.
Funktions-Definition	Der bearbeitbare Ablauf einer Funktion samt Kontrakt und Variablen.
Aufrufstelle	Ein Funktion (FX)-Transferobjekt, das eine Definition verwendet.
Kontrakt	Die deklarierten Eingänge und Ausgänge eines Unterablaufs mit Name und Datentyp.
Scope-Eingang, Scope-Rückgabe (Scope-Brücken)	Feste Transferobjekte am Anfang und Ende jedes Unterablaufs, die die Kontrakt-Werte hinein- bzw. herausreichen.
Scope-Variable	Platzhalter {Name} in den Eigenschaften der Unterablauf-Transferobjekte, belegt statisch (beim Veröffentlichen) oder verdrahtet (pro Aufruf).
Ausführungskopie	Die beim Veröffentlichen je Verwendung erzeugte, versteckte Laufzeitfassung eines Unterablaufs. Nur sie wird ausgeführt.
Aufrufstatus	Ergebnis eines Aufrufs: Ok, Skipped, Failed, Timeout, Rejected, ConnectionNotReady.
Maximale Aufruftiefe	Experten-Einstellung, die die Verschachtelungstiefe von Aufrufen begrenzt (Standard 16).