Gelöst Wawi läuft Amok wenn etwas nicht gefällt

[css-umsetzung]

Ich habe gerade das Problem und das wohl auch nicht nur beim Prestashop Connector, bei Shopware ist mir das auch schon ähnlich aufgefallen, dass die Wawi wenn Beispielsweise Artikeldaten nicht OK sind, die Wawi, den zuletzt gesendeten Datensatz immer und immer wieder sendet.

Ich spreche da jetzt von den letzten 10 Artikel in meinem festgestelltem Fall. Das heisst das durch dei Worker, in relativ kurzer Zeit, diese 10 Artikel mehrere 100mal, wenn man es nicht bemerkt sogar mehrere 1000 mal eingefügt werden.

Das muss dringend behoben werden, besonders weil es im Prestashop Fall nur darum ging, dass wohl die Kurzbeschreibung zu lang war. Ich sehe nirgends einen Hinweis, den die Wawi selbstständig ausgeben müsste.

hier der Auszug aus dem errorlog:




Da steht das die Short-description nicht länger sein darf als 3997 und die derzeitige Länge 4162 Zeichen hat.
nachdem ich das bereinigt habe kamen die nächsten Fehlermeldungen das die Short Description nicht länger als (ich glaube) 892 Zeichen lang sein darf.

Irgendwas muss da passieren, damit die wawi den Artikelblock nicht immer wieder erneut sendet udn nicht mal eine Fehlermeldung hinterlässt, die der Shopbeseitzer sieht.

 

[dc-nico]

Hallo,

ich weiss nicht ob es jetzt der richtige Hinweis ist, aber wenn die Artikel IDs der Connector_Link Tabelle nicht mit den IDs im Shop übereinstimmen, dann wurden bei mit manche Artikel bei jedem Abgleich erneut angelegt.
Ich habe damals die Connector_Link komplett geleert und neu abgeglichen.
Es geht sicher auch über die Connector Einstellung Shop zurücksetzen oder so.
Vielleicht reicht es auch, wenn du die betroffenden Artikel /IDS aus der Connector_Link löscht und auch im Shop entfernst.

Gruß

NICO

 

[css-umsetzung]

Hallo,

nein das ist davon unabhängig das system wurde jedes Mal kompl. neu zurückgesetzt.

 

[daniel.jtl]

Das die Wawi Artikel bei Fehlern neu sendet ist auch beabsichtigt.
Zudem sollten dem Shop-Betreiber natürlich die Auflagen und Beschränkungen des Shops bekannt sein, und die Daten entsprechend auch in der Wawi gepflegt.
Wir können ja schlecht per Connector einfach Beschreibungen etc. wegschneiden.

 

[css-umsetzung]

Das die Wawi Artikel bei Fehlern neu sendet ist auch beabsichtigt.
Zudem sollten dem Shop-Betreiber natürlich die Auflagen und Beschränkungen des Shops bekannt sein, und die Daten entsprechend auch in der Wawi gepflegt.
Wir können ja schlecht per Connector einfach Beschreibungen etc. wegschneiden.

Aber Hallo
Ich halte das für einen Fehler,

wenn ich in einem Shop bin, in dem ich online meine Artikel Pflege, werden mir als Shopbesitzer meine Grenzen aufgezeigt, sprich der Shop meckert mich an wenn ihm meine Artikeleinpflege nicht gefällt. Eure Ameise macht das gleiche, passen Ihr die Daten n icht verarbeitet Sie diese nicht und gibt mir Fehler aus.

Ich sehe das echt anders, wenn ich einen Connector zur verfügung stelle, dann muss der Connector auch wissen, welche Bedingungen der Shop, den ich connecte, erwartet, und nicht immer weiter Daten reinwerfen die nicht verarbeitet werden können. Hier werden über Nacht mehrere 1000 Artikel angelegt,

Ich kenne keinen Shopbesitzer, der weiß, wie groß die Felder der Datenbanken sind.

 

[daniel.jtl]

dann muss der Connector auch wissen, welche Bedingungen der Shop, den ich connecte, erwartet

