Wir rufen bei einem Flow zum Export von Aufträgen von Plentymarkets eine Flow-URL auf, um eine REST-Schnittstelle anzusprechen, aus der dann eine csv-Datei erzeug und auf einen ftp-Server geladen wird.
In den vergangenen Monaten kam es dabei immer wieder mal vereinzelt zu dem Fehler, dass kein Ergebnis von der Flowrun-Trigger URL zurück kam, bzw. die URL nicht aufgerufen werden konnte.
Seit gestern scheint das Problem dauerhaft zu sein.
Laut Flowlog sieht es für mich so aus, als würde der Flow trotzdem ausgeführt, das hilft uns aber nicht so recht weiter, weil in unserem Prozess der http-Client-Step mit Fehler abbricht und nachfolgende Schritte nicht mehr ausgeführt werden.
Es geht um den Flow Plenty7 Auftragsexport
Wie kann das Problem gelöst werden?
Es gab schon mal einen ähnlichen Fehler, der damals nicht gelöst wurde, weil er nicht mehr auftrat: https://support.synesty.com/support/discussions/topics/11000030923
Danke
Holzhauer
Hallo Herr Holzhauer,
am Flow URL Trigger wurde die letzten Monate nichts gerändert. Wenn der Flow erfolgreich startet und durchläuft, scheint der Aufruf der URL mit ihrem Client zu funktionieren. Erhalten sie denn eine Fehlermeldung von ihrem Client und können uns ggf. die Fehlermeldung oder Logs (gerne per Ticket) bereit stellen ?
Als Test können sie auch die Trigger URL in ihrem Browser öffnen und schauen was sie als Ergebnis erhalten. Es sollte in etwa wie im folgenden Screenshot aussehen:
Viele Grüße
Torsten Felsch
Hallo Herr felsch,
wir haben an unserem Prozess ebenfalls seit Monaten nichts geändert.
Das Problem muss dringend gelöst werden, da bei Auftreten des fehler keine zeitkritischen Auftragsimport möglich sind.
Der http-Client meldet, dass er von der Trigger-URL kein Ergebnis abrufen kann, da der Flow nicht erreichbar ist und somit auch keine Rückmeldung erhält, kann ich ihnen auch kein json-Ergebnis liefern. Für mich sieht es aus, als sei ihr Server manchmal nicht erreichbar; unser Client (Pentaho Data Integration) meldet heute um 6:30 und um 7:30:
2020/09/07 07:30:10 - HTTP client.0 - ERROR (version 5.0.1-stable, build 1 from 2013-11-15_16-08-58 by buildguy) : Because of an error, this step can't continue: 2020/09/07 07:30:10 - HTTP client.0 - Unable to get result from specified URL : https://apps.synesty.com/studio/api/flow/v1?id=$2a$10[obfusziert] 2020/09/07 07:30:10 - HTTP client.0 - Read timed out
Nachtrag:
Heute um 5:30 hat der Aufruf funktioniert, um 6:30 und 7:30 nicht.
Hallo Herr Holzhauer,
ich habe mir die 3 entsprechenden Einträge im Log angesehen. Es sieht so aus würde ihr Client nach 0,120 Sekunden die Verbindung beenden (HTTP Status 499).
0.064 sec [07/Sep/2020:05:30:05 +0200] "GET /studio/api/flow/v1?id=*** HTTP/1.1" 200
0.120 sec [07/Sep/2020:06:30:04 +0200] "GET /studio/api/flow/v1?id=*** HTTP/1.1" 499
0.120 sec [07/Sep/2020:07:30:10 +0200] "GET /studio/api/flow/v1?id=*** HTTP/1.1" 499
Versuchen sie bitte das Timeout des Clients etwas zu erhöhen.
Viele Grüße
Torsten Felsch
Ja, das ist korrekt, den Timeout haben wir implementiert, um überhaupt einen abbruch des prozesses erreichen zu können, bevor der eingebaut wurde, bleib der Prozess im http-Client Aufruf hängen und kam nie mehr daraus zurück. Erst seit des den Timeout gibt, bekommen wir überhaupt den "nicht erreichbar"-Fehler. Ohne den Timeout werden Flow-Aufruf-Step und der gesamte nachfolgende Prozess gar nicht mehr beendet und der bleibt "in der Luft hängen".
Für mich sieht es im Moment so aus, als würde der Flowaufruf via http-Trigger nur dann funktionieren, wenn bei PlentyMarkets auch tatsächlich Aufträge abgerufen werden können. Liegen dort keine vor, kommt auch keinerlei Rückmeldung vom Flow.
Aber das ist im Moment nur eine These.
Nachtrag:
120 Millisekunden war natürlich ein falscher Parameter, das sollten 120 Sekunden sein (habe ich soeben korrigiert). Das wird allerdings nichts ändern, denn ohne den Timeout passiert das oben Beschriebene.
Der Timeout soll nicht entfernt werden, sondern nur erhöht. Mit den 120 Sekunden (statt 120ms) sollten sie jetzt aber auf der sicheren Seite sein.
Der URL-Trigger hat zunächst nichts mit der Ausführung des Flows zu tun und ist unabhängig von Daten in Plentymarkets. Es wir 'nur' ein Flow Run erzeugt für den sie die Run ID in der Response erhalten. Die Zeit bis zur Response kann je nach Last etwas variieren. Ich würde vorschlagen, dass wir die nächsten URL Aufrufe abwarten und sie sich ggf. nochmal melden falls es noch Probleme gibt.
Ich denke nicht, dass die Erhöhung des Timeouts für eine Fehlerlösung zielführend ist.
Wenn der Fehler auftrat, kam auch nach mehreren Stunden kein Response von der URL und der Prozess musste abgeschossen werden. Ich gehe nicht davon aus, dass die Erhöhung des Timeouts das Problem tatsächlich löst, denn der Timeout wurde letztendlich nur implementiert, um überhaupt mal eine Fehlermeldung zu bekommen, statt eines unresponsiven Prozesses.
Warten wir es ab. Es hilft zumindest bei der weiteren Fehlersuche, wenn ihr Client nicht nach 120 ms abbricht.
Gestern gegen 15:45: Flowrun konnte nicht getriggert werden.
Nachtrag: Wie ich sehe wurde der Flow gegen 15:45 gestartet, hat allerdings unserem Client-Prozess keine Status-Rückmeldung geliefert, sondern diesen erneut in einen undefinierten Zustand versetzt.
Laut unserem Log wurde Status HTTP Code 200 + Response nach 0,06 Sekunden geliefert. Ich kann keinen Unterschied zu allen anderen Aufrufen ihres Clients von gestern erkennen. Bei allen Aufrufen von ihnen wurde HTTP Status 200 + Response (immer in gleicher Größe) ausgeliefert.
Der entsprechende Auszug von 15:45 Uhr aus unseren Log:
0.060 sec [08/Sep/2020:15:45:55 +0200] "GET /studio/api/flow/v1?id=*** HTTP/1.1" 200
Sie sagen, die Response wurde ausgeliefert, ich stelle fest, sie kommt bei uns nicht an. In diesem Fall hat noch nicht mal der Timeout von 120 Sekunden gegriffen, der http-Client-Step hat sich einfach aufgehängt. Da das mehrere Jahre problemlos funktioniert hat und am Prozess und der Software keine Änderungen durchgeführt wurden, hilft mir die Auskunft bei einer Lokalisierung des Fehlers eher nicht.
Wir würden ihnen ja gerne helfen, aber dazu müssen wir wissen warum sich ihr Client in einigen wenigen Fällen "aufhängt" und nicht mal mehr der Timeout greift.
Wenn keine Response von unserer Seite erfolgen würde, dann sollte ja auch der Timeout ihres Clients greifen und wir würden es am HTTP Status 499 erkennen (siehe Log bei Timeout von 120 ms).
Gestern 15:45: keine Rückmeldung vom Flow, http-Client erhält keine json-Rückmeldung vom Flow, auch der Timeout nutzt nichts, um den http-Client zu beenden, 120 Sekunden scheint deutlich zu lang zu sein. Hier kann ich im Backend sehen, dass der Flow durchgelaufen ist.
In anderen Posts sehe ich, dass Sie Probleme mit ihrem Serverbetreiber Hetzner haben und auch andere Nutzer Probleme mit der Flow-Ausführung haben. Ich würde eindeutig einen Zusammenhang sehen wollen.
"Gestern 15:45: keine Rückmeldung vom Flow, http-Client erhält keine json-Rückmeldung vom Flow, auch der Timeout nutzt nichts, um den http-Client zu beenden, 120 Sekunden scheint deutlich zu lang zu sein."
Wir haben das natürlich nochmal geprüft, aber können kein Problem erkennen: 0.060 Sekunden [16/Sep/2020:15:45:39 +0200] "GET /studio/api/flow/v1?id=*** HTTP/1.1" 200
Sie können den Timeout Wert auch verringern. 30 Sekunden sollten auch ausreichen. Prüfen sie bitte auch nochmal ob beim ihrem Client noch weitere Timeout Einstellungen gesetzt werden können. Eventuell gibt es auch eine Art "Debug Modus" der mehr als bisher loggt. Selbst wenn keine Antwort von unserem Server kommt, sollte der Client nicht in einem "undefinierten Zustand" hängen bleiben. Nach Ablauf der 120 Sekunden sollte ihr Prozess weiterlaufen. Leider kann ihnen und uns nur ihr Client "verraten" warum er hängen bleibt.
"In anderen Posts sehe ich, dass Sie Probleme mit ihrem Serverbetreiber Hetzner haben und auch andere Nutzer Probleme mit der Flow-Ausführung haben. Ich würde eindeutig einen Zusammenhang sehen wollen."
Ja, dass ist korrekt. Allerdings waren die Probleme begrenzt auf die letzen 2 Tage. Das erklärt ihre vorherigen Probleme nicht. Die Flow Ausführung hat auch nicht wirklich etwas mit der Trigger API zu tun. Beides ist nahezu vollständig entkoppelt voneinander. Deshalb kann ich da aktuell keinen Zusammenhang erkennen.
I hatte an dem Step in Pentaho Data Integration bereits ein erweitertes Logging aktiviert, das nutzt aber rein gar nichts, da keine Logs generiert werden, wenn der http-Client sich aufhängt, weil von der aufgerufenen URL kein Ergebnis zurück kommt.
Weitere Timeout-Einstellungen gibt es nicht. Ich versuche den Timeout zu verringern.