[gelöst] Bei wem läuft der Währungswechselkurs-Dienst noch?

Hallo,

seit dem 23.9. läuft der Währungswechselkurs-Dienst bei mir nicht mehr. Dieser ruft seit Jahren die URL https://www.ecb.europa.eu/stats/eurofxr ... -daily.xml auf.
Es macht keinen Unterschied, ob ich die Funktionalität von OPplus oder den Standard (Page 1650, Table 1650) verwende. Es liegt an der URL. Ich bekomme diese Fehlermeldung.

2022-09-26 14_19_22-Microsoft Dynamics NAV.png

Im Debugger kracht es an der Stelle: Codeunit 1235 .. Function CreateXMLReaderFromPath

Code:

XmlReader := XmlReader.Create(Path,XmlReaderSettings);

Wenn ich die URL in Firefox aufrufe, erhalte ich die Wechselkurse. Ich nehme an, dass der Anbieter etwas bei sich geändert hat.

Habe meine IT schon gefragt, ob da vielleicht etwas an der Firewall geblockt wird .. die erkennen aber nix.

Funktioniert bei jemandem dieser Dienst über diese URL oder verwendet ihr einen anderen "Anbieter"?
Für sachdienliche Hinweise antwortet bitte in diesem thread.

Viele Grüße
Andi

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Zuletzt geändert von vempire am 27. September 2022 15:55, insgesamt 1-mal geändert.

Ich hab's gerade in NAV 2017 getestet (Codeunit 1281 über Aufgabenwarteschlange), funktioniert. Der Fehler klingt für mich als Laie auch danach dass dein Rechner (Server) nicht rauskommt. Hast du mal die Firewall auf dem Server geprüft?

Ja, hab ja geschrieben, dass ich meine IT gefragt habe. Die erkennen nicht mal den Versuch des Aufrufs.

Glaube nie einem IT'ler!

Allgemeine Tips: Dienst neu starten, wenn das nix hilft Server neu starten.

Hallo,
ich hab das soeben auch kurz getestet. Gleiche Fehlermeldung.
Das hängt mit TLS zusammen, das muss erhöht werden danach funktioniert es wieder. Das kannst du so machen:

Variablen:

Code:

Name   DataType   Subtype   Length
ServicePointManager   DotNet   System.Net.ServicePointManager.'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'   
SecurityProtocolType   DotNet   System.Net.SecurityProtocolType.'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'   


Code:

Code:

ServicePointManager.SecurityProtocol := SecurityProtocolType.Tls12;


Ich hab das testweise bei der Codeunit 1299 bei der TryFunction GetWebResponse eingebaut, bevor

Code:

HttpWebResponse := HttpWebRequest.GetResponse

ausgeführt wird.

Hallo Furean,

vielen Dank für deine Antwort. Es "freut" mich schon mal, dass der Fehler auch bei jemand anders auftaucht.

Deine Code-Änderung versteh ich leider nicht ganz. Du definierst eine neue Variable ServicePointManager und setzt ein besonderes SecurityProtocol.
Was hat denn ServicePointManager für Auswirkungen auf andere Variablen?
Wo hast du ServicePointManager überall eingebaut? Nur in C1299 oder auch in C1235?
Kannst du bisschen mehr Code zeigen?

Ich verstehe nicht, was es bringen soll, wenn ich ServicePointManager in C1299.GetWebResponse einbaue. Ich bin aber auch kein DotNet-Fachmann.

Code:

[TryFunction] GetWebResponse(VAR HttpWebRequest : DotNet "System.Net.HttpWebRequest";VAR HttpWebResponse : DotNet "System.Net.HttpWebResponse";VAR ResponseInStream : InStream;VAR HttpStatusCode : DotNet "System.Net.HttpStatusCode";VAR ResponseHeaders : DotNet "System.Collections.Specialized.NameValueCollection";ProgressDialogEnabled : Boolean)
IF ProgressDialogEnabled THEN
  ProcessingWindow.OPEN(ProcessingWindowMsg);

ServicePointManager.SecurityProtocol := SecurityProtocolType.Tls12;

CLEARLASTERROR;
HttpWebResponse := HttpWebRequest.GetResponse;
HttpWebResponse.GetResponseStream.CopyTo(ResponseInStream);
HttpStatusCode := HttpWebResponse.StatusCode;
ResponseHeaders := HttpWebResponse.Headers;

IF ProgressDialogEnabled THEN
  ProcessingWindow.CLOSE;

Wo hast du denn diese Info her? Aus jüngeren NAV-Versionen?

Viele Grüße
Andi

Ich hab das nur in der genannten Codeunit (1299) eingebaut, danach funktioniert es wieder.
Ich habe das aktuell nicht weiter angesehen, da das bei uns nicht mehr verwendet wird, eventuell eignet sich eine andere Stelle besser dafür. Bei mir schmeißt er allerdings hier den Fehler, welchen du auch bekommst.

Darüber wird definiert welches Protokoll verwendet werden soll, genauer kannst du das hier nachlesen:
https://learn.microsoft.com/de-de/dotne ... mework-4.0

