Neues Thema starten

Flowrun Trigger via http funktioniert nicht

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


Anmelden um einen Kommentar zu veröffentlichen