Das ist technisch nicht machbar, da sich die Längen bei jedem Update des Shops ändern könnten oder auch durch Benutzer-Modifikation geändert werden kann. Das können wir unmöglich permanent nachhalten und es ist auch nicht die Aufgabe des Connectors.
Der Connector steuert die API des Shops an, mit deren Hilfe die Daten wie vom Shop vorgesehen angelegt werden. Auch die genannte Fehlermeldung kommt nicht vom Connector, sondern direkt vom Shop (siehe Dateinamen).
Die Frage sollte somit an Presta gestellt werden, wieso deren API die Artikel trotz gescheiterter Validierung und Fehlermeldung in die Datenbank schreibt.
Ich werde mir das gerne mal genauer angucken, aber einen Fehler des Connectors kann ich hier definitiv nicht erkennen.

 

[dc-nico]

Und was wäre, wenn man die Spalte für beschreibung auf einen höheren Wert setzt?
Dann dürfte der Shop nicht mehr meckern oder ?

Gruß

NICO

 

[css-umsetzung]

Es würde ja ausreichen, wenn Ihr den Betrieb des Workers für die Plattform stoppt, Ihr seht ja das es ein exception gibt, das ist ja etwas aussergewöhnliches, da es sonst nicht vorhanden ist. dann würde man diese Fehlermeldung in verkürzter Form ala "exception, Shop aktiviere das debug" schreiben, dann weiß jeder was zu tun ist.

Wenn ich mir die Verbindung Shopware -> Plentymarket anschaue dann prüft der Connector auch ob die Daten passen, gibt es einen Fehler, hört der Connector auf.
Ich weiß schon, das das nicht einfach ist , aber ein System zu schrotten weil man Fehler ignoriert, ist für den Shopbetreiber ungünstig.

@dc-nico : Das mit dem Feld ist nur eins der Probleme die auftreten könnten und Presta oder andere Shops möchten, genau wie JTL mit sicherheit nicht, das man in deren Datenbanken rumbastelt.

 

[Xantiva]

Die erste Frage wäre mal:

Das die Wawi Artikel bei Fehlern neu sendet ist auch beabsichtigt.

Warum? Was soll das bringen? Der Fehler wird sich nicht plötzlich in Luft auflösen, nur weil man es 1.000 Mal versucht. Dann müsstet Ihr schon anfangen die Fehler unterschiedlich zu bewerten. Eine zu lange Beschreibung ist ein zu lange Beschreibung und wird durch ständige Wiederholung auch nicht kürzen (die nutzt dabei nicht ab ). Wenn der Shop kurzfristig nicht erreichbar ist und z. B. einen #503 liefert, dann könnte man es nach der Retry-After Angabe noch 1-2 mal versuchen. Aber auch dann muss Schluss sein.

Das jetzige Verhalten bringt den Abgleich nur in eine Endlosschleife ...

 

[daniel.jtl]

Warum? Was soll das bringen?

Das ist ein gängiges und übliches Entwicklungs-System (Stichwort: Stateless) und bringt sehr viel.
Sinn und Zweck des Ganzen ist nämlich, dass jede Komponente jederzeit abstürzen kann oder sogar die Netzwerk-Leitung zwischenzeitlich weg sein kann, ohne dass Daten verloren gehen.
Genau dieses Wiederholen des Sende-Vorgangs ist also absolut beabsichtigt.
Wenn das immer wieder von vorne startet, liegt das ja einfach daran dass der Fehler offenbar nicht beseitigt wird, was aber ja definitiv nicht die Aufgabe des Connectors ist.

 

[dc-nico]

@css-umsetzung, na wenn mir der Platz für die Kurzbeschreibung nicht reicht, änder ich die Parameter.
Wenn diese begrenzt wurden, dann sicher nur, weil das Design mit einer längeren Kurzbeschreibung etwas unsymetrisch aussieht.
Aber als css-umsetzer kannst du das Design sicher leicht so gestalten, dass es alles passt.
Ich sehe da keine Probleme bezüglich der längeren Beschreibung.

Gruß

NICO

 

[css-umsetzung]

@css-umsetzung,
Aber als css-umsetzer kannst du das Design sicher leicht so gestalten, dass es alles passt.

ja, das kann ich, aber es geht ja nicht darum das ich das einfach alles anpassen könnte, es geht darum dass man sich nicht am core, bzw. an der Datenbank vergreift um vom System vorgegebene Felder oder Dateien zu verändern.

