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
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 
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:
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
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:
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.
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
