Ok, noch mal zu unserer initialen Idee, um eine Feinheit ergänzt:
Es gibt die Möglichkeit der Trigger-URL noch einen Parameter delayMinutes mitzugegeben (siehe bei Optionale Parameter)
delayMinutes: Über diesen Parameter kann die Startzeit des Flows gesteuert werden. Mit dem Parameter kann die Anzahl Minuten zwischen Aufruf der URL und Ausführungszeitpunkt des Flows angeben werden (Default: 0, Min: 0, Max: 1440).
Beispiel URL: https://apps.synesty.com/studio/api/flow/v1?id=websiteabrufen&t=123&host=google.de&delayMinutes=5 (startet den Flow 5 Minuten nach Aufruf der URL)
Angenommen du stellst diesen Delay auf 1 Minute, dann müsste das unserer Meinung nach folgendes bewirken (immer noch das 50 Aufträge Beispiel, die auf einen Schlag kommen):
1. plenty versucht 50x mal diese URL (mit delayMinutes) aufzurufen.
Aber nur der 1. Aufruf schafft es durch. Die anderen 49 werden abgelehnt.
2. dieser 1. Aufruf triggered den Flow an, aber er startet erst in 1 Minute in der Zukunft. Dieses delay wäre dafür hilfreich, damit du sicher stellst, dass auch wirklich gewartet wird, bis alle 50 Aufträge im Hintergrund von plenty in den entsprechenden Status geschoben wurden.
3. Der Flow läuft dann in 1 Minute los und holt Auftrage im von dir bestimmten Status (nicht per OrderID!!!). Damit sollten 50 Aufträge (oder mehr) abgeholt werden.
Dann macht der Flow damit irgendwas.
Mit anderen Worten:
Du machst dir den Effekt zunutze, dass von 50x gleichzeitigen URL-Trigger-Aufrufen nur der erste Aufruf den Flow antriggert. Die Idee ist, den Flow so zu bauen, dass diese eine einzige Ausführung trotzdem alle 50 Aufträge verarbeitet. Durch den delay baust du dir einen kleinen Warte-Puffer ein.