Die Template Dateien und die Ausgabe ist zweitrangig, es geht hier nur um die Systemfunktionen.
Stell dir vor ein Artikelname darf nach einem Shopupdate keinen Bindestrich mehr haben, die Wawi erlaubt dir aber weiterhin Bindestriche zu verwenden, Die Wawi bemerkt diesen Fehler und sendet dennoch, immer und immer wieder 10 Artikel in den Shop wovon 9 akzeptiert und immer wieder neu eingefügt werden.

Bis ich das als Shopbesitzer merke, das in meinem Shop Chaos herrscht dauert unter umständen Tage und dann ist alles zu spaet, der Shop ist geschrottet, Es ist dann ein erheblicher Aufwand, das zu bereinigen.

Hinzu kommt, dass der Shopbesitzer gar nicht weiß warum das passiert ist, weil sich ein OttoNormaloShopbesitzer keine Changelogs oder Api Schnitstellenbeschreibungen duchliest in denen solche Daten "eventuell" zu finden wären und es gab ja auch kein Feedback, dass etwas nicht stimmte.

Der Shopbesitzer bringt alles wieder in Ordnung und drei tage spaeter steht er vor dem gleichem Problem.

 

[dc-nico]

Ja, das ist natürlich schlecht.
Aber dass der Connector immer wieder Artikel hoch lädt hat mit der Connector_Link zu tun.
Der Connector merkt sich nicht, dass diese Artikelnummer schon da ist und legt bei jedem Abgleich die gleiche noch ein mal an.
Ich hatte da schon einige Hundert gleiche Artikel.
Es konnte nur mit einem Bereinigen der Connector Link behoben werden.

Eigentlich ist es egal was der Fehler ist, der Connector muss erkennen, dass ein Artikel schon vorhanden ist.
Oder sehe ich das falsch?

Gruß

NICO

 

[daniel.jtl]

Die Wawi bemerkt diesen Fehler

Genau das tut sie nicht. Es wird zwar gemerkt dass ein Fehler auftrat, aber die Wawi kann diese nicht auswerten weil sie vom Shop und/oder Server kommen.
Der Wawi ist also der Grund dafür absolut unklar und unverständlich. Es wird lediglich vermerkt dass die Übertragung nicht erfolgreich war, so dass diese beim nächsten Mal eben erneut versucht wird.

der Connector muss erkennen, dass ein Artikel schon vorhanden ist.

Tut er auch, sofern die Übertragung denn erfolgreich war und somit auch ein Link-Eintrag erzeugt wurde, der wiederum an die Wawi zurückgeliefert wurde.
Erst dann kann die Wawi vermerken dass dieser Artikel (bis zur nächsten Änderung) nicht mehr gesendet werden muss.

 

[dc-nico]

Ja, das ist eben die Voraussetzung.
Solange dann alles stimmt, funktioniert es perfekt.
Bei mir ist im Moment alles gut.

 

[Xantiva]

Das ist ein gängiges und übliches Entwicklungs-System (Stichwort: Stateless) und bringt sehr viel.
Sinn und Zweck des Ganzen ist nämlich, dass jede Komponente jederzeit abstürzen kann oder sogar die Netzwerk-Leitung zwischenzeitlich weg sein kann, ohne dass Daten verloren gehen.
Genau dieses Wiederholen des Sende-Vorgangs ist also absolut beabsichtigt.
Wenn das immer wieder von vorne startet, liegt das ja einfach daran dass der Fehler offenbar nicht beseitigt wird, was aber ja definitiv nicht die Aufgabe des Connectors ist.

Der Connector kann ja gerne Zustandslos sein, aber ein stumpfes Wiederholen durch den Worker kann doch nicht zielführend sein, oder?

Beispiel:
Ich habe 10.000 zu übertragende Artikel. Beim ersten Artikel XY taucht ein Fehler auf. Wenn ich es richtig verstehe, versucht der Worker diesen fehlerhaften so lange zu übermitteln, bis es funktioniert? (So ist ja auch das o.g. Fehlerbild.) Die restlichen 9.999 Artikel würden evtl. keinen Fehler verursachen (weil die Beschreibung nicht zu lang ist, what ever) und können sofort übertragen werden.