Ich hab wirklich nur eine Zeile hinzugefügt und die Variablen. Bei der GetWebResponse Funktion, das sieht aktuell dann so aus:

Code:

IF ProgressDialogEnabled THEN
  ProcessingWindow.OPEN(ProcessingWindowMsg);

CLEARLASTERROR;

//>>NEUEZEILE
ServicePointManager.SecurityProtocol := SecurityProtocolType.Tls12;
//<<NEUEZEILE

HttpWebResponse := HttpWebRequest.GetResponse;
HttpWebResponse.GetResponseStream.CopyTo(ResponseInStream);
HttpStatusCode := HttpWebResponse.StatusCode;
ResponseHeaders := HttpWebResponse.Headers;
HttpWebResponse.Close();
IF ProgressDialogEnabled THEN
  ProcessingWindow.CLOSE;



Bei uns gab es vor einiger Zeit eine Umstellung bzgl. der Versendung von E-Mails. Hier musste das selbe gemacht werden.

Stimmt, da gab es vor einiger Zeit (ca. 2018) mal ein Thema bzgl. TLS 1.2, finde gerade den ursprünglichen Beitrag dazu nicht, aber diese:
https://community.dynamics.com/nav/f/mi ... fix/875728
https://cloudblogs.microsoft.com/dynami ... source=nav

Grundsätzlich hilft ein aktuelleres CU, ich vermute du bist auf einem recht alten Stand.

Grundsätzlich hilft ein aktuelleres CU, ich vermute du bist auf einem recht alten Stand.

Das vermute ich auch , hier geht es zwar um die Entwicklungsumgebung und SQL-Server, aber die Liste dürfte auch bei den Clients anwendbar sein, also Support für TLS 1.2 bei NAV 2016 erst ab CU 31.
How to get earlier versions of the Dynamics NAV development environment to work with TLS 1.2

Habe die eine Zeile jetzt in C1235.CreateXMLReaderFromPath eingebaut.
Damit funktioniert es dann auch bei mir wieder.

Code:

LOCAL CreateXMLReaderFromPath(Path : Text)
ServicePointManager.SecurityProtocol := SecurityProtocolType.Tls12;

XmlReader := XmlReader.Create(Path,XmlReaderSettings);

Bin sehr froh darüber. Vielen Dank Furean und enh.

Ja, ich bin auf einem sehr alten CU-Stand.

Hallo,

vielen Dank für den Tipp.
Bei mir hat er auf unserer Entwicklungsdaten funktioniert, beim Kunden jedoch leider nicht.
Gibt es technische Voraussetzungen?
Wir haben das Problem bei mehreren Kunden in NAV2016 und 2017.

Viele Grüße
Mike

Gibt es technische Voraussetzungen?

Grundsätzlich immer , bei veralteten Betriebssystemen bzw. Servern muss man auch noch mehr machen:
Aktivieren von TLS 1.2 auf Clients

Hallo .. ich nochmal,

ich habe vor paar Tagen ein Update von CU 17 (48067) auf das neueste Build 52203 machen lassen. Bei diesem Build tut der Währungswechelkurs wieder nicht.

Bei HttpWebRequest.GetResponse bekomme ich ein timeout.

timeout.png

Diese DotNet-Funktion scheint in 52203 nicht so zu funktionieren, wie zuvor.

Ein ähnliches Problem hab ich auch bei der Prüfung der Lizenz für "Document Capture". Hier wird die Verbindung auch abgebrochen.

Abbruch.png

Weiß jemand, wizo diese DotNet-Funktionen bei mir nicht funktionieren könnten? Was muss ich ändern oder aktualisieren?

DotNet.png

Viele Grüße
Andreas

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Wurde denn sonst noch was umgestellt? (Server?)
Das scheint ein generelles Verbindungsproblem zu sein, unabhängig von den DotNet Anpassungen.

Hallo,

da fehlt eine Code-Zeile, ich finde aber im Moment nicht, wo die Änderung war.

Es war kurz bevor der eigentliche HHTP-request aufgerufen wurde.


Gruß Fiddi

Hallo,

dieser Server ist tatsächlich neu. Wir mussten unser Echtsystem und unser Testsystem auf 2 neue Server umziehen. Auf dem Echtsystem mit altem CU-Stand tut es.
Auf dem Testsystem mit neuem CU-Stand tut es nicht.

Ich dachte, dass der Währungswechselkurs-Dienst auf dem Testsystem schon mal lief, als er noch den alten CU-Stand hatte. Dem ist aber gar nicht so.

Vielleicht fehlt dort .NET 4.5.2. Mein ITler meint, dass er dort 4.5.2 nicht sieht. Er sieht nur 4.7.
4.5.2 läßt sich leider nicht installieren, wenn schon eine neuere Version da ist.

Fiddi, du meinst aber nicht das Tls12. Das hab ich ja drin.

Andreas

Hallo,

Fiddi, du meinst aber nicht das Tls12. Das hab ich ja drin.

Nein, meine ich nicht.

Gruß Fiddi

