Ich habe mehrere Themen, wo die Warteschlange relevant wäre. Hier zwei Beispiele:
- 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!
- 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