26. September 2022 14:42
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.
26. September 2022 14:51
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?
26. September 2022 15:05
Ja, hab ja geschrieben, dass ich meine IT gefragt habe. Die erkennen nicht mal den Versuch des Aufrufs.
26. September 2022 15:15
Glaube nie einem IT'ler!
Allgemeine Tips: Dienst neu starten, wenn das nix hilft Server neu starten.
27. September 2022 09:38
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.
27. September 2022 11:47
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
27. September 2022 13:01
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.0Ich 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.
27. September 2022 14:37
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/875728https://cloudblogs.microsoft.com/dynami ... source=navGrundsätzlich hilft ein aktuelleres CU, ich vermute du bist auf einem recht alten Stand.
27. September 2022 15:54
enh hat geschrieben: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
27. September 2022 15:55
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.
5. Oktober 2022 12:56
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
5. Oktober 2022 13:23
Mike24 hat geschrieben: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
31. Juli 2023 08:56
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.
31. Juli 2023 17:03
Wurde denn sonst noch was umgestellt? (Server?)
Das scheint ein generelles Verbindungsproblem zu sein, unabhängig von den DotNet Anpassungen.
31. Juli 2023 17:48
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
1. August 2023 08:59
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
1. August 2023 09:05
Hallo,
Fiddi, du meinst aber nicht das Tls12. Das hab ich ja drin.
Nein, meine ich nicht.
Gruß Fiddi
1. August 2023 11:17
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-clienthttps://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?
2. August 2023 11:03
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
7. August 2023 18:19
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.
4. September 2023 16:46
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
8. September 2023 12:13
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
8. September 2023 14:40
vempire hat geschrieben: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
16. Februar 2024 11:26
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?
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.