Feststellen, ob ein FlowExecute erfolgreich gestartet ist

Hallo zusammen,

ich möchte innerhalb eines Flows darauf reagieren, ob in einem vorheriger FlowExecute-Step der Flow erfolgreich gestartet wurde. Es soll eine Mail verschickt werden, wenn der FlowExecute den auszuführenden Flow nicht starten konnte, weil dieser schon lief.

Gibt es die Chance, dass ihr einen Output-Parameter dafür ergänzt z.B. ein Boolean-Parameter „FlowStartedSuccessfully“?

Gruß
Gustav

Du meinst vermutlich den FlowTrigger oder?

Wir prüfen das.

Im Grunde ging es mir um beide Steps, aber beim FlowTrigger kam ich schon selbst zu dem Schluss, dass das nicht möglich sei. Der läuft ja mitunter erst zeitversetzt. Deshalb kann man nicht wirklich sicherstellen, dass der Status zum Zeitpunkt der Abfrage durch den übergeordneten Flow überhaupt schon bekannt ist. Das war zumindest meine Verständnis.

Ich glaube, das Thema hat sich fast erledigt. Ich hatte grade mal mit den FlowExecuting-Steps getestet und konnte darüber einen Flow ausführen, obwohl der schon lief. War das schon immer möglich, den Flow darüber zeitgleich laufen zu lassen? Ich hatte das eigentlich anders im Kopf, aber vielleicht verwechsel ich jetzt auch wirklich den Step mit dem FlowTrigger. Damit hat sich mein eigentliche Sorge im Grunde erledigt.

Korrekt. Aber hier wäre so eine zusätzliche Ausgabevariable dahingehend sinnvoll für den Fall ohne Zeitverzögerung. Da kann es nämlich auch zum Fehler kommen, wenn der Flow gerade läuft. Seit einigen Wochen kann man über Option „flowAlreadyRunning“ steuern, wie ob der Flow abbrechen soll oder nicht.

Denkst du, dass eine zusätzliche Ausgabevariable für dich trotzdem noch beim FlowTrigger sinnvoll wäre?

Ja.

Flows | Synesty Docs : Der FlowExecutingStep führt den anderen aufzurufenden Flow direkt aus (synchron, d.h. so, als ob die Steps des aufzurufenden Flows direkt selbst Teil des aktuellen Flows wären).

Wenn ihr das bei einer Ausführung ohne Zeitverzögerung sicherstellen könnt, dass der Flow erst nach erfolgreichem/gescheiterten FlowTrigger weiterläuft, fände ich das durchaus interessant. Dann kann man weitere FlowTrigger zu einem späteren Punkt im Flow als Fallback einbauen.

Jetzt bin ich verwirrt :slight_smile: Könntest du das noch mal anders formulieren oder mit Beispiel?
Ich verstehe nicht was das Wort „sicherstellen“ hier zu suchen hat.

Aktuell ist es so:

Fall 1 (default Verhalten … Fehler wenn Flow schon läuft)

  • A-FlowTrigger(B)
    • B läuft schon: Fehler, Flow bicht ab (es sei denn man stellt ein, dass der Flow weiterlaufen soll)

Fall 1a (Flow soll weiterlaufen, auch wenn FlowB schon läuft)

  • A-FlowTrigger(B)
    • B läuft schon: Fehler, aber Flow A läuft weiter.

Fall 2

  • A-FlowTrigger(B)
    • B läuft nicht: Flow B wird angetriggert (sofort oder mit Zeitverzögerung)… startet dann irgendwann in der Zukunft, je nach dem was gerade so los ist. Selbst ein „sofort“ kann eine Zeitverzögerung je nach Queue / Serverlast haben.
    • Flow A läuft weiter. Da Flow B asynchron (parallel) angestartet wurde, kann es sogar sein, dass Flow A vor FlowB fertig ist.

