Keim Import aus XTC304SP1

[igrimpe]

Hi,

um's verrecken krieg ich die Artikel (40k) und Kategorien (5k) nicht aus dem Shop nach easysales importiert.
xtc304SP1, es0971c, xtc- connector 0.98
Der Import läuft (ca. 15 Minuten, trotz lokalem Server), aber es werden weder die Artikel noch die Kategorien übernommen. Bestellungen werden jedoch angezeigt und können in eS übernommen werden.
Hab schon einmal die leere Datenbank wieder importiert, aber auch dann kein Import Prod/Cat.
Die easysales_ Tabellen auf dem server sind größtenteils leer - zumindest die wohl wichtigen martikel und mkategorie.
Der Import läuft durch ohne Fehlermeldung. eS. log enthält eine Zeile: "eS:0971"

Bin mit meinem Latei am Ende und für hilfreiche Tips dankbar.

 

[Thomas Lisson]

Hi,

an UTF8 liegt es schonmal nicht - da die Bestellunegn übernommen werden.

Sobald eazySales neu gestartet wird, wird ein neues es. log angelegt - der Inhalt dabei gelöscht.

martikel / mkategorie waren komplett leer? oder größtenteils?

Probier dies aus und gib mir ein Feedback:

in dbeS/syncinclude.php:

Aus

function auth()
{
	$cName = $_POST["userID"];
	$cPass = $_POST["userPWD"];

	$cur_query = eS_execute_query("select * from eazysales_sync");
	$loginDaten = mysql_fetch_object($cur_query);
	if ($cName == $loginDaten->cName && $cPass == $loginDaten->cPass)
		return true;

	return false;
}

mach

function auth()
{
return true;
	$cName = $_POST["userID"];
	$cPass = $_POST["userPWD"];

	$cur_query = eS_execute_query("select * from eazysales_sync");
	$loginDaten = mysql_fetch_object($cur_query);
	if ($cName == $loginDaten->cName && $cPass == $loginDaten->cPass)
		return true;

	return false;
}

Damit wird die Authentifizierung ausgehebelt und Du kannst nun im Browser folgendes aufrufen:
eazysales_connector/dbeS/getArtikel.php

Gib bitte bescheid, ob der Browser da was auspuckt.

 

[igrimpe]

getManufacturer

OK, das hat geholfen.
SQL Fehler weil manufacturer_id NULL (Der Shop-Betreiber hat keine Hersteller gepflegt)
Ich habe also so abgeändert:

function getManufacturer($manufacturers_id)
{
// check if there is a manufacturer_id at all!
if ($manufacturers_id) {
$manu_query = eS_execute_query("select * from manufacturers where manufacturers_id=".$manufacturers_id);
$manu = mysql_fetch_object($manu_query);
return ($manu->manufacturers_name);
}
// if no manufacturer, we return an empty string
else return '';
}

und jetzt werden Artikel und Kategorien auch importiert.

Problem mit fehlerhaften Sonderzeichen bleibt allerdings bestehen:
Beurer Blutdruckmessgerät BM 10
Ebenfalls bei Kundendaten etc:
Baaderstraße 25

 

[igrimpe]

was mir sonst noch aufgefallen ist:

Der Internetabgleich braucht sehr lange. Mit Server im lokalen Netz ca. 15-20 Minuten. Was passiert dann erst mit einem live-System, wenn über DSL 128k gearbeitet wird und der Server gleichzeitig auch noch Seiten an Kunden ausliefern muss?

Vielleicht sollte man die Sync-Richtung auswählen können? Jeweils für jeden Punkt getrennt, so dass man zumindest Artikel und Kategorien nicht jedesmal aus dem Shop abrufen muss. Das Pflegen von Artikeln mit xtC ist bei größeren Mengen sowieso kaum möglich, weshalb wir eine AJAX Anwendung dafür einsetzen, die das ganze deutlich performanter. Bei einem evtl. Umstieg auf eS, würde die Artikel- und Kategoriepflege sowieso über die lokale Anwendung laufen.

Zusatz: Die Abfrage über php-Scripte ist sicherlich ne gute Sache, weil's immer geht, möglicherweise wäre ein lokaler Connector aber auch nicht schlecht, der direkt auf den MySQL Server zugreift (ja ich weiß, ist bei vielen Providern nicht möglich ...)

 

[Thomas Lisson]

Problem mit fehlerhaften Sonderzeichen bleibt allerdings bestehen:
Beurer Blutdruckmessgerät BM 10

