Zum Hauptinhalt springen

Wie ein Flow ausgeführt wird

Ein Flow beschreibt, welche Daten unter welcher Bedingung von wo nach wo verschoben werden. Diese Seite beschreibt, was die Laufzeit daraus macht: in welcher Reihenfolge die Transferobjekte abgearbeitet werden, wie viele Flows gleichzeitig laufen und was bei einem Fehler mit dem Rest des Flows geschieht.

Die Reihenfolge entsteht beim Projektieren​

Die Reihenfolge der Transferschritte legen Sie nicht von Hand fest – der OPC Router berechnet sie aus den Item Links des Flows:

  • Ein Transferobjekt bekommt seine Schrittnummer erst, wenn alle Transferobjekte nummeriert sind, aus denen ein Item Link in dieses Objekt führt. Ein Objekt läuft also nie vor den Objekten, die es mit Werten versorgen.
  • Verzweigt der Flow, können mehrere Objekte gleichzeitig an der Reihe sein. Dann entscheidet ihre senkrechte Anordnung auf der Projektierungsfläche: Das weiter oben liegende Objekt läuft zuerst. Ordnen Sie die Objekte entsprechend an, wenn Ihnen die Reihenfolge wichtig ist.

Welchem Schritt ein Item Link angehört, sehen Sie beim Überstreichen mit der Maus. Die berechnete Reihenfolge gehört zur Projektierung und gelangt mit dem Veröffentlichen in die Laufzeit; zur Laufzeit wird sie nicht neu entschieden.

Ein Transfer, ein Worker-Thread, ein Schritt nach dem anderen​

Ein laufender Transfer belegt genau einen der Worker-Threads, die der OPC Router für Transfers bereithält, und arbeitet die Transferschritte streng nacheinander ab. Innerhalb eines Flows gibt es keine parallelen Zweige:

  • Verzweigt der Flow, werden die Zweige nacheinander abgearbeitet, nicht gleichzeitig.
  • Laufen mehrere Zweige wieder zusammen, ist das zusammenführende Objekt erst an der Reihe, wenn alle seine Vorgänger abgearbeitet sind.

Ein langsamer Schritt verzögert deshalb den gesamten Rest des Flows. Gleichzeitigkeit erreichen Sie über mehrere Flows, nicht über die Anordnung innerhalb eines Flows.

Je Trigger läuft nur ein Transfer gleichzeitig​

Ein Trigger startet immer nur einen Transfer gleichzeitig: Erst wenn sein Transfer abgeschlossen ist, kann derselbe Trigger den nächsten auslösen.

In einem laufenden Transfer werden die Transferobjekte der Trigger übersprungen, die diesen Transfer nicht ausgelöst haben. Ob ein einzelner Trigger genügt oder alle auslösen müssen, legt die Trigger-Verknüpfung fest, siehe Einstellungen für Flows und Vorlagen.

Was bei einem Fehler passiert​

Der Rest des Transfers wird abgebrochen​

Schlägt ein Transferschritt fehl, führt der OPC Router die restlichen Schritte dieses Transfers nicht mehr aus. Der Abschluss läuft trotzdem über alle Transferobjekte des Flows – auch über die, die gar nicht mehr an der Reihe waren. So bleibt kein Trigger in seinem ausgelösten Zustand hängen und der nächste Transfer kann starten.

Der abgebrochene Transfer wird nicht wiederholt. Der Flow selbst bleibt bereit: Die nächste Auslösung startet einen neuen Transfer, wieder beim ersten Schritt.

Einen Teil des Flows gegen Fehler absichern​

Soll ein Teil des Flows einen Fehler überstehen, klammern Sie ihn mit dem Fehlerbehandlung (Try/Catch)-Transferobjekt ein. Der abzusichernde Teil liegt in dessen TRY-Zweig und wird auf Wunsch mehrfach versucht; den endgültigen Fehlschlag übernimmt ein optionaler CATCH-Zweig mit den Fehlerinformationen. Ein so behandelter Fehler bricht den Transfer nicht ab – ebenso wenig einer, den das Transferobjekt ohne CATCH-Zweig verschluckt.

Wenn das Zielsystem ausgefallen ist​