Ich hatte gedacht, der Flow könnte möglicherweise schon weiterlaufen und nachfolgende Schritt ausführen, bevor der FlowTrigger-Step zurückmeldet, dass der zu triggernde Flow schon läuft. Aber wenn der FlowTrigger den weiteren Ablauf des Flows blockiert, bis er eine Antwort vom „'FlowRunScheduler“ hat, dann ist alles ok.


Das viel viel coolere Feature wäre natürlich, wenn der FlowTrigger seine Ausführung auch in eine Warteschlange werfen könnte und einfach zum nächstmöglichen Zeitpunkt startet. Dann muss man sich mit dem „flowAlreadyRunning“-Fehler garnicht mehr beschäftigen. Ihr spielt nicht zufällig mit dem Gedanken, sowas irgendwann mal umzusetzen, oder?

Genau so ist das. Der FlowA kann sehen, ob es gerade eine laufende Instanz vom anzutriggernden FlowB gibt.

Es kann immer nur eine Instanz eines Flows gleichzeitig ausgeführt werden.

Vielleicht kannst du mal etwas weiter deine Usecases ausführen. Ich kann mir zwar schon vorstellen, in welche Richtung das geht, aber wäre nicht gut das auf Annahmen zu machen :slight_smile:

Also vielleicht als konkrete Zusatzfrage: Aus welchem Grund willst du einen Flow nochmal ein die Warteschlange packen, obwohl der gerade läuft?

Ich habe mehrere Themen, wo die Warteschlange relevant wäre. Hier zwei Beispiele:


  1. Beispiel
    Das Beispiel hatte ich auch am vergangenen Donnerstag schonmal erwähnt im Kontext der neuen Laufzeitbeschränkunen. Wir erstellen in einem Flow einen XML für ein einzelnes Kapitel unseres Katalog. Zur Generierung aller Kapitel habe ich einen weiteren Flow, der über knapp 20 FlowExecute jeweils nacheinander die einzelnen Kapitel generiert. Jeder Flowrun dauert zwischen 5-30 Minuten und damit läuft der Flow mit den ganzen Aufrufen deutlich länger als eine Stunde. Diesen Flow und die damit gewonnene QOL müssten wir aufgeben, wenn wir auf neue Kontigentmodell umsteigen.
    Im Moment benutze ich dort FlowExecute-Steps, weil es anders eben nicht geht. Aber eigentlich würden dort FlowTrigger vollkommen ausreichen und sind m.M.n. auch eigentlich der richtige Step.
    Der Flowautomatisierung mit Variablen-Thread von gestern läuft ja auf dasselbe Thema hinaus. Hier ist zwar das Problem, dass der FlowExecute-Step nicht verfügbar ist. Aber es sollen nicht Flow mit dynamischen und komplexen Input- und Outputdaten aufgerufen werden, der eigentliche Nutzen des FlowExecute-Steps ist hier ja garnicht notwendig!

  1. Beispiel
    Für einen Kunden frage ich Daten aus drei Shopify-Systemen ab, konfigurierbar per Variable. Der Flow soll pro System einmal laufen. Da mir bei dem Kunden auch der FlowExecute-Step fehlt, wäre meine Lösung 3 Flows, die zu unterschiedlichen Zeiten den Flow per FlowTrigger starten. Da es keine Warteschlange gibt, muss ich mir den Zeitversatz eben selbst einbauen.

Bei dem Thema fallen mir auch immer die URL-Trigger ein. Ich habe immer gewisse Sorgen, Webhooks aus anderen Systemen per URL-Trigger zu integrieren. Dort kann es ja auch häufiger zum „Flow läuft schon“-Fehler kommen. Trotzdessen sicherzustellen, dass der Webhook sauber läuft und keine Ausführung verschluckt wird, ist eigentlich unmöglich. Zum Beispiel deaktiviert Shopify konfigurierte Webhooks einfach, wenn diese für eine Anfrage 20-mal fehlschlagen.
Auch hier kann eine Warteschlange Abhilfe schaffen, falls man einmal eine solche Lösung umgesetzt hat.