Du kannst für die aktuelle Sitzung den Charset, mit dem die DB antwortet setzen.
Also in dbeS/syncinclude.php hinter zeile 22 (nach xtc_db_connect() or die('....')
füge dies hier ein:

mysql_query("SET CHARACTER SET 'latin1'");

Dies sollte die Probleme beheben.

Ansonsten gibts noch die Funktion http://de2.php.net/manual/de/function.utf8-decode.php

Der Internetabgleich braucht sehr lange. Mit Server im lokalen Netz ca. 15-20 Minuten.

Das ist richtig. Das dauert auch nur beim allerersten Abgleich so lange (Du hast erwähnt, 40000 Artikel?), da alles aus dem Shop importiert wird.
Die Pflege danach geht viel zügiger. Pro veränderten Artikel wird ca. 0,5-1sec in Anspruch nehmen.
DSL128k hat dabei kaum was zu sagen, der Upload von 128Kbit reicht für de Pflege. Ausserdem müssen die Daten irgendwie ins Netz, ob Sie online eingestellt werden über den Adminbereich oder Dein AJAX tool, da werden noch wesentlich mehr Daten hin und hergeschickt (HTML drumherum). Von daher sollte dies eine erhebliche Zeitersparnis bei der Pflege sein.

Vielleicht sollte man die Sync-Richtung auswählen können?

Dies haben wir bewusst nicht so gemacht. Dadurch können Probleme auftreten, die nicht sein müssen. Was passiert z.B. wenn Bestellungen eingehen, wenn die dazugehörigen Artikel noch nicht da sind... usw.

Die Abfrage über php-Scripte ist sicherlich ne gute Sache, weil's immer geht,

Exakt. Dadurch können wir die Defines und globalen Funktionen aus dem Shop nutzen. Funktioniert der Shop, so auch der Connector. Performancemäßig würde sich da kaum was tun.

 

[igrimpe]

Das SET CHARACTER SET hat leider keine Abhilfe gebracht
Mann, wie ich das hasse. Können nicht alle englisch sprechen und sich auf 26 Zeichen beschränken, dann funzt auch plain-ASCII wieder.
Das mit dem charset hatte ich auch schon bei den export-scripten gemacht und da hette ich dann immerhin die richtigen Zeichen. Hier kommt aber immer nur jeweils UTF-8 codierung zurück.

Zum Sync: Vielleicht mach ich ja was falsch, aber nach dem ersten Internet-Abgleich starte ich den nächsten (m_artikel, etc sind gefüllt) und trotzdem rödelt er seine 20 Minuten rum.

Na, probier ich halt noch'n bißchen rum ...

 

[Thomas Lisson]

Das mit dem charset hatte ich auch schon bei den export-scripten gemacht und da hette ich dann immerhin die richtigen Zeichen. Hier kommt aber immer nur jeweils UTF-8 codierung zurück.

wie siehts aus mit utf8_decode() aus? Kriegst Du da die richtigen Zeichen?

Vielleicht mach ich ja was falsch, aber nach dem ersten Internet-Abgleich starte ich den nächsten (m_artikel, etc sind gefüllt) und trotzdem rödelt er seine 20 Minuten rum.

Kannst Du mir sagen, wie lange er braucht, wenn du (mit ausgehebelter UserAuthentifizierung) dbeS/getArtikel.php aufrufst ?

 

[igrimpe]

Mit utf8_decode geht es. Hat natürlich den Nachteil, das jedes Script betroffen ist -> bzw alle get_xxxx scripte?

Laufzeit (mit microtime()) ca. 0.02 sek
Klingt zwar recht schnell, aber bei 40k Artikeln kommen dann auch schon mal 800 Sekunden (also ca. 13 Minuten) zusammen. Und das auch wenn nur ein einziger Artikel in eS geändert wurde.
Mittelfristiges Ziel sind übrigens 100k Artikel und da wird's dann schnell unangenehm -> 2000 Sekunden = 33 Minuten.


Vorher wurde übrigens der GSShopBuilder eingesetzt und da war der Upload dann nur noch am Wochenende möglich, da es über mehrere Stunden ging (plus eine Ewigkeit für das 'kompilieren'). Deswegen ja auch der Wechsel auf xtC, damit man 'mal eben schnell' etwas ändern.
Die wenigsten Programmierer machen sich halt frühzeitig Gedanken über sehr große Datenbanken (eigene Erfahrung und selbst schon diesen Fehler gemacht, deshalb werfe ich mal grundsätzlich nicht mit Steinen) und hinterher läßt sich meist nicht mehr alles ändern, da das dann einer kompletten Neuentwicklung gleich käme.

 

[Thomas Lisson]

Mit utf8_decode geht es. Hat natürlich den Nachteil, das jedes Script betroffen ist -> bzw alle get_xxxx scripte?

Exakt. Du kannst sie Dir schon anpassen, ich denke nicht, dass dort während der Beta noch großartig was passiert. Wäre schön, wenn Du uns dann auch die Skripte zukommen lassen könntest für Leute mit dem gleichen Problem.

Laufzeit (mit microtime()) ca. 0.02 sek

Das ist bei getArtikel.php - richtig?
Wenn ja, dann sollte der Abgleich (wohlgemerkt nicht der allererste) bei 2-3Sec bleiben.

Kurz zum Verständnis:
Unsere Synchronisationszeit ist ab dem 2. Abgleich (weil der allererste Abgleich der Import zu eazySales ist) unabhängig von der Artikelanzahl und sollte pro Artikel - je nach Beschreibungslänge, Variationsanzahl etc. 0,5-3sec dauern + Bildupload.

eazySales holt als erstes Artikel ab, die noch nie zu eazySales importiert wurden. Diese Abfrage dauert - wie Du schreibst ca. 0,2Sec, d.h. er benötigt pro Artikel, der noch nie zu eS übertragen wurde, diese Zeit.

Als nächstes werden alle in eazySales geänderten Artikel und Kategorien im Shop geupdated. Dies geschieht so, dass nur diejenigen Artikel verschickt werden, die auch wirklich bearbeitet wurden oder bei denen der Lagerbestand verändert wurde. Das bedeutet, ändert man in eS 1 Artikel, sollte der Abgleich weniger als 2-3Sec dauern.

Dass er länger dauert, macht mich stutzig - hast Du nicht zwischendruh die eazysales_martikel Tabelle gelöscht oder ähnliches? Wieviele Datensätze sind in dieser Tabelle vorhanden?


Uns würde es sehr interessieren, dieses Problem zu lösen, da wir speziell diese Sache beachtet haben, d.h. Synchronosation läuft unabhängig von der Artikelanzahl.

 

[igrimpe]

ok, hab gedacht, ihr fasst tatsächlich bei jedem sync jeden Artikel an.

Zuerstmal die Fakten:
Auf Webserver:
martikel enthält 4269 artikel, mkategorien 804 datensätze.
products und categories: 40403 und 5512
Lokal:
tartikel und tkategorie ebenfalls 4269 und 804

Es werden offensichtlich nicht alle Artikel importiert. Fehlermeldung gibt's jedoch keine und eS. log ist leer (bis auf den obligatorischen "eS:0971" Eintrag).

Was mich wundert: getArtikel liefert ja nur jeweils einen Artikel zurück? Wird also solange aufgerufen, bis kein Artikel mehr zurückgeliefert wird (alles importiert)? Wenn dann das setzen in martikel nicht funktioniert, müsste doch immer wieder derselbe Artikel zurückgeliefert werden, also müsste das ganze sich dann irgendwann in eine Endlosschleife begeben, oder nicht?

 

[igrimpe]

noch als Anmerkung: rufe ich getArticle direkt auf, kriege ich tatsächlich "0;" -> also "nichts zu tun"
Und das kann ich wegen des LEFT JOIN nicht verstehen, denn der müsste ja wirklich alles zurückliefern was noch nicht in martikel ist. Und wenn in products mehr drin sind, muss auf jeden Fall was kommen. Kommt aber nicht ...

 

[Thomas Lisson]

Schön, dass wir bei Dir auf jmd gestossen sind, der auch was von der Materie bei diesem Problem versteht - sonst wärs sehr schwer.

Auf Webserver:
martikel enthält 4269 artikel, mkategorien 804 datensätze.
products und categories: 40403 und 5512

Er hat nicht alles importiert. die 30min brauchte er also für diese 4000 Artikel - ich denke 95% der Zeit haben die Bilder in Anspruch genommen.

getArtikel liefert ja nur jeweils einen Artikel zurück? Wird also solange aufgerufen, bis kein Artikel mehr zurückgeliefert wird (alles importiert)? Wenn dann das setzen in martikel nicht funktioniert, müsste doch immer wieder derselbe Artikel zurückgeliefert werden, also müsste das ganze sich dann irgendwann in eine Endlosschleife begeben, oder nicht?

Exakt.

rufe ich getArticle direkt auf, kriege ich tatsächlich "0;" -> also "nichts zu tun"

Richtig. Und das ist eigenartig, weil 4000<40000 und der left join auf jeden Fall noch 35000 Artikel der Reihe nach rausholen sollte.

Was sagt der Browser bei getCountArtikel.php ? auch 0 ?

Sehr gerne würden wir dies debuggen. Würdest Du uns die DB zu Debugzwecken zukommen lassen? Natürlich ohne Kunden/Bestellungen etc.

 

[igrimpe]

getCountArticle = 36134
Wird also erkannt, dass noch Artikel fehlen.

Wenn ich den SELECT direkt über phpMyAdmin ausführe, funzt es übrigens (Ergebnis: 10578).


IDEEE ... gefunden
Der nächste SELECT funzt net. Für ID 10578 gibt's keine Description, also kommt der IF Block nicht und trotz vorhandenem Artikel wird 0; geliefert. Hat wohl mal irgendwann jemand manual gelöscht oder die 10577 manuell angelegt.

Ich hab mal folgende Änderung vorgenommen:

//hole einen noch nicht versandten Artikel nach eS raus
$sqlstring = 'select products.products_id from products '.
'LEFT JOIN eazysales_martikel ON products.products_id=eazysales_martikel.products_id '.
'LEFT JOIN products_description ON products.products_id=products_description.products_id '.
'WHERE (products_description.language_id='.$GLOBALS['einstellungen']->languages_id.' AND eazysales_martikel.products_id is NULL) '.
'limit 1';
$cur_query = eS_execute_query($sqlstring);

getArtikel liefert jetzt zumindest wieder was zurück. Ich werd's mal laufen lassen und meld' mich wieder (evtl muss VPE auch noch angepasst/abgefangen werden?)


Anmerkung: Aus eigener Erfahrung kann ich nur immer wieder empfehlen nicht nur die möglichen sondern grundsätzlich auch alle 'unmöglichen' Fehler abzufangen. Wenn ich jedesmal einen Euro bekommen hätte, wenn ein Kunde sagt "dieses und jenes KANN NIEMALS vorkommen", würde ich heute sicherlich Ferrari fahren

 

[Thomas Lisson]

Sehr gut.

Dies wird der Fehler gewesen sein. Man geht von einer konsistenten Datenbank (Jeder Artikel braucht eine Description) aus, aber dies ist wohl schwer zu gewährleisten bei größeren Datenbanken, die wohlmöglich schonmal ausgefallen sind oder öfters aus dem Backup kommen.

Übrigens sollte dieser Artikel ohne Descriptioneintrag auch nicht im shop zu sehen sein - es ist quasi eine Datenleiche.

(evtl muss VPE auch noch angepasst/abgefangen werden?)

Die Verpackungseinheit hat nichts damit zu tun - kannst Du ruhig vernachlässigen.

Aus eigener Erfahrung kann ich nur immer wieder empfehlen nicht nur die möglichen sondern grundsätzlich auch alle 'unmöglichen' Fehler abzufangen.

Da hast Du Recht
Wir haben uns auch ehrlich gesagt mit dem Betatest etwas erhofft, ein paar dieser "unmöglichen Fehler", die ja eigentlich keine Fehler sind, abzufangen.

 

[igrimpe]

Bei mehrsprachigen Shops könnte es schon mal vorkommen, dass Artikel nicht für die Hauptsprache existieren (könnte ja zB irgendwas sprachspezifisches ein). Wenn die nicht nach eS importiert werden -> OK. Aber die dürfen den sync natürlich nicht scheitern lassen.

 

[igrimpe]

Finally ...
Der Import aus xtC ist jetzt komplett durchgelaufen. Zwischendurch ist nochmal einer der bereits beschriebenen SQL-Fehler aufgetreten (obwohl ich den Rechner die ganze Zeit nicht angefasst habe, aber vielleicht ist ja der Virenscanner aufgepoppt oder irgendwas anderes).
Alles in allem mehrere Stunden, aber der nachfolgende Abgleich war dann tatsächlich in wenigen Sekunden durch. Insoweit sind meine Performance-Bedenken also zerstreut worden.

Falls ich am Wochenende Zeit habe, werde ich die Scripte nochmal durchgehen, um überall eine UTF8 Dekodierung (+Kodierung?) einzubauen wo nötig - clevererweise wohl per config-include gesteuert.

 

[Thomas Lisson]

Das freut mich.

der SQL-Fehler ist natürlich nicht gut - schwer zu sagen woran es liegt.

Vielen Dank für den Test!