Super, danke für die schnelle Notlösung! Zu Shipcloud noch: Das geht aber erst ab Tarif "Profesional" für 29€ im Monat. Es ist aber für solche Fälle hilfreich wenn man ein Shipcloud "Starter Paket" für 5 Euro im Monat hat, dann hat man eine Alternative zur Hand. Ich habe gestern meine DHL Labels fix mit Shipcloud erstellt, kostet zwar etwas mehr, aber dafür gehen sie heute morgen raus.
gleiches Problem, gleiche Fehlermeldung, nichts funktioniert bzgl DHL Label Das Versandlabel konnte nicht erzeugt werden. - SOAP-ERROR: Parsing WSDL: Couldn't load from 'https://cig.dhl.de/cig-wsdls/com/dp...-api/3.1/geschaeftskundenversand-api-3.1.wsdl' : failed to load external entity "https://cig.dhl.de/cig-wsdls/com/dp...-api/3.1/geschaeftskundenversand-api-3.1.wsdl"
Ich habe Deine Änderung vorgenommen und habe bei mir einen Ordner Soap erstellt und die zwei xsd und die wsdl 2.2 eingefügt. (Habe noch Gambio 4.0) Bei mir kommt allerdings die Meldung: Laut php_info wird File aber unterstützt.
Ja, das ist genau das Symptom, das ich meinte. Wenn man sich das genau ansieht, erkennt man auch, was da schief läuft: „file:/var/www/…“ ist kein valider URL, das müsste „file:///var/www/…“ heißen. Schwierig, leider. Ich hab bislang nicht rausfinden können, wo genau dieser Fehler entsteht. Das passiert irgendwo im Dunstkreis der SOAP-Extension für PHP, und/oder in der XML-Parser-Library, die diese Extension verwendet. Hintergrund ist, dass die SOAP-Extension von uns nur die lokale WSDL-Datei bekommt, und diese Datei referenziert zwei andere Dateien (die beiden *.xsd im gleichen Verzeichnis). Diese Referenz wird da irgendwie falsch aufgelöst, und dann hakt das auf diese Art.
Ja was soll ich tun? Habe heute morgen ca. 350Bestellungen, habe nichts an den Einstellungen verändert und fühle mich plötzlich mit der Arbeit von Gambio im Stich gelassen... Lasst Euch schnell etwas einfallen, jede Minute kostet ein gefühltes Vermögen und meine Kunden. Habe keinerlei Änderungen am Shop vorgenommen und seit Samstag ist dieses Problem!!!
@BigRib Suche mal in GXMainComponents/Extensions/Geschaeftskundenversand/GeschaeftskundenversandSoapAdapter.inc.php diese Zeile (ca. Zeile 68): PHP: $this->pingWsdl($wsdlUrl); und ändere sie auf PHP: //$this->pingWsdl($wsdlUrl); Das ist nötig bei Shopsystemversionen, die nicht auf die Verwendung einer lokalen WSDL ausgerichtet sind.
Alles Gut gemeint, habe doch davon keine Ahnung!!! Ich will nur einen funktionierenden Shop kotz/grins
DHL scheint just in diesen Minuten die Verfügbarkeit der WSDL-Ressource wiederhergestellt zu haben. Die Notlösung aus #39 ist also nicht mehr nötig; wer das eingebaut hat, sollte also idealerweise den Urzustand wieder herstellen.
Nur sicherheitshalber: DHL hat dich im Stich gelassen, nicht wir. Und die haben das nicht als willentliche Aktion gemacht, denen ist was missraten. Das müsstest du dann auch dem Verursacher sagen. Wirklich dringende Empfehlung.
Vielen Dank an das Gambio Team, das trotz eines Fehler von DHL, hier im Forum stets bemüht ist eine Lösung zu finden und mit Rat und Tat zu Seite steht, was nicht immer einfach ist. Vielen Dank dafür und allen einen ruhigen und entspannten Wochenstart. Liebe Grüße Damian
Ab sofort geht das wieder ! Vor 10 min hat nicht Funktioniert jetzt aber schon! Danke an wem auch immer !
@Marco (Gambio) Mal als Idee für die Zukunft: Man könnte es doch so programmieren das, falls mal die Serverversion (DHL Server) der wsdl ausfällt, automatisch auf die lokalen (lokaler Server) Dateien zugegriffen wird. Laut DHL Entwickler Portal ist seitens DHL eh nur eine einmalige Abfrage der Serverversion gewünscht zwecks Performance. Und die wsdl Dateien in einen nicht geschützten Ordner legen weit oben in der Ordnerhierarchie (damit die Parse-Errors bei manchen nicht erscheinen). Wäre simpel umsetzbar .... und ausfallsicherer.... Wäre für Eure Cloud sicher auch nicht verkehrt --- und uns andere Kunden. So in etwa, natürlich mit mehr Cases für mehr Eventualitäten: PHP: if(http_response_code(404)) { 'wsdl_url' => sprintf('file://' . __DIR__ . '/Soap/geschaeftskundenversand-api-%s.wsdl', $version),}else { 'wsdl_url' => 'https://cig.dhl.de/cig-wsdls/com/dpdhl/wsdl/geschaeftskundenversand-api/3.1/geschaeftskundenversand-api-3.1.wsdl',} LG Peter
@kugelschubs2 Das ist im Ansatz eine hübsche Idee, aber müßig, wenn man es etwas weiter denkt. Dass der WSDL-Abruf ausfällt, während der dahinter liegende Webservice dennoch aufrufbar bleibt, ist extrem selten. Meistens ist es doch eher umgekehrt, wie die Erfahrung zeigt. Für das fallweise Fangen solcher Fälle irgendeine Dynamik da einzubauen, halte ich insofern nicht für zielführend. Wie wir generell zukünftig mit dem Abruf umgehen, müssen wir noch mit DHL klären. Ich persönlich halte wenig davon, die WSDL bei SOAP-Schnittstellen im Shop mitzuschleppen, weil dann das Risiko besteht, dass die Schnittstellenbeschreibung im Shop nicht mehr zu der beim Dienstleister passt, das führt dann zu ganz neuen, fiesen Problemen. Die WSDL selbst ist an sich eine statische Ressource, die sich normalerweise nur selten ändert und die insofern bei einer öffentlich zugänglichen Schnittstelle auch nicht vom Application Server ausgeliefert werden muss, sondern von einem separaten, ressourcenschonenderen Server.