| |||
| | | |
| |
Warenwirtschaftssystem für Onlineshop-Betreiber
SchnittstellenAuch dieser für viele fast "furchterregende" Begriff sorgt mitunter dafür, dass Anwender Ihre Software verfluchen. Dabei sind allein die Programmierer dafür verantwortlich, Fehlerquellen so weit zu minimieren, dass der Begriff "Schnittstelle" möglichst das ganze Geschäftsjahr lang gar nicht genannt werden muss.Aber wie bekommt man Schnittstellen sicher? Nun, es gibt kein Geheimrezept. Das wichtigste bleibt Disziplin bei der Entwicklung. Schnittstellen müssen immer so flexibel programmiert werden, dass alle eventuellen Fehler abgefangen sind – in beiden per Schnittstelle verbundenen Systemen natürlich! Weil reibungslos funktionierende Schnittstellen so entscheidend sind, werden im Folgenden die kritischen Punkte des Themas beleuchtet. So können bei der Konstruktion die richtigen Entscheidungen getroffen werden und das Ergebnis passt besser zum jeweiligen Projekt. Standards sorgen für Stabilität und Erweiterbarkeit Oft helfen hier Standards: Hat die Warenwirtschaft XY einen Bestelldatenimport mit einer guten Dokumentation, kann der Shop-Entwickler allein 'loslegen'. Dennoch ist dabei ein guter Draht zum Entwickler beim Warenwirtschafts-Systemhaus immer von Vorteil. Ein solcher Standard – XML – kann helfen, die Datenstruktur zu vereinfachen und damit die Schnittstelle sowohl sicherer als auch einfacher erweiterbar zu machen. XML bedeutet aber auch größere Datenmengen: Hat man 1.000 Artikeldaten, die stündlich von der Warenwirtschaft zum Shop transportiert werden müssen, sind (in etwa) 15 Megabyte Daten kein Problem. Hat ein größerer Shop jedoch 50.000 Artikel, so ist das Einspielen von 0,75 Gigabyte für auch große Shopsysteme im Livebetrieb durchaus problematisch (von der Netzauslastung durch solch eine Datenmenge ganz abgesehen). Hier muss man also viel genauer planen. Teil-Aktualisierungen schonen die Ressourcen So ist es sinnvoll, beispielsweise tagsüber nur das "Delta", also die neuen und geänderten Artikel, austauschen und erst nachts zur Sicherheit einen Komplettimport durchzuführen. Schlecht ist es da, wenn ein Warenwirtschaftssystem nur Komplett-Exporte erzeugen kann. 
Für einfache Schnittstellen, über die "nur" Artikelpreise oder aktuelle Bestände überspielt werden, reichen einfache Textdateien (CSV ) völlig aus. Überträgt man Zeile für Zeile nur die Artikelnummer und den neuen Bestand, so braucht man nicht unbedingt XML. Dabei ist aber auch hier die Datenmenge nicht ganz egal: 50.000 SQL-Updates (Datenbank-Aktualisierungen) sind zwar heutzutage kein echtes Problem mehr, aber warum den Server unnötig quälen, wenn sich der Bestand nur bei 200 Artikeln geändert hat? Hier fehlt den Wawi-Systemen leider fast immer die Möglichkeit, eben nur diese 200 geänderten Datensätze zur Verfügung zu stellen. Wenn es daher nicht anders möglich ist, als Komplettimporte zu machen, kann man das Problem entschärfen, indem auf Seiten des Shops eine Verzögerung eingebaut wird, so dass die Updates nicht alle auf einmal geschrieben werden und dadurch das System zu sehr verlangsamt. Das Ziel aller Bemühungen muss es sein, den kaufenden Besucher im Shop nicht zu stören. Denn eine Eieruhr im Browser des Kunden, weil im Hintergrund die Shopdatenbank eine Belastungsspitze hat, muss schlicht ausgeschlossen werden. Welche Wege die Daten gehen Es gibt kein "Ideal", auf welchem Weg die Daten zwischen Warenwirtschaft und Shop ausgetauscht werden sollten. Die Anzahl der Möglichkeiten ist systembedingt oft begrenzt. Denn Warenwirtschaftssysteme sitzen vernünftigerweise geschützt hinter Firewalls und können daher oft nicht direkt mit dem Netz kommunizieren. Somit können aus Sicherheitsgründen dann auch Shopsysteme die Warenwirtschaft nicht direkt mit Daten füttern. Daher müssen zuerst die Sicherheitssysteme so konfiguriert werden, dass Shop und Warenwirtschaft miteinander "sprechen" können. Ist das geschafft, kann der Shop Vorgänge, beispielsweise neue Bestellungen, aktiv an die Warenwirtschaft melden. Also nicht periodisch, sondern direkt mit der Bestellung. Dies bedeutet, dass Bestellungen ohne Verzögerung in der Warenwirtschaft weiterverarbeitet werden können. Gibt die Wrenwirtschaft ihrerseits ein "OK" zurück, kann der Shop die Order als exportiert markieren. Umgekehrt genauso: kommt kein OK zurück, würde der Shop die Warenwirtschaft periodisch so lange anfragen, bis es klappt. Eine andere Möglichkeit ist, ein gemeinsames FTP-Verzeichnis zu nutzen. Hierbei sprechen die Systeme nicht direkt miteinander, sondern stellen sich gegenseitig Dateien zur Verfügung: So schreibt der Shop beispielsweise die Bestelldaten in eine Datei und speichert sie im "vereinbarten" FTP-Pfad. Die Warenwirtschaft ihrerseits schaut in periodischen Abständen dort nach, ob neue Daten vorliegen und wenn ja, nimmt sie die Daten auf. Dieses "Nachsehen" kann man oft auch über sogenannte "Trigger" aktivieren. So merkt die Warenwirtschaft es direkt, wenn neue Daten vom Shop geschrieben worden sind. Wichtig ist es, bei beiden Varianten besonders am Anfang Protokolle schreiben zu lassen. Auch sollten die importierten Daten nicht gleich gelöscht werden, sondern zunächst in einem Korb "erledigt" abgelegt werden. Das hilft bei einer Fehlersuche enorm. Letztendlich liegt es aber wirklich am Programmierer, ob er alle Eventualitäten abgefangen hat. Dabei sind auch Kleinigkeiten wichtig: Ein Schlussdatensatz bestätigt in jeder Datei bzw. bei jeder Übertragung, dass es sich um eine vollständige Datei handelt. Fehlt er, kann das Empfängersystem reagieren und melden, dass etwas nicht stimmt. Probleme gibt es auch, wenn die Nummernkreise nicht harmonieren, beispielsweise das Shopsystem (irgendwann) höhere Bestellnummern erzeugt, als Warenwirtschaften oder Steuerprogramme (z.B. DATEV) verarbeiten können. Etwaige Einschränkungen dieses Systeme sollten dann bei der Schnittstellen-Entwicklung berücksichtigt werden. So kann man diese Höchstgrenzen in den Schnittstellen fest einstellen und das Script mahnt dann früh genug per eMail an das Erreichen des Höchstwertes. Insgesamt sind – bei Berücksichtigung der genannten Punkte – Schnittstellen heute gar nicht mehr so problematisch, wie ihr Ruf einen glauben macht. Und sind erst alle "Kinderkrankheiten" behoben und die Schnittstelle läuft ein paar Wochen ohne Probleme, so meldet sie sich meist auch für viele Jahre nicht wieder... Integrierte SystemeDie optimale Lösung ist, wenn Shop und Warenwirtschaft in einem integriertem System verschmolzen sind. Diese sind im besten Fall auf die Funktionen minimiert, die alle Prozesse des jeweiligen Onlinehändlers abdecken: So muss beispielsweise nicht jeder zwingend ein Reisekostenmodul oder eine komplette Buchhaltung inhouse abbilden. Denn bei den meisten Shopbetreibern (selbst bis zu einer mittleren Größenordnung) wird die reine Buchhaltung bei einem Steuerberaterbüro abgedeckt.Eine Kombination aus Shop + Wawi ist somit – je nach Größenordnung und Bedarf – schon möglich. So bilden auch größere Online-Händler mit bis zu 50 Mio. Euro Jahresumsatz ihre kompletten Prozesse mit dem integrierten POWERGAP-System ab, ohne dabei auf eine zusätzliche Wawi-Software zurückgreifen zu müssen. Und dies schon erfolgreich seit vielen Jahren. Das spart Nerven und Zeit und damit auch Geld! Für einen reinen Onlinehändler, der Umsätze nicht aus anderen Kanälen wie z.B. mehreren stationären Ladengeschäften zusammenbringen muss, besteht im Grunde also nicht unbedingt der Bedarf, eine separate Warenwirtschafts-Software anzuschaffen.
02/2008
| | | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| © 1999-2008 FEiG & PARTNER | Nutzungsbedingungen | | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |  |  | |  | |  | |  | |  | |  | |  | |  | |   |
|
| ||
| | |
| ||
| ||
| ||
| ||
|
