Keim Import aus XTC304SP1

igrimpe

Aktives Mitglied
5. Juli 2006
20
0
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

Administrator
Mitarbeiter
24. März 2006
15.574
299
Köln
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
Code:
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
Code:
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

Aktives Mitglied
5. Juli 2006
20
0
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

Aktives Mitglied
5. Juli 2006
20
0
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

Administrator
Mitarbeiter
24. März 2006
15.574
299
Köln
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:

Code:
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

Aktives Mitglied
5. Juli 2006
20
0
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

Administrator
Mitarbeiter
24. März 2006
15.574
299
Köln
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

Aktives Mitglied
5. Juli 2006
20
0
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

Administrator
Mitarbeiter
24. März 2006
15.574
299
Köln
Code:
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.

Code:
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

Aktives Mitglied
5. Juli 2006
20
0
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

Aktives Mitglied
5. Juli 2006
20
0
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

Administrator
Mitarbeiter
24. März 2006
15.574
299
Köln
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

Aktives Mitglied
5. Juli 2006
20
0
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

Administrator
Mitarbeiter
24. März 2006
15.574
299
Köln
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

Aktives Mitglied
5. Juli 2006
20
0
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

Aktives Mitglied
5. Juli 2006
20
0
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.
 
Ähnliche Themen
Titel Forum Antworten Datum
Neu Umlagerung per Ameisen-Import JTL-Wawi - Fehler und Bugs 1
Neu JTL 1.8.12.0 - Artikelattribut für Shop importieren - Format CSV-Datei / Hilfe bei Import von individuellen Attributen für JTL-Shop (googlekat) JTL-Ameise - Ideen, Lob und Kritik 1
Ameisen Import von Aufträgen: Zahlungsziel in Tagen immer 0 JTL-Wawi 1.8 1
Neu Automatisierter Import Händler-CSV, Problem mit unterschiedlichen Artikeln bei gleicher EAN Schnittstellen Import / Export 7
Automatisches MHD bei Import JTL-Wawi 1.8 1
Neu Import von sonderpreisen JTL-Ameise - Fehler und Bugs 1
Neu ebay Import ohne Variantenbilder eBay-Anbindung - Fehler und Bugs 0
Beschreibung wird beim Import fehlerhaft übernommen JTL-Wawi 1.8 0
Neu Ameise - Logikfrage zum Import von Artikeln mit und ohne Varkombis gemäß Guide User helfen Usern - Fragen zu JTL-Wawi 0
Neu JTL Ameise Import von Meta-Descriptions Schnittstellen Import / Export 6
Neu Nach Import von Kundendaten aus SW5 Umleitung nach Login und weiße Seite JTL-Shop - Fehler und Bugs 5
Neu Bitte um Hilfe beim Export/Import von Attributen JTL Ameise - Eigene Exporte 0
Neu Zahlungsart beim Import ändern User helfen Usern - Fragen zu JTL-Wawi 0
Neu Mindestabnahme / Abnahmeintervall Import mittels Ameise User helfen Usern - Fragen zu JTL-Wawi 1
Neu Export & Import Lagerplätze JTL Ameise - Eigene Exporte 7
Neu Shopdaten import funktioniert nicht Shopware-Connector 2
Neu Import von Blogseiten undLandingpages von Magento Umstieg auf JTL-Shop 3
Neu CiN TrackID-Import Plugin User helfen Usern - Fragen zu JTL-Wawi 12
Label per Import bedienen JTL-Wawi 1.8 0
Neu Auftrag aus Woocommerce Import zeigt im Druck "Zahlungsziel beträgt 150 Tage ab Rechnungsdatum" User helfen Usern - Fragen zu JTL-Wawi 0
Neu Ameise Import manuell ausgeführt funktioniert, der gleiche Import über Batch Planung gestartet hat Fehler JTL-Ameise - Fehler und Bugs 2
Neu Gefahrlos Testkunden aus tkunde löschen? Umstieg auf JTL-Shop 0
Neu Kurzbeschreibung aus mehreren Zellen importieren - möglich? User helfen Usern - Fragen zu JTL-Wawi 2
Neu Daten aus getBackorderString Templates für JTL-Shop 7
Neu Nach Update auf 5.3 fliegen die Produkte aus dem Merchant Center JTL-Shop - Fehler und Bugs 0
Neu Update des JTL shops aus der Wawi funktioniert nicht Allgemeine Fragen zu JTL-Shop 1
Neu EK-Netto der Verkäufe aus Datenbank ? User helfen Usern - Fragen zu JTL-Wawi 5
Kundenattribute aus Shop übernehmen und aus Wawi zurück an Shop übermitteln Einrichtung JTL-Shop5 1
Neu Produktdaten aus Shop zur Wawi WooCommerce-Connector 9
Neu Kunden aus Wawi nicht auffindbar JTL-POS - Fehler und Bugs 4
Versuch Bilder aus Ebay für Kaufland zu übernehmen JTL-Wawi 1.8 0
Druckvorlage für Etiketten aus Auftragspositionen JTL-Wawi 1.8 4
Neu Shop in Unterverzeichnis führt dazu, dass Inhalte aus dem übergeordneten Verzeichnis im Shop gezeigt werden JTL-Shop - Fehler und Bugs 3
Rechnung zeigt Mehrwertsteuer 0% aus obwohl 7% berechnet werden - wenn UST-ID eingegeben JTL-Wawi 1.8 0
Warum sind die Rechnungen aus Aufträge(mit Rechnung(Vollständig)) nicht unter Rechnung zu finden JTL-Wawi 1.7 0
Neu Alle Produktbilder in Shopify aus JTL löschen Shopify-Connector 0
Neu Zusammenführen / Konsolidieren von Artikeln aus 2 Quellen (Amazon / Shopify) und zentrale Bestands-Verteilung an beide Systeme User helfen Usern - Fragen zu JTL-Wawi 0
Kartonage (Set) besteht aus mehreren Artikeln (Stückliste) JTL-Wawi 1.8 0
Neu Coupon einlösbar bei Mindestbestellwert aus Kategorie xy Allgemeine Fragen zu JTL-Shop 0
Neu Suche Seite 2 gibt falsche URL aus JTL-Shop - Fehler und Bugs 4
Neu NEU ✔️ PDF-Angebots-Plugin für den JTL-Shop 5 - PDF Angebote von der Produktseite oder aus dem Warenkorb heraus generieren B2C / B2B Plugins für JTL-Shop 5
Neu JTL POS übernimmt Attribute nicht aus WaWi Einrichtung / Updates von JTL-POS 2
Neu Aus bestehenden Artikeln einen Vaterartikel erzeugen. JTL-Wawi - Ideen, Lob und Kritik 0
Ausgabe per E-Mail geht plötzlich nicht mehr, Testmail aus Wawi aber schon JTL-Wawi 1.6 22
Neu erster JTL Shop - Artikelbilder aus Cloudspeicher - aber nicht in die Wawi eazybuisiness DB Allgemeine Fragen zu JTL-Shop 0
Neu Emails aus der Wawi an Gmail kommen nicht an ///SPF User helfen Usern - Fragen zu JTL-Wawi 4
In Diskussion Workflow, Wert setzen aus Zwischenablage/Clipboard JTL-Workflows - Ideen, Lob und Kritik 0
Artikel aus Auftrag entfernen, Zahlung drin lassen JTL-Wawi 1.7 0
Neu E-Mail Versandbenachrichtigung aus JTL Wawi 1.8.10.0 wird doppelt versendet User helfen Usern 0
Texte aus Webshop Datei ziehen Einrichtung JTL-Shop5 0

Ähnliche Themen