Rekursiv Aufruf an WebService ?

19. November 2024 15:29

Hallo Zusammen,

ich stehe vor einem Problem mit einem Webservice-Request und hoffe auf eure Expertise.

Ausgangslage:
- Ich sende ein JSON-Request an einen Webservice (3rd Party, kein Zugriff auf deren Backend).
- Der Webservice akzeptiert die Anfrage und antwortet mit einem Status wie "Accepted" oder "Update". Diese Antwort speichere ich in ErrorText.
- Die Verbindung an sich scheint also erfolgreich zu sein.

Problem:
Wenn auf der NAV-Seite ein Fehler auftritt – beispielsweise in der Funktion GetVoucherRemainingAmount (z. B. "Voucher nicht gefunden") – wird dieser Fehler an den Webservice weitergegeben.
Das wäre grundsätzlich in Ordnung, wenn dies nur einmal geschähe. Allerdings hat der Webservice-Empfänger angemerkt, dass solche fehlerhaften Requests mehrfach eintreffen – etwa 8 Mal alle 20 Minuten.

Vermutung:
NAV scheint bei einem Fehler auf seiner Seite den ursprünglichen Request automatisch zu wiederholen, obwohl die Verbindung mit dem Webservice erfolgreich war und eine Antwort empfangen wurde.

Lösungsansatz:
Um das Problem zu umgehen, plane ich vor dem Aufruf von DoRequest1 eine Prüfung einzubauen:
Code:
IF GETLASTERRORTEXT <> '' THEN 
  EXIT; 

So soll verhindert werden, dass ein fehlerhafter Zustand zu weiteren Requests führt.

Frage:
Hat jemand eine Idee, warum NAV in diesem Szenario die Requests rekursiv erneut sendet, obwohl die Verbindung zum Webservice erfolgreich war?
Gibt es vielleicht eine NAV-interne Einstellung oder ein Verhalten, was ich übersehe?

Danke im Voraus für eure Hinweise!

Code:
JsonString := GetVoucherRemainingAmount(VoucherNo);
resulttext := JSonMgt.DoWebRequest1(JsonString);


Die Funktion Dorequest1 sieht so aus:

Variablen:
Name DataType Subtype Length
ResponseInStream InStream
ResponseHeaders DotNet System.Collections.Specialized.NameValueCollection.'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
ErrorText Text
HttpStatusCode DotNet System.Net.HttpStatusCode.'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
TempBlob Record TempBlob

Code:
Dorequest1 {
ServicePointManager.SecurityProtocol := SecurityProtocolType.Tls12;

TempBlob."Primary Key" := 1;
TempBlob.Blob.CREATEINSTREAM(ResponseInStream);


HttpWebRequestMgt.Initialize('https://url.to.webservice.make.com/123456abcdef');
HttpWebRequestMgt.SetMethod('POST');
HttpWebRequestMgt.SetContentType('application/json');
HttpWebRequestMgt.AddBodyAsText(jsonin);


IF HttpWebRequestMgt.GetResponse(ResponseInStream,HttpStatusCode,ResponseHeaders) THEN BEGIN
    ResponseInStream.READ(ErrorText);
    //MESSAGE('Result: ' + ErrorText);
END ELSE BEGIN
  HttpWebRequestMgt.ProcessFaultResponse(ErrorText);
END;

EXIT(ErrorText);
}

Re: Rekursiv Aufruf an WebService ?

19. November 2024 23:00

Hallo,
ich denke, da wird nichts rekursiv aufgerufen, sondern die API wird jedes Mal angefragt, auch wenn kein Voucher gefunden wurde.
MMn. solltest du die Funktion GetVoucherRemainingAmount dahingehend ändern, dass ein Boolean zurückgegeben wird und du die Anfrage nur durchführst, wenn auch ein Voucher gefunden wurde (oder die gesamte Funktion vorzeitig verlassen). Ohne einen gültigen "JsonString" gibt die API ja eh nichts gescheites zurück.

In etwa so:
Code:
GetVoucherRemainingAmount(VoucherNo: Code[xx]; VAR JsonString: Text): Boolean


Gruß

Re: Rekursiv Aufruf an WebService ?

Heute 15:38

es ist ein wenig verwirrend - warum schreibst du was in eine variable ErrorText, wenn es eigentlich eine Response ist o_O
TempBlob."Primary Key" := 1;

wozu das denn?

das hat natürlich nichts mit deinem urspr. Problem zu tun, sei aber trotzdem angemerkt.

Zu deinem Problem:

wie kommst du darauf, dass BC da was macht?
Dein Code ist doch individuell, oder bedienst du dich hier irgendeinem Standard?
Ich weiß nicht, wie dein Code wann wo aufgerufen wird, sprich wann du deinen Post-Request sendest.
Von deiner Funktion GetVoucherRemainingAmount ganz zu schweigen - wo ist die beschrieben?

Wie Ermac schon sagte, passe deine Funktion so an, dass sie den WebRequest nicht triggert, wenn nix gefunden wurde