Zielführend wäre es, nach dem ersten Fehlerversuch, dies bei dem Artikel XY zu vermerken und versuchen, den nächsten noch zu übermittelnden, fehlerfreien Artikel zu übermitteln. Dann wären wenigstens die 9.999 Artikel zeitnah aktualisiert. Von mir aus kann es dann noch x Fehlversuche geben. Aber irgend wann sollte der Worker merken, dass etwas nicht stimmt und den Artkel als "Fehler" zu vermerken und beispielsweise der Admin darüber zu informieren. Sonst blockiert ein fehlerhafter Artikel dauerhaft die Arbeit des Workers, oder habe ich da etwas falsch verstanden?

 

[daniel.jtl]

Du hast das Prinzip da leider nicht verstanden: Wenn der Connector sich Fehler "merken" und überspringen wäre, wäre er nicht mehr stateless.
Zudem bekommt man in dem Fall massive Probleme mit Abhängigkeiten, da die Daten in einer aufeinander aufbauenden Priorität gesendet werden.
Es nützt zum Beispiel nichts wenn ich einen Vater-Artikel aufgrund irgendwelcher Probleme überspringen, und anschließend 50 Variationen schicke die aufgrund dessen nicht zugeordnet werden können.
Oder wenn ich Artikel sende, deren Kategorie zuvor nicht übermittelt werden konnte.
Bei so einem Vorgehen wäre innerhalb kürzester Zeit der gesamte Shop und dessen Datenbank-Konsistenz zerstört.

 

[css-umsetzung]

Da gebe ich dir recht, das ginge nicht, daher bin ich ja der Meinung, dann lieber die Artikel oder Kategorie (je nachdem in welchem Bereich der Fehler aufgetreten ist) nicht mehr bedienen und eine Meldung raushauen.

Ich finde es ja wirklich toll, dass Ihr das immer und immer wieder versucht, aber das Problem besteht eben, von 10 Artikeln ist einer Fehlerhaft und die funktionierenden 9 die ja schon im System sind, da alles OK war werden immer wieder neu reingeschoben, was eben nicht passieren darf, denn genau das ist dann der Fehler an der vorgehensweise.

Mich wundert es, dass dies noch keinem aufgefallen ist, die Gefahr das dies passiert, egal bei welchem Connector, ist ja recht hoch

 

[daniel.jtl]

von 10 Artikeln ist einer Fehlerhaft und die funktionierenden 9 die ja schon im System sind, da alles OK war werden immer wieder neu reingeschoben

Das ist nicht korrekt so. Wenn die Artikel wirklich erfolgreich gespeichert wurden, dann werden die auch nicht neu angelegt.
"Erfolgreich" ist für den Connector allerdings nur dann, wenn in der Link Tabelle ein Eintrag für die Relation zwischen Wawi- und Shop-ID erstellt wurde.
Erst dann kann der Connector überhaupt "wissen", dass es den Artikel schon gibt wenn er von der Wawi aufgrund eines Fehlers im Übertragungs-Block ggf. neu gesendet wird.

Wie ich zuvor aber schon erklärt habe ist das Problem hier aber auch nicht der Connector, sondern die API von Presta. Diese speichert offenbar trotz des Abbruchs mit Fehlermeldung die Daten schon unvollständig in die Datenbank.
Aufgrund dieses Abbruchs kommt der Connector nicht bis zu dem Punkt, wo er die Relation zwischen den IDs vermerken kann. Beim nächsten Abgleich erscheint dem Connector der Artikel dann als "neu", da die zugehörige Shop-ID fehlt.

Wir reden hier aber auch ehrlich gesagt über Punkte die absolut nicht in den Aufgabenbereich und die Verantwortung des Connectors fallen, wie ich jetzt hier entsprechend durch Fakten begründet und erklärt habe.

 

[css-umsetzung]

Ok, ich habe das Gefühl wir kommen hier nicht weiter, es wird sich aber jedes System so verhalten und die Frage ist immer, wer fügt diese Artikel wirklich ein, es ist letztendlich der Connector, der das über die Shopeigenen Funktionen tut, in dem er Sie anspricht, der Shop weiss bei den ersten 9 gar nicht das da noch einer kommt der nur zur hälfte oder falsch geliefert wird.

Aber gut wie schon geschrieben wir kommen hier nicht weiter, wir müssen also warten bis es in einigen Shops so richtig knallt, damit diese Vorgehensweise nochmal überdacht wird.