Zweck der Sache ist doch, dass man kleinen gekapselte Prozesse in einem Flow packt und an vielen Stellen benutzen kann. Dabei macht man sich grundsätzlich keine Gedanken darüber oder muss Sorge dafür tragen, dass dieser Prozess zu keinem Zeitpunkt mehrfach laufen soll. Ich erwarte da eigentlich intuitiv irgendeine Lösung, die das regelt.

In der Beschreibung vom FlowTrigger sagt ihr, dass der Flow asynchron gestartet wird. Also kann man als Anwender damit leben und erwartet eigentlich auch, dass der Flow nicht unbedingt direkt gestartet wird, sondern baldmöglich in der näheren Zukunft. Zeitgleich „verbietet“ ihr aber, dass über den selben Prozess der Flow ein zweites Mal in der etwas weiter entfernten Zukunft gestartet werden soll. Die eigentliche Anwendung à la „Bitte starte demnächst den Flow A mit dem Parameter X“ ist damit eigentlich unmöglich. Im Grunde ist der FlowTrigger nur eine schlechtere Variante des FlowExecutes.

Ihr bezeichnet es ja sogar als Warteschlage in der Beschreibung des FlowTrigger, meint damit aber vermutlich euren internen Scheduler. Eine wirkliche Warteschlange ist das ja nicht, wenn man einen Flow nur einmal darin platzieren kann.

Gruß
Gustav

Hallo @digitalslvde-gustavf ,
danke für deine umfangreiches Feedback. Wir werden das intern diskutieren und schauen, was wir machen können.

Hallo @gustavfriedeheim ,

danke für deine Geduld. Hier mal das Ergebnis unserer ersten internen Diskussion.

  • die Doku ist dahingehend nicht korrekt - passen wir an.
  • das Thema Queuing werden wir in Zukunft angehen, aber mit hoher Sicherheit nicht bei den Flows, sondern vermutlich im Bereich Datastore. D.h. die heutigen Mechanismen von FlowTrigger / URLTrigger bleiben unverändert.
  • d.h. wir stellen uns vor, dass man Datastores als „Queue“ benutzen kann, deren (batch-mäßige) Abarbeitung durch Flows realisiert werden kann. Es wird dann Wege geben um diese „Datastore-Queue“ zu befüllen (z.B. aus Flows heraus oder per URLTrigger-ähnlichem Mechanismus).

Das sind bisher eher lose Gedanken und keine Zusagen. Wir verstehen aber den Wunsch und Bedarf. Allerdings haben wir immer das Thema Skalierbarkeit im Hintergrund und bei Flows laufen wir da an verschiedene Grenzen.

Sobald wir Luft für das Thema haben, melden wir uns wieder.

Hallo @synesty-Sales,

da bin ich sehr gespannt, was dabei rauskommt. Für die Webhook-Thematik hört sich das nach einer guten Lösung an.

Bitte vergesst aber nicht die Problematik aus meinem ersten Beispiel. Vielleicht lässt sich das ja auch einfach über die angedachte Lösung abbilden, das kann ich grade nicht absehen. Ich fänd’s nur sehr schade, wenn dort durch das Fortbestehen der Queue-Beschränkung in Kombination mit der Flow-Laufzeitlimitierung aus dem neuen Kontigentmodell die Komplexität und der Aufwand in der Umsetzung steigt.
Im Moment fällt mir nur eine Lösung ein, um meinen Flow mit 17 FlowExecute mit der Laufzeit-Beschränkungen auszuführen. Dafür müsste ich 17 Flows mit jeweils einem FlowExecute erstellen, die ich dann alle über einen Flow per FlowTrigger starten kann.
Dass das unübersichtlicher ist als ein Flow mit X FlowExecute, ist wohl klar.

Gruß
Gustav