Das DotNet ist in der Regel abwärtskompatibel (ab. 4.5) und es sollte auch eine andere Meldung kommen, falls dass das Problem sein sollte.
Ich hab es auch mal mit der von dir genannten Version probiert, dort hatte ich keine Probleme. Ist bei euch die Dienste-URL "http://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xml" hinterlegt?
Kann diese vom Server aufgerufen werden?

Die Anpassung mit TLS12, solltest du auch nicht mehr brauchen. Das wurde mit Cumulative Update 31 abgeändert. Dort hatte Kowa schon einen Link weiter oben gepostet.
https://learn.microsoft.com/de-de/mem/c ... 1-2-client
https://support.microsoft.com/en-au/top ... 447f9e1161

@fiddi, bezieht sich das mit der fehlenden Codezeile auf "Document Capture", oder ist das ein generelles Problem mit dieser NAV Version?

Hallo,

ja, diese URL wird angesprochen. Allerdings über https, bzw. Port 443.

Die URL kann ich leider nicht über Browser testen. Aus Sicherheitsgründen kann über Browser gar nix externes angesprochen werden. In unserer Firewall
gibt es aber eine explizite Regel, damit diese URL über 443 angesprochen werden kann. Gäbe es die nicht, würde ich eine andere Fehlermeldung bekommen,
die besagt, dass diese IP über 443 gar nicht angesprochen werden kann. Deshalb weiß ich, dass die Anfrage generell gesendet werden kann. Fragt sich nur, welcher
"Parameter" fehlt, damit auch eine Antwort zurückgesendet wird.

Viele Grüße
Andreas

Ja - https sollte natürlich auch funktionieren.
Bin mir nicht sicher an was das bei euch liegt, ich hatte das bei uns nochmal mit der gleichen Version getestet, dort kann ich ohne Anpassung die Währungswechselkurse abfragen.
Dort kommt auch keine Fehlermeldung. Zusätzlich wurde nichts eingerichtet, darum ging ich davon aus dass es anderweitig bei euch blockiert wird.

Hallo,

mittlerweile konnte ich die URL per Firefox am Server aufrufen. Das ging ohne Probleme. Deshalb denke ich, dass die Firewall nix blockt. Ein Test über den Internet Explorer war schwer zu bewerkstelligen. Einmal hab ich sogar eine Rückmeldung bekommen. Wiederholen konnte ich es nicht. Nach langer Zeit kam aber eine Meldung, dass der Browser veraltet ist.

Ich glaube, mir wird nur die "eine Zeile", die Fiddi erwähnt hat, weiterhelfen. Nur wer kann mir die verraten?

Viele Grüße
Andreas

Hallo,

das Problem bei Report 5157809 (von OPplus) konnte ich jetzt beheben. Zusätzlich zu Zeile 1, siehe unten, habe ich noch Zeile 2 hinzugefügt.
Damit erhalte ich keine Fehlermeldungen mehr und der Download der Kurse funktioniert wie gewohnt.

Code:

ServicePointManager.SecurityProtocol := SecurityProtocolType.Tls12;
ServicePointManager.CheckCertificateRevocationList(FALSE);


Jetzt muss ich nur noch schauen, wo ich diesen Befehl bei der Lizenz-Prüfung von Document Capture einbauen muss.

Viele Grüße
Andreas

Jetzt muss ich nur noch schauen, wo ich diesen Befehl bei der Lizenz-Prüfung von Document Capture einbauen muss.

Hallo nochmal,

sehr komisch. Jetzt wollte ich den Standard-Währungswechselkurs-Dienst (Page/Table 1650) zum Laufen bringen.
Habe gemerkt, dass er jetzt ohne weiteres Zutun funktioniert

Die Lizenz-Abfrage bei Document Capture tut auch ohne weiteres Zutun.

Daraus schliesse ich, dass der einmalige Aufruf von ServicePointManager.CheckCertificateRevocationList(FALSE) im Report von OPplus auf dem ganzen Server
die Zertifikatsverarbeitung geändert hat. Verstehen tu ich es noch nicht, aber mit dem Ergebnis bin ich natürlich zufrieden.

Viele Grüße
Andreas

Bei einem Kunden haben wir folgendes Problem nach dem Einbau der Updates für Tabelle 1650 wie oben beschrieben. Es geht um NAV 2017.

Der Fehler kommt beim Eintragen der "Dienste-URL" auf der Währungswechselkurs-Dienst Karte.

Der Debugger bricht mit Fehler ab in einer Codeunit die aus der Page 1651 "Curr. Exch. Rate Service Card" aufgerufen wird (procedure "GenerateXMLStructure")

---------------------------
Fehler bei einem Aufruf von System.Xml.XmlReader.Create mit folgender Meldung: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 80.90.16.91:443
---------------------------

Das kommt von hier:

Codeunit 1235 "XML Buffer Writer"
CreateXMLReaderFromPath(Path : Text)
XmlReader := XmlReader.Create(Path,XmlReaderSettings);

Der Anwender erhält dann diese Fehlermeldung:

---------------------------
Die bereitgestellte URL enthält keine unterstützte Struktur.
---------------------------

Ich gehe davon aus dass dies mit Firewall oder ähnlichen Einstellungen zu tun hat. Hat jemand eine bessere Idee?