Ein Fehler, der nur daher rührt, dass die Gegenstelle vorübergehend nicht erreichbar ist, muss die Daten nicht kosten: Mit Store and Forward speichert der OPC Router sie zwischen und reicht sie nach, sobald die Übertragung wieder möglich ist. Store and Forward wird global und zusätzlich je Flow eingeschaltet, siehe Einstellungen für Flows und Vorlagen.

Dem Fehler nachgehen​

Der fehlgeschlagene Transfer erscheint im Flow-Status als roter Transferpunkt; zeigen Sie im Flow auf das fehlerhafte Transferobjekt, nennt der OPC Router die Einzelheiten dazu. Der Flow-Knoten im Statusbaum trägt daneben den zuletzt gemeldeten Zustand als farbigen Punkt – welche Farbe welchen Zustand meint, steht unter Farben im Statusbaum. Was der OPC Router darüber hinaus aufgezeichnet hat, steht im Ereignisprotokoll und in den Logdateien.

Unterabläufe und Wiederholungen belegen denselben Worker-Thread​

Ein aufgerufener Unterablauf – ein Zweig oder eine Funktion (FX) – läuft nicht auf einem eigenen Thread, sondern innerhalb des laufenden Transfers auf demselben Worker-Thread. Der Aufrufer wartet, bis der Unterablauf fertig ist. Wie tief Aufrufe ineinander geschachtelt sein dürfen, begrenzt die maximale Aufruftiefe für Unterabläufe mit dem Standardwert 16.

Das Fehlerbehandlung (Try/Catch)-Transferobjekt ist keine Klammer um den eigenen Flow, sondern der Aufrufer zweier solcher Unterabläufe: des TRY-Zweigs und des optionalen CATCH-Zweigs. Ist die Wiederholung eingeschaltet, wartet der Transfer an diesem Objekt, bis alle Versuche einschließlich ihrer Wartezeiten abgeschlossen sind – so lange bleibt der Worker-Thread belegt. Prüfen Sie deshalb bei eingeschalteter Wiederholung, ob die längstmögliche Summe aus Versuchen und Wartezeiten noch in das Flow-Timeout passt.

Wie viele Flows gleichzeitig laufen​

Der OPC Router hält standardmäßig 80 Worker-Threads für Transfers bereit, dazu 5 weitere, die für Flows mit hoher Priorität reserviert sind. Sind alle belegt, warten weitere ausgelöste Transfers in einer Warteschlange; es gibt eine Warteschlange je Flow-Priorität.

  • Die 80 allgemeinen Worker-Threads bedienen zuerst die hohe, dann die normale, dann die niedrige Priorität.
  • Die 5 reservierten Worker-Threads bedienen ausschließlich die hohe Priorität.

Ein laufender Transfer wird dabei nie unterbrochen. Eine höhere Priorität verschafft einem Flow den Vorrang in der Warteschlange und – bei hoher Priorität – zusätzliche Worker-Threads; sie verdrängt keinen bereits laufenden Transfer. Überlast heißt deshalb: Das ausgelöste Ereignis wartet, bis ein Worker-Thread frei wird.

Wie viele Transfer-Anforderungen nicht sofort verarbeitet werden konnten, zeigt die Karte Systemlast im Dienststatus – wahlweise für die allgemeinen oder für die hochpriorisierten Worker.

Das Flow-Timeout begrenzt die Belegung​

Weil ein laufender Transfer nicht verdrängt wird, begrenzt der OPC Router stattdessen seine Laufzeit: Jeder Flow hat ein Flow-Timeout, ohne eigene Angabe sind das 300 Sekunden. Sobald nur noch 15 % der erlaubten Laufzeit übrig sind, meldet der OPC Router eine Vorwarnung.

Vergeben Sie ein eigenes Flow-Timeout für Flows, die absehbar länger dauern – etwa weil sie große Abfrageergebnisse verarbeiten oder mit Wiederholungen arbeiten.

Einen Flow von Hand auslösen​

Sie müssen für einen Testlauf nicht auf einen Trigger warten: Im Statusbaum der Statusanzeige klicken Sie mit der rechten Maustaste auf den Flow und wählen „Flow auslösen“. Der Flow braucht dafür keinen Trigger. Wie diese Transfers im Statuschart erscheinen und was zusätzlich aufgezeichnet wird, steht unter Flow-Status.