nach Update auf 6.4.1.0 liefert bei mir die Sync-API (api/_action/sync) auf ein product-upsert folgende Fehlermeldung
„Malformed UTF-8 characters, possibly incorrectly encoded“
Identischer Aufruf mit selbem Payload unter 6.4.0.0 lief erfolgreich durch.
virtuelle Maschine zurückgesetzt auf 6.4.0.0.
product-upsert initiiert, keine Fehlermeldung.
Update auf 6.4.1.0 durchgeführt.
betreffendes Product (aus dem vorigen upsert) im backend gelöscht.
selbes product-upsert mit identischem payload erneut initiiert.
Fehlermeldung wie oben.
Hat dazu jemand eine Idee?
Oder evtl. das selbe Problem ?
Hatte am 15.6.21 dazu ein Support-Ticket aufgemacht (wir haben die prof-Version im einsatz).
Leider kam folgende Antwort zurück
„…Ab einem Diamond Wartungsvertrag steht Ihnen die Auswahl „Entwickler-Support“ in Ihrem Shopware-Account zur Verfügung. Sollte dieser Menüpunkt bei Ihnen nicht auswählbar sein, beinhaltet Ihr Support-Paket keine Möglichkeit eine Anfrage an den Entwickler-Support zu stellen…“
Super. Da frage ich wofür wir 2,5k€ ausgegeben haben.
Bisher konnte ich noch alle auftretenden Probleme selbst lösen.
Nun das erstes Problem, bei dem ich Hilfe brauche. Ergebnis: null
@sicordev : wenn ich irgendeinen Workaround finde melde ich mich bei dir
@elvis-d
Einen kleinen Teilerfolg hatte ich bereits.
Sobald ich beim Produktabgleich den key „visiblilities“ weggelassen habe, läuft der Abgleich durch.
Irgendwas scheint sich hier bei dem Update verändert zu haben.
Ich hatte den Fehler auch schon mehrfach bekommen, meisten war es dann so das es eine übergebene ID nicht gegeben hat.
Ein anderer Fall war bei Artikel die Untervarianten haben, da bekommt der Master ja die „configuratorSettings“, wenn der Artikel aber bereits angelegt war, und ich ihm die selben noch mal zuweise bekomme ich auch den oben genannten Fehler.
Vielleicht kann das helfen
-Update-
Wenn ich versuche ein Product nicht über die Sync-API, sondern über die Admin-API zu erstellen, dann kommt seit 6.4.1.0 folgende Fehlermeldung:
„status“:„500“,
„title“:„Internal Server Error“,
„detail“:„An exception occurred while executing \u0027INSERT INTO product_configurator_setting (id, version_id, product_id, product_version_id, property_group_option_id, created_at) VALUES (\u0027\u0005#\ufffd\ufffd\ufffd\ufffdH\ufffd\ufffd}\ufffd0\ufffd*\ufffd\ufffd\u0027,\u0027\u000f\ufffd\u001c\ufffd\ufffdjK\u00beK\ufffd\ufffdu,4%\u0027,\u0027\ti\ufffd\ufffd\u0006\ufffdF\ufffd\f\ufffd9!@\ufffd\u0027,\u0027\u000f\ufffd\u001c\ufffd\ufffdjK\u00beK\ufffd\ufffdu,4%\u0027,\u0027\ufffdI\ufffdV\u04cfAa\ufffdT\ufffd\ufffdL\ufffd\u001d\u0027,\u00272021-06-24 14:33:14.147\u0027);\u0027:\n\nSQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry \u0027\x09i\x8E\xD8\x06\x94F\xED\xAF\xB5\x0C\xE19!@\x9E-\x0F\xA9\x1C\x\u0027 for key \u0027uniq.product_configurator_setting.prod_id.vers_id.prop_group_id\u0027“
Beachtenswert: identische JSON-Content erzeugt in 6.4.0.0 das Product ohne Probleme.
Ich habe dazu das Ticket NEXT-16111 aufgemacht.
Meine Vermutung ist, dass durch Beseitigung von NEXT-14835 dieses Problem erst entstanden ist.
Die sehr aufwändige Lösung für mein Problem war, sich nicht mehr auf das automatische Erstellen von kaskadierten „Untertabellen“ zu verlassen, sondern diese nacheinander selbst anzulegen.
Bei mir kam die gleiche Fehlermeldung wenn ich bereits bestehende Produkte über die AdminAPI aktualisieren wollte. Nachdem ich beim updaten des Produktes das Feld „visibilities“ weggelassen habe ging es plötzlich.
Hat es einen Grund das sich die visibility nicht aktualisieren lässt oder ist das ein Bug im System?
Das hängt davon ab, wie das „visibilities“-Objekt beim Update aussieht. Beim Update musst Du die id des visibiltities-Datensatzes mitgeben (die ist ungleich productId!), ansonsten wird versucht durch das upsert eine neue „visibility“ für dieses Produkt im bereits hinzugefügten Verkaufskanal anzulegen und das ist nicht möglich.
Bekam gestern einen Anruf aus Schöppingen. Es soll angeblich an NEXT-16111 jetzt bald gearbeitet werden. Es könnte daher sein, das in einem Dezember-21-Update endlich Varianten wieder so, wie es bis vor einem halben Jahr möglich war, per API erstellt und gepflegt werden können.
Die Hoffnung stirbt zuletzt…
Dieses Ticket ist nicht für eine Umsetzung vorgesehen. Daher wurde es geschlossen. Gründe, die zu einer solchen Entscheidung führen, können u.a. die Komplexität oder der Umfang des Tickets, sowie mögliche Fehlerquellen, die durch die Änderungen entstehen, sein.
The new behavior results from a new unique index on the ‘product_configurator_setting’ table.
During an upsert action, the system checks whether the entity already exists in the system and updates it if an ID has been passed, otherwise a new entity is created with this ID. This is also the case for ‚configuratorSettings‘.*
So in your case you must either submit an ID for each ‚configuratorSetting‘ or leave ‚configuratorSettings‘ completely empty.
Super. Im Klartext heißt das „Wir haben da was geändert, wodurch einige Funktionen nicht mehr wie gewohnt genutzt werden können. Sieh zu wie du damit klar kommst - dein Problem. Und nun nerv hier nicht weiter rum…“
Also ich fange jetzt langsam an echt genervt zu sein.
Evtl. war es doch keine so gute Idee zu Shopware zu wechseln :o(
Das ist doch wohl mehr als selbstverständlich, dass sich Dein Code an der Shopware-API orientieren muss und nicht Shopware an Dir. Neue Version, neue Regeln. Das wird mit jedem anderen System auch so sein. Viel Erfolg!
also früher, ganz früher, da wo noch alles aus Holz war und vieles mit der Hand gemacht wurde, da gab es so Prinzipien wie „Abwärtskompatibilität“.
Eine sauber programmierte Win32s-Anwendung aus Zeiten von Windows 3.1 wird auch auf einem aktuellen Windows 11 noch hervorragend ihren Dienst tun.
Ich stelle mir ja nur die Frage, wenn ich jetzt x Stunden in die Entwicklung einer Shopware-Anbindung an unser ERP-System baue, sollte/muss ich dann davon ausgehen, dass mit Shopware-Version 6.4.7 meine Anbindung nicht mehr funktioniert, obwohl sie streng nach vorliegender Dokumentation für 6.4.6 gebaut wurde?
Das ist doch wohl mehr als selbstverständlich, dass sich Dein Code an der Shopware-API orientieren muss und nicht Shopware an Dir. Neue Version, neue Regeln. Das wird mit jedem anderen System auch so sein. Viel Erfolg!
also früher, ganz früher, da wo noch alles aus Holz war und vieles mit der Hand gemacht wurde, da gab es so Prinzipien wie „Abwärtskompatibilität“.
Eine sauber programmierte Win32s-Anwendung aus Zeiten von Windows 3.1 wird auch auf einem aktuellen Windows 11 noch hervorragend ihren Dienst tun.
Ich stelle mir ja nur die Frage, wenn ich jetzt x Stunden in die Entwicklung einer Shopware-Anbindung an unser ERP-System baue, sollte/muss ich dann davon ausgehen, dass mit Shopware-Version 6.4.7 meine Anbindung nicht mehr funktioniert, obwohl sie streng nach vorliegender Dokumentation für 6.4.6 gebaut wurde?
Ich finde ihr habt beide Recht. Ein System ändert sich und volle Abwärtskompatibilität kann nicht immer dauerhaft gewährleistet werden, aber in einem bestimmten Rahmen sollte man sich schon darauf verlassen können, dass einem die Schnittstellen nicht bei jedem kleinen Update um die Ohren fliegen. Dazu gibt es eigentlich auch verschiedene Versionssprünge. Ein kleiner Versionssprung von 6.4.6 auf 6.4.7 sollte keine vorherigen API Funktionen einfach so unbrauchbar machen oder zu stark verändern.