Hi,
wir haben ja unsere komplette Auftragsverarbeitung (zwischen Zahlungseingang und Picken) von Plentymarkets zu euch ausgelagert. Das ist komplex & vielschichtig, läuft aber seit >2 Jahren super stabil.
Muss es auch, denn wenn das steht, kommt nichts zum picken. Dann müssen die Versand-Kollegen heim geschickt werden. Und das ist am Samstag passiert
Konkret im Flow SH_5.080_getWarenpost, der Aufträge aus besagtem Status abholt, und weiterschiebt. Am Ende wird per FlowTrigger der nächste Flow angestoßen, der wiederum diese Aufträge weiter verarbeitet. Und so weiter. Wenn ein Flow steht, stehen alle.
Der genannte Flow hat üblicherweise (wenn er kontinuierlich alle 15 Minuten läuft) eine Laufzeit von etwa 30 bis 90 Sekunden.
Samstag früh um 01:32 wurde ein Run getriggert, der über 11 Stunden hing, bis ich ihn dann gestoppt habe:
Und gelahmt hat auch nicht die API (zu Plenty), sondern ein Spreadsheetmapper:
Was war da genau los?
Der langsame Step gruppiert Aufträge (mit Positionen) nach OrderID (also ohne Positionen). Nichts anspruchsvolles. Ich war wohl da letzte Woche am Code, aber egtl nur 2-3 Spalten zugefügt. Gefühlt liegts nicht daran.
In der zweiten Meldung steht ja was von System Maintenance und Server Restart. Hat sichs vllt dadurch gefixt? Weshalb war denn der Restart, könnte das thematisch passen?
Na klar. Mail hab ich keine, aber ich habs als Ticket geschickt. Hängender Step ist L2
Andere Idee noch: ich hatte letzte Woche von einem API-Nutzer auf mehrere umgestellt. Also alle Plentymarkets, alle das selbe System/Host, alle die selben Rechte/Rolle. Nur, um auf Plenty-Seite simpler sehen zu können, welcher Flow für eine Änderung verantwortlich ist.
Da es nicht auf den API-Steps lahmt, schließe ich das eher aus, aber ich wills nicht unerwähnt lassen. Ganz generell: ist euer RateLimiter auf Multiuser eingestellt, und beachtet entsprechend globale Limits, die er sich mit zeitgleich laufenden Flows (aus anderen Nutzern) teilt?
@samenhaus-admin Wie meinst du das genau? Wenn du mehrere Plenty Rest Api User hast, die in unterschiedlichen Flows laufen, aber auf das gleiche Plenty System zugreifen?
Genau. Ich seh in Plenty in der Änderungshistory nur den Benutzer, aber nicht den User-Agent (mit Flow-ID) den ihr mitschickt.
Also hab ich meine Flows auf ~10 verschiedene Nutzer verteilt
Selbes System/Endpoint, selbe Rechte, nur eben verschiedene Credentials.
Weiß ja nicht wie ihr den Limiter implementiert habt (oder Plenty die Meldung der verbleibenden Calls long/short im Response). Gefühlt sollte das passen, will nur keine unangenehmen Überraschungen erleben falls nicht Grade ist unsere Last noch im Rahmen, aber im Frühjahr ist wieder Hauptsaison… Da werden wir öfter mal die Limits ausreizen vermutlich.
Wenn ihr keine Erfahrungswerte habt, warten wirs ab. Wollte nur fragen ob.
wir verwenden für den rate limiter aktuell nur den X-Plenty-Global-Short-Period Wert aus der plenty response. Wenn ich die plenty Doku richtig interpretiere (und die Dokumentation aktuell und korrekt ist), dann sollte es ein User spezifisches Limit sein. D.h. wenn du 10 verschiedene User verwendest, dann sollten z.B. bei plenty „Basic“ 800 lesende und 400 schreibende Calls / min. möglich sein.
Das X-Plenty-Global-Long-Period ist dann ein System Limit (globales Limit für alle User / Calls pro 24h). Diesen Wert berücksichtigen wir nicht im rate limiter. Die Steps brechen allerdings mit Fehler ab, wenn wir ein Long-Period-Limit Fehler in der Response erhalten.
Ich hoffe, dass dir die Erklärung etwas weiter hilft.
