Hallo Gemeinde,
wir haben in einem aktuellen Projekt die Aufgabe eine Anbindung zwischen Navision und der REST API herzustellen. Grundsätzlich kommen die Artikel in Shopware an, allerdings wirft die API einen nicht besonders hilfreichen Fehler, sobald Umlaute, Sonderzeichen etc. ins Spiel kommen.
{„success“:false,„message“:„Invalid method or invalid json string.“}
Nun gibt es keinen Header den man einfach auf UTF-8 setzen könnte o.ä.
Das spannende ist: Wenn ich exakt diesen Request per Postman an die API sende, ist alles schick. Sendet Navision den exakt gleichen Request, schlägt er mit oben genannter Fehlermeldung fehl. Auch bei Postman muss ich nirgendwo ein Charset definieren.
Nun war die Zwischenlösung, alle Sonderzeichen in HTML Entitäten umzuwandeln, aber dann steht ja totaler Blödsinn in der Datenbank: Gewürz statt Gewürz. Was sich dann an vielerlei Stellen des Front- und Backends bemerkbar macht.
Daher meine Frage: Wie haben andere das gelöst? Wenn ich das richtig sehe, kann Navision gar kein UTF-8, aber wir werden ja vermutlich nicht die ersten mit einer Navision-Shopware Schnittstelle sein? Kann man die API dahingehend erweitern, dass sie HTML Entitäten wieder in anständige Umlaute und Sonderzeichen konvertiert?
Tausend Dank im Voraus,
Philipp
Funktioniert
json_encode( $text, JSON_UNESCAPED_UNICODE );
?
Auf Navision oder Shopware-Seite?
Wieder das alte Problem mit Zeichencodierungen… Es kommt immer ganz auf das Programm an, wie die zusammengestellten Daten codiert sind.
Das kann je nach Datenhaltung und Programm in einem ISO oder UTF8 - Format erfolgen.
Wenn deine Umlaute kaputt sind, so würde sich für Felder mit Umlautpotential ein utf8_decode bzw. utf8_encode anbieten.
Die Fehlermeldung könnte auch auf ein kaputtene oder nicht konforme Datenstruktur hinweisen… (Das war der Hinweis von BestShopPossible)
Das KANN von den zerschossenen Umlauten kommen, muss aber nicht.
Prüfe doch einmal, ob die Daten, die du an die Api schicken möchtest auch wirklich als Json abgeschickt werden, oder ob hier einfach nur ein Array zusammengepuzzled wird.
Wenn du die standard Shopware-Api-Klasse nutzt sollte eigentlich ein json_encode nicht mehr nötig sein.
Danke fürs Feedback. Wir haben den API Request auf jeden Fall geprüft und er ist gültiges JSON. Wenn ich den so nehme und in Postman sende geht es auch, nur aus Navision kommt eben die Fehlermeldung. Wenn man in diesem Request dann die Umlaute entfernt, geht auch dieser Request aus Navision durch. Daher haben wir es eindeutig auf die Umlaute und Sonderzeichen eingrenzen können.
Die Frage wird sein: Können wir denn auf Seiten von Shopware etwas daran verändern? Können wir also bei uns das utf8_encode o.ä. machen?
NAV kann doch .NET-Assemblies einbinden. Bau eines zum Zugriff auf die REST-Services von Shopware und codiere darin richtig auf UTF-8.
1 „Gefällt mir“
@volkerstraehle schrieb:
NAV kann doch .NET-Assemblies einbinden. Bau eines zum Zugriff auf die REST-Services von Shopware und codiere darin richtig auf UTF-8.
Die Navision Anbindung obliegt einem externen Dienstleister, aber ich gebe das so gerne an ihn weiter!
Ich hätte noch einen. NAV kann selber Webservices (SOAP) veröffentlichen. Man könnte nun hergehen und Shopware via REST über aktuelle Daten informieren (etwa ein Boolean-Feld). Danach ruft Shopware über ein neu zu erstellendes Plugin die Daten von NAV ab.
Es geht auch ganz ohne NAV, nur mit dem MS-SQL-Server. Das Stichwort heißt hier Trigger in den jeweilgen Tabelen und Kombination mit dem SQL-Broker. Das benötigt in NAV gar keine Programierung/Anpassung. Vorsicht ist nur bei BLOBs geboten, da diese bei NAV im Standard komprimiert sind. Schaltet man diese Komprimierungaus, dann kann man das auch mit .NET lesen.
Klingt hoch komplex. Und das alles für Umlaute… 
Nicht unbedingt nur für Umlaute. Über die SOAP-Webservices wird die normale Business-Logik in NAV (wie in Shopware auch) berücksichtigt. In Kombination mit Triggern/SQL-Broker ist das ganze unabhängig vom Client (CC oder RTC): der muss gar nicht laufen. Weiterer Vorteil: das ganze läuft in einem separaten Thread und blockiert weder Client noch SQL-Server durch Warten auf Antworten des Webservers (von Shopware).
Ihr könntet aber auch einen einfachen Fehler in NAV selbst produziert haben. Welche NAV-Version und wie erstellt Ihr die Dateien für den Export? Meine NV-Tage sind schon einige Zeit her, aber ich erinner mich, dass der Export über XML-Port anderen Output erzeuigt hat als der Dataport. Lass dich vom XML nicht täuschen. Wenn ich nicht alles vergessen habe, dann erzeugt der auch CSV und nicht nur XML.
NAV nutzte im Standard ANSI in neueren Versionen Unicode. Unter http://www.msdynamics.de findest Du die beste Hilfe, die du in DE fü NAV bekommen kannst. Die Wissen das.