Customizing eines B2B-Webshopsystems: Automatischer Import von Artikeldaten und Erweiterung der Administrationsoberfläche

Transkript

1 Diplomarbeit Customizing eines B2B-Webshopsystems: Automatischer Import von Artikeldaten und Erweiterung der Administrationsoberfläche Autor (Name)Daniel Hein Oktober 2005 Betreuung: Prof. Dr. Andreas Künkler Fachbereich Design und Informatik Fachhochschule Trier University of Applied Sciences

2 FACHHOCHSCHULE TRIER UNIVERSITY OF APPLIED SCIENCES Fachbereich DESIGN UND INFORMATIK Autor: Daniel Hein Titel: Customizing eines B2B-Webshopsystems: Automatischer Import von Artikeldaten und Erweiterung der Administrationsoberfläche Studiengang: Angewandte Informatik Betreuung: Prof. Dr. Andreas Künkler Fachbetreuung: Dr. Thomas Simon Oktober 05 Es wird hiermit der Fachhochschule Trier (University of Applied Sciences) die Erlaubnis erteilt, die Arbeit zu nicht-kommerziellen Zwecken zu verteilen und zu kopieren. Unterschrift des Autors Daniel Hein,

3 Kurzfassung In der folgenden Arbeit wird die Integration und Aktualisierung von CSV-basierten Artikeldaten in die Shoplösung der Firma Omeco beschrieben. Zunächst werden der Entwurf und die Realisierung eines CSV-Importmoduls dargestellt, um die Artikeldaten in die Webshopdatenbank einzutragen. Die Herausforderung lag dabei darin, die Zuordnung zwischen den importierten Daten und der Datenbankstruktur herzustellen, um die Datenintegrität des Webshopsystems sicherzustellen. Der zweite Teil der Arbeit analysiert die Anforderungen bezüglich der administrativen Aufgaben des Webshops für den Einsatz im B2B-Bereich. In diesem Zusammenhang werden das Präsentationsframework des Webshopbackends erläutert und die projektspezifischen Erweiterungen vorgestellt. -3-

4 4 / 86 Inhalt Customizing eines B2B-Webshopsystems: Automatischer Import von Artikeldaten und Erweiterung der Administrationsoberfläche...1 Titel: Customizing eines B2B-Webshopsystems: Automatischer Import von Artikeldaten und Erweiterung der Administrationsoberfläche Einleitung Problemstellung Voraussetzungen für einen eigenen Shop Analyse des Einsatzgebietes Aufgabenstellung und Zielsetzung Auswahl einer geeigneten Shoplösung Integration der Artikeldaten Integration zusätzlicher administrativer Aufgaben Der Artikelimport Entwurf des CSV-Importmoduls Transformation der Datensätze Beschaffung der neuen Daten Unifizierung der Daten Anlegen der Lieferanten Anlegen der Hersteller Anlegen der Kategorien Anlegen von Artikeln Preisimport Kundenmodul Analyse des Funktionsumfangs Analyse und Umsetzung der kundenbezogenen Rabattierung Ermittlung des Basispreises Kundenbezogene Preisgestaltung...41

5 5 / Artikelgebundene Kundenkonditionen Kundenobjekt als Vorlage benutzen Technische Realisierung Einbindung projektspezifischer Erweiterungen Architektur des Backends Gliederung der Views Aufbau der Controller Zugriff auf die Persistenzschicht Internationalisierung der Web-Anwendung Realisierung der Preisfindung Einstellen des Basispreises Kundenspezifische Aufschläge Kunden-Teile-Relation Kundenobjekte als Vorlage verwenden Technischer Hintergrund Die Entwicklungsumgebung Eclipse Integration von Logging- und Debugfunktionen Fazit und Ausblick Abbildungsverzeichnis Literaturverzeichnis

6 6 / 86 1Einleitung Seit dem Beginn der New Economy steigt die Bedeutung von B2B1-Plattformen für kleine und mittelständische Betriebe, um im heutigen Marktumfeld, das von Globalisierung, Vernetzung, Digitalisierung, Preisdruck und einer großen Flut von Informationen geprägt ist, mit der Konkurrenz Schritt halten zu können. Dabei vereinfachen die B2B-Applikationen nicht nur die Kommunikation im Unternehmen und mit der Außenwelt, sondern sie unterstützen auch innerbetriebliche Prozesse vom Einkauf über die Lagerverwaltung bis hin zum Verkauf. Die Migration der Daten und Prozesse in die Struktur des Unternehmens stellt dabei eine besondere Herausforderung dar. B2B-Geschäfte werden heute mehr denn je auf elektronischem Wege über den Einkauf in Internetshops abgewickelt. Die Entwicklung des E-Commerce hat sich in den letzten Jahren nach einem kurzen Einbruch zu Beginn des neuen Jahrtausends wieder erholt und wird sich, den aktuellen Marktforschungen zufolge, in den nächsten Jahren weiterhin stark steigern [heise Jan.2005]. E-Commerce ist dabei aber keineswegs ein bestimmtes technologisches System das eingekauft, implementiert und betrieben werden könnte. Es kann eher als eine Leitvorstellung verstanden werden, die sowohl eine technische als auch eine organisatorische Dimension umfasst. Die technologische Seite kann durch ein Shopsystem abgebildet werden, über das die Kundenaufträge erfasst werden. Zur Unterstützung der organisatorischen Komponente wird bereits in kleinen- und mittelständischen Unternehmen ein so genanntes ERP2 System zur Steuerung und Organisation von Betriebsabläufen eingesetzt. Die Verbindung der beiden Applikationen ist in der Regel eine individuell zu lösende Aufgabe. Zwar wurden in den vergangenen Jahren hier verschiedene standardisierte Verfahren zum Datenaustausch entwickelt, die meist auf XML-Dokumenten basieren, doch werden diese von vielen Unternehmen noch nicht genutzt. Zudem erschwert bereits die Vielzahl dieser Formate die Schaffung einer einheitlichen Schnittstelle. In diesen Bereichen werden Daten meist über konventionelle Wege ausgetauscht. XML sollte auch nicht als Allheilmittel angesehen werden. Bei Anwendungen, bei denen viele Daten bewegt werden, ist der Austausch über CSV- Dateien immer noch eine sinnvolle Alternative, da im Falle großer Datenmengen die XMLDokumente schnell auf eine unhandliche Größe anwachsen. In dieser Arbeit werden die Anpassungen zur Datenintegration über CSV-Dateien in den Artikelkatalog eines B2B-Webshops für die Firma IT-Haus GmbH beschrieben. In den folgenden beiden Kapiteln soll eine Einführung in das Fokusthema der Arbeit gegeben werden. Es werden hier Voraussetzungen zur Einführung einer neuen Webshoplösung und die Ansprüche an den neuen Webshop aufgeführt. Im vierten Kapitel geht es um die Frage, wie die Produktdaten logisch und technisch in die Shopsoftware integriert werden können. Es werden das Design und die 1 B2B ist die Abkürzung für Business-To-Business und steht allgemein für Beziehungen zwischen mindestens. zwei Unternehmen 2 Darunter versteht man ein System, das unternehmensweite Ressourcen-Planung, die z.b. Produktions-, Finanz-, Personal-, Vertriebs- und Materialwirtschaftssysteme verbindet.

7 7 / 86 Funktionsweise der neu erstellten Importroutinen beschrieben. Dabei stellt sich die Frage, wie die Artikeldaten transformiert werden müssen, um die Datenintegrität des Shopsystems zu gewährleisten. Im darauf folgenden Teil der Arbeit wird eine Analyse der Anforderungen an den B2B-Webshop und die realisierten Änderungen dargestellt. Anschließend wird der Entwurf des Backends erklärt, um die Implementierung der Erweitungen verständlich darstellen zu können. Im letzten Kapitel werden die verwendeten Technologien beschrieben, die bei der Realisierung des Projektes sehr hilfreich waren. Abschließend wird ein Resümee gezogen, wobei ein bewertender Vergleich der jeweiligen Techniken gezogen wird. Es werden Beispiele für die Erweiterung des Funktionsumfangs aufgezählt, durch die der Webshop sinnvoll ergänzt werden könnte.

8 8 / 86 2Problemstellung Die Integration eines Shopsystems in die Geschäftsprozesse eines Unternehmens erfordert die Anpassung an vielen Stellen. Um eine Integration in die Prozesse des Unternehmens umzusetzen, ist eine Anbindung des Shopsystems an die strategischen Unternehmensapplikationen notwendig. Sehr häufig sind es gerade diese Integrationsansätze, die Geschäftsapplikationen erfolgreich machen. Um langfristig den Absatz über E-Commerce anzukurbeln, ist eine starke Individualisierung im Bereich der kundenbezogenen Geschäftsbedingungen notwendig. Oft werden Kundenbeziehungen in Unternehmen über Customer Relationship Management (CRM) Systeme unterstützt. Zur Unterstützung der organisatorischen Komponente werden in Unternehmen ERP-Systeme eingesetzt. Bestellungen, die über den Shop ausgelöst werden, müssen daher an die Auftragserfassung des ERP-Systems durchgereicht werden, wo sie gegebenenfalls nochmals geprüft werden. Um Aussagen über Verfügbarkeit und Preis treffen zu können, ist eine Anbindung des Shopsystems an die Materialwirtschaft notwendig. Hier wird der Artikelbestand der im ERP-System angelegten Artikel mit dem Artikelangebot des Webshops verknüpft. In sehr tief integrierten Shoplösungen können der Status der Bestellung, sowie die Rechnungsabwicklung online verfolgt werden. Hier ist die zusätzliche Verknüpfung des Shopsystems mit den Teilen Logistik und Finanzbuchhaltung realisiert. Bei der Verknüpfung des Webshops mit den Prozessen des ERP-Systems liegt die Aufgabe in der Übertragung der Daten und der entsprechenden semantischen Darstellung für das Zielsystem, um die Datenintegrität des Systems sicherzustellen. Abb Integration des Webshops in die Unternehmensprozesse

9 9 / 86 Diese Voraussetzungen sind im Allgemeinen bei einer Mietlösung nicht gegeben. Zu Beginn der Diplomarbeit betrieb die Firma IT-Haus bereits einen Shop für Druckerverbrauchsmaterial. Dieses System basierte auf einer angemieteten Shoplösung der Firma Kompashop [kompashop], eines Dienstleistungsunternehmens, das in Zusammenarbeit mit seinem Partner UFP [ufp] eine ganzheitliche Shopmietlösung für Druckerverbrauchsmaterial anbietet. Da eine Mietlösung in der Regel nicht den individuellen Anforderungen eines Unternehmens angepasst werden kann, blieb nur die Anschaffung eines eigenen Shopsystems, das nach eigenen Wünschen und Vorstellungen gestaltet und in die Unternehmenssoftware integriert werden kann. 2.1Voraussetzungen für einen eigenen Shop Ein eigenes Shopsystem zu betreiben setzt allerdings voraus, dass im Vorfeld eine gewisse Grundlage dafür geschaffen werden muss. Neben aktuellen Preislisten für Artikel, müssen auch Produktinformationen, wie Artikelbeschreibungen und Artikelbilder, vorhanden sein. Diese Basis wurde bereits im Vorfeld mit der Realisierung des intern genutzten V-Tools3 geschaffen. Die Artikeldaten für den Hardwarebereich werden von der Firma CNET [cnet] bezogen. Diese Daten können über einen Kundenzugang auf dem FTP-Server der Firma CNET wöchentlich aktualisiert werden. Die Qualität der eingekauften Artikeldaten ist im Allgemeinen sehr gut und basiert auf einem ausgereiften Datenschema. Das Angebot der Daten soll laut Plänen der Firma CNET in unbestimmter Zeit auch im Bereich Druckerverbrauchsmaterial weiter ausgebaut werden. Aus diesem Grund werden die CNET-Daten als Grundlage für den Shop genutzt. Während die Versorgung mit Hardwaredaten dadurch sichergestellt wurde, war der Bezug der Verbrauchsmaterialdaten noch nicht zufrieden stellend abgesichert. Anfangs ging man davon aus, dass die Artikeldaten über die XML-Schnittstelle der Firma Kompashop in den Webshop eingebunden werden könnten, so wie es bereits für das VTool realisiert wurde. Nach anfänglichem Zögern wurde aber entschieden, dass sich diese Quelle wegen der daraus ergebenen Abhängigkeiten von einem Fremdsystem hinsichtlich Zuverlässigkeit, Performance und Beständigkeit nicht für den Einsatz im Shop eignet. Es konnte schließlich eine Lösung mit der Firma Kompashop gefunden werden, die den Bezug der Artikeldaten über CSV-Dateien4 sicherstellte. 2.2Analyse des Einsatzgebietes Vor Einführung einer neuen Unternehmenssoftware steht die Analyse und Auswahl der geeigneten Software. Die Anforderungen wurden dabei im Vorfeld durch die Geschäftsführung und der Arbeitsgruppe Shop zusammengestellt, die von kaufmänni3 Das V-Tool, Kurzform für Vertriebstool, ist ein von der Firma IT-Haus realisiertes Webfrontend, über das die Preislisten der Lieferanten zur Unterstützung der Vertriebsmitarbeiter bei ihrem Tagesgeschäft aufbereitet dargestellt werden. 4 CSV-Dateien sind einfache strukturierte Textdateien, deren Inhalte durch Trennzeichen voneinander separiert werden. Die Abkürzung CSV steht dabei für Characater Separated Values oder Comma Separated Values.

10 10 / 86 schen Mitarbeitern der Firma IT-Haus gebildet wurde. Das Ergebnis dieser Arbeitsgruppe wurde in einem Pflichtenheft festgehalten, das die gewünschten Navigationsmerkmale und Personalisierungskriterien zusammenfasste, die aus kaufmännischer Sicht für ein Shopsystem ausschlaggebend sind. Im Rahmen der geplanten Einführung eines Shopsystems standen dabei die Optionen zur Auswahl, eine Eigenentwicklung umzusetzen oder eine Shoplösung eines Anbieters einzukaufen und nach eigenen Vorstellungen zu erweitern. Vom Einsatz eines Out-of-the-Box Shopsystems, das nicht mehr oder nur in geringem Maße erweiterbar ist, sah man ganz ab. Die im Pflichtenheft festgehaltenen Ansprüche, wie Personalisierung des Shops für einen Kunden und die Anbindung an das eigene Warenwirtschaftssystem, können natürlich am besten durch eine Eigenentwicklung realisiert werden. Allerdings sprachen die lange Entwicklungszeit und der hohe personelle Aufwand dagegen, so dass die Entscheidung für die zweite Möglichkeit schnell gefallen war. Im Vorfeld wurde der gesamte Artikelstamm auf Artikel geschätzt, die im Shop verwaltet werden sollen und somit von einem Shopsystem mittlerer Größe, also noch nicht im High-End Bereich, bewältigt werden können.

11 11 / 86 3Aufgabenstellung und Zielsetzung 3.1Auswahl einer geeigneten Shoplösung Die Auswahl einer geeigneten Shoplösung ist alles andere als trivial. Der Markt ist in diesem Bereich nahezu unüberschaubar: Die Palette reicht vom einfachen OpenSource-Shop über Out-of-the-Box Standardlösungen im mittleren Preissegment bis hin zu E-Commerce-Suiten mit horrenden Lizenzkosten. Die in diesem Rahmen untersuchten Shoplösungen basierten dabei im Wesentlichen auf den Technologien PHP und JSP, wobei derzeit die überwiegende Mehrheit der Shoplösungen in PHP realisiert ist. Die etwas in die Jahre gekommene CGI-Schnittstelle wurde dabei von keinem der betrachteten Anbieter mehr benutzt. Kriterien zur Auswahl eines Shopsystems müssen dabei individuell auf die Bedürfnisse der Firma abgestimmt sein. Neben Sicherheitsaspekten und intuitiver Bedienbarkeit, sollte die Investition auch Beständigkeit und Updatefähigkeit berücksichtigen. Außerdem sollte das Webshoppaket durch ein Managertool abgerundet werden, über das die täglichen Verkaufs- und Marketingmaßnahmen von einem kaufmännischen Mitarbeiter selbst übernommen werden können. Mit einer grafischen Benutzeroberfläche ausgestattet, soll die Pflege des Warenkatalogs und der Kundendaten so leicht wie möglich sein. Idealerweise sollen Schnittstellen zu allen gängigen Datenaustauschformaten existieren. Bei der Darstellung und dem Vergleich des gebotenen Funktionsumfangs waren dabei die praktischen Beispiele, in Form von Demoshops, besonders hilfreich. Von den betrachteten Shopsystemen konnte aber kaum ein System allen Wünschen hundertprozentig gerecht werden. Nach Begutachten verschiedener Anbieter gefiel das Shopsystem der Firma Omeco am besten. Über die Demoversion konnte sich hier ein umfassendes Bild gemacht werden, wie der Shop zu bedienen ist. Durch die Umsetzung aktueller Standards und Richtlinien werden wichtige Sicherheitsaspekte berücksichtigt. Als Alleinstellungsmerkmal wurde in dieser Shoplösung die PHP-Einstellung register globals off verwendet, die ein Einschleusen schädlicher Codeteile über die URL verhindert. Neben zusätzlichen Modulen, wie einer Exportschnittstelle ins BME-Cat Format5 oder dem Cross-Selling6 Modul, beinhaltete das Angebot des Anbieters aus Kaiserslautern auch den Quelltext des Shopsystems, sodass vielfältige Erweiterungsmöglichkeiten durch Eigenprogrammierung problemlos umgesetzt werden konnten. Der Omeco-Webshop wird in die beiden Bereiche Frontend und Backend gegliedert, die auf einer gemeinsamen Datenbank arbeiten. Das Frontend, als eigentlicher Shop zum Kunden hin offen, präsentiert die angebotenen Artikel und ermöglicht es dem Kunden, Bestellungen über ein Warenkorbsystem 5 Ein vom Deutschen Bundesverband für Materialwirtschaft und Einkauf in Zusammenarbeit mit dem Frauenhofer IOA, der Universität Essen und zahlreicher namhafter Unternehmen definiertes Dateiaustauschformat. Dieses bietet zahlreiche Möglichkeiten zur Produktbeschreibung und ist derzeit einer der wichtigsten Standards für den Austausch von Katalogdateien [BMECat 2005]. 6 Über Cross-Selling werden Produktzusammenhänge und Abhängigkeiten im Onlineshop abgebildet. Zu jedem Produkt werden Variationen des Produkts sowie das passende Zubehör tabellarisch angezeigt. Die Produkt- und Zubehörauswahl gestaltet sich daher äußerst einfach und schnell.

12 12 / 86 abzuwickeln. Das Backend ist eine eigenständige Applikation, die für die administrativen Aufgaben im Webshop zuständig ist. Zum Funktionsumfang des Backends gehören die Systemverwaltung zur zentralen Steuerung des Onlineshops, die Kundenverwaltung, die Produktgruppenverwaltung, die Artikelverwaltung sowie die Bestellverwaltung. Die neue Shoplösung soll die beiden Vertriebsbereiche der IT-Haus GmbH, den Hardware- und den Verbrauchsmaterialvertrieb, in einem System abbilden. 3.2Integration der Artikeldaten Die Integration der Artikeldaten für den Vertriebsbereich Supplies ist ein komplexer Vorgang, der sich durch den Import heterogener CSV-Dateien unterschiedlicher Herkunft auszeichnet. Der Import in das Datenbanksystem setzt dabei voraus, dass die vom System vorgegebene Struktur der Daten eingehalten wird. Bei der Datenintegration von Fremddaten in ein anderes System sind in der Regel Konvertierungen der Datensätze notwendig. Die Daten des Shopsystems werden in einer relationalen Datenbank verwaltet. Die Datenbankstruktur des Omeco Webshop 3.0 ist sehr komplex und aus den vorausgehenden Versionen gewachsen. Zum Import der Artikeldaten musste deshalb die Struktur der Datenbank analysiert werden, um zu verstehen, wie die neuen Daten eingetragen werden müssen, damit die Datenintegrität des Shopsystems erhalten werden kann. Zudem musste beim Importvorgang berücksichtigt werden, dass Artikel aus verschiedenen Quellen im Shop angelegt werden sollen, so dass es zu Überschneidungen oder mehrdeutigen Einträgen kommen kann. Um das Anlegen redundanter Einträge zu vermeiden, müssen die Daten unifiziert werden. Die Herkunft der Daten soll dabei aber immer noch ersichtlich sein, weil dies für weitere Vorgänge, wie zum Beispiel bei der Artikelpflege, eine wichtige Rolle spielt. Entscheidend für einen Shop ist die Aktualität seiner Daten. Um die Artikeldaten zu pflegen, mussten Lösungen entwickelt werden, wie neue Daten integriert und bestehende Daten aktualisiert werden können.

13 13 / Integration zusätzlicher administrativer Aufgaben Das Backend des Webshops basiert auf dem Grundgerüst der J2EE7 Presentation Layer Technologien JSP und Servlets. Das Präsentationsframework führt dabei die Informationen aus der Businessschicht und den Benutzereingaben zusammen. J2EE stellt dabei selbst kein Präsentationsframework dar. In den letzten Jahren haben sich hier unterschiedliche Frameworks entwickelt, von denen besonders das Struts-Framework8 weit verbreitet ist. Um Erweiterungen an einem Framework vornehmen zu können, ist ein Verständnis und eine Analyse der Konzepte, die dabei umgesetzt wurden, zwingend erforderlich. Im Rahmen dieser Arbeit musste das Framework des Omeco-Backends um eigene Funktionen, besonders in der Kundenverwaltung, erweitert werden, was grundlegende Kenntnisse des verwendeten Frameworks voraussetzt. Wegen der intensiven Kundenbeziehung im B2B-Bereich soll die Kundenverwaltung um eine flexible Kalkulationsmatrix für kundenspezifische Konditionsmodelle erweitert werden. Dabei muss die individuelle Erweiterung streng nach dem Softwaredesign der Firma Omeco umgesetzt werden, um die Updatefähigkeit der Applikation zu gewährleisten [schulung]. Die Preisgestaltung, wie sie im Standardshop umgesetzt wurde, ist für den Einsatz im B2B-Bereich nicht fein genug. Es soll möglich sein, für jeden Kunden eine individuelle Preisberechnung einzustellen. Dabei ist eine Lösung zu finden, wie die Einstellungen möglichst effizient über eine Menge von Artikeln vorgenommen werden können und nicht jeder Preis einzeln einzutragen ist, wie es im Standard des OmecoWebshops vorgesehen ist. Im Vergleich zu einem B2C-Webshop9 ist beispielsweise die Zahlungsabwicklung eines B2B-Webshops aber wesentlich einfacher, da hier Zahlungsmittel wie z.b. Kreditkarte oder Lieferung per Nachname eher die Ausnahmen sind. 7 J2EE (Java 2 Enterprise Edition): Industriestandard für plattformunabhängige, webbasierte Anwendungen 8 Struts ist ein Open-Source-Framework aus dem Jakarta Projekt und wird als Präsentationsschicht von Java-Web-Anwendungen eingesetzt [struts] 9 B2C ist die Abkürzung für Business to Customer und steht für die Beziehung vom Unternehmen zum Kunden

14 14 / 86 4Der Artikelimport Die einfachste Art des Datenaustauschs ist der Austausch über CSV-Dateien. Dieses Format ist leicht zu generieren und weit verbreitet. Allerdings handelt es sich bei dem Character Separated- oder Comma Separated Value-Dateiformat um ein nichtstandartisiertes Format, das in vielen Varianten existiert, wie bereits die nicht eindeutige Bezeichnung vermuten lässt. Welches Trennzeichen dabei zur Trennung der einzelnen Werte benutzt wird, ist nicht vorgeschrieben. Außerdem können die einzelnen Werte in Hochkommata oder sonstige Zeichen eingeschlossen sein. Der verwendete Zeilenumbruch hängt dabei auch sehr stark vom verwendeten Betriebssystem ab. In vielen Fällen wird auf die Bedeutung der Spalten durch Spaltenüberschriften hingewiesen, die beim Import, zum Beispiel in eine Datenbanktabelle, ausgelassen werden müssen. Um eine flexible Integrationsmöglichkeit für CSV-Dateien in das Shopsystem zu schaffen, wurde für den Import ein Modul erstellt, das sich an die Anforderungen der verschiedenen Dateien anpassen lässt. Als Grundlage dieses Moduls wurde das, von der Firma Omeco bereits entwickelte, Importmodul genommen, erweitert und umgebaut, um den neuen Anforderungen gerecht zu werden. Dieses Modul war nicht Bestandteil des Shops, sondern noch im experimentellen Stadium. Die Java-Klassen dieses Moduls aus dem Package de.omeco.webshop.business.util waren ursprünglich nur für den initialen Datenimport aus CSV-Dateien gedacht, die genau auf die Datenbankstruktur des Webshops abgestimmt waren. Das Importmodul der Artikeldaten für den Bereich Verbrauchsmaterial muss während des Importvorgangs die Daten durch einen Transformationsvorgang auf die Datenbankstruktur des Webshops abstimmen. Der Importprozess kann dabei nicht durch den Webserver ausgeführt werden, weil Prozesse, die zu lange dauern, vom Webserver durch ein Timeout abgebrochen werden. Aus diesem Grund konnte das Importmodul nicht im Backend integriert werden, sondern wurde als eigenständiges Modul entworfen. Weil die CSV-Dateien nicht alle Informationen enthalten, die zum Füllen eines Datensatzes notwendig sind, müssen die Informationen aus mehreren CSV-Dateien ergänzt werden. Als Folge dieser Vorgehensweise ergibt sich ein fester Ablauf des Importvorgangs, bei dem die Daten des vorherigen Imports durch den nächsten Importschritt ergänzt oder verwendet werden.

15 15 / Entwurf des CSV-Importmoduls Zum Einspielen in die Datenbank müssen die CSV-Dateien geparst werden. Der dafür entworfene Parser arbeitet nach dem Erzeuger-Verbraucher-Muster mit einem gemeinsamen Puffer, um auch CSV-Dateien mit mehreren tausend Einträgen verarbeiten zu können. Eine nicht-gepufferte Lösung würde bei großen CSV-Dateien einen java.lang.outofmemoryerror hervorrufen, da die Java-Objekte, die mit diesen Daten gefüllt werden, komplett im Speicher verwaltet werden und der Heap10 der JavaVirtualMachine (JVM) auf 64 MB begrenzt ist. Den maximalen Heap-Speicher der JVM über die Parameter Xmx512m auf beispielsweise 512 MB zu vergrößern, würde nur eine temporäre Lösung des Problems bedeuten, aber die Flexibilität des Parsers weiterhin einschränken. Der Importprozess wird über die main()-methode der Klasse CSVImport gestartet. Als Argumente müssen der Pfad zur Konfigurationsdatei, die einzulesende CSVDatei und die Mapping-Datei angegeben werden (vgl. Beispiel 2). Die einzulesende Datei wird von der Klasse CSVProducer zeilenweise verarbeitet. Als Argumente müssen im Konstruktor der absolute Pfad zur Datei und das Trennzeichen der CSV-Datei übergeben werden. Diese Argumente werden von der Klasse CSVImport aus der zentralen Konfigurationsdatei CSVImport.properties ausgelesen und über ein java.util. Properties-Objekt dem Konstruktor der Klasse CSVProducer mitgegeben. Beispiel 1: Auszug aus der Konfigurationsdatei #################################### ## Verzeichnisse #################################### CSV_BASE_DIR=C:/develop/Supplies/0905 MAPPINGFILES_BASE_DIR=C:/eclipse2.1/workspace/CSVImport/xml ###################################### ## Parsereinstellungen ###################################### CSV_SEPARATOR_CHAR=; CSV_QUOTE_CHAR=" CSV_ESCAPE_CHAR=" HAS_HEADER_FILEDS=true START_WITH_LINE_NUMBER=0 ####################################### ## Datenbank ####################################### DB=webshop3 DBHOST=localhost DBUSER=root DBPWD= 10 Der dynamische Speicher, auch Heap (engl. für Halde, Haufen) oder Freispeicher ist ein Speicherbereich, aus dem zur Laufzeit eines Programmes zusammenhängende Speicherabschnitte angefordert und in beliebiger Reihenfolge wieder freigegeben werden können [wiki 2005].

16 16 / 86 Die Einträge einer CSV-Datei werden zeilenweise geparst. Jede Zeile wird als Objekt vom Typ CSVRow dargestellt, wobei die Werte in einer ArrayList verwaltet werden. Als Container für die CSVRow-Objekte dient die Klasse ParsedCSVFile. Es werden jeweils 1000 Zeilen aus der CSV-Datei gelesen und in einem ParsedCSVFileObjekt abgelegt. Für größere CSV-Dateien werden mehrere dieser Objekte in dem CSVBuffer-Objekt vom Erzeuger abgelegt. Diese Klasse realisiert die Pipe des Erzeuger-Verbraucher Entwurfsmusters und synchronisiert den Zugriff der beiden Threads [Esser 2001]. Der Thread CSVConsumer wartet nach dem Start, bis er vom Puffer benachrichtigt wird, dass ParsedCSVFile-Objekte zum Abholen bereitstehen. Diese übergibt er dann an den Datenbankwrapper, der die Datensätze in die Datenbanktabellen einträgt. Zum Eintragen in die Datenbank werden mehrere Wrapper-Klassen bereitgestellt, die von der Klasse CSVBasisWrapper abgeleitet sind. Der Consumer-Thread blockiert so lange, bis der Wrapper die Einträge in die Datenbank geschrieben hat. Anschließend kann der Producer die nächsten CSV-Einträge als ParsedCSVFile liefern. Die erste Zeile einer CSV-Datei ist für den Parser ausschlaggebend, wie viele Spalten in der Datei enthalten sind. Wird während des Parsens eine Zeile gefunden, die mehr oder weniger Spalten enthält, löst diese eine Exception aus. Der Grund einer solchen Unregelmäßigkeit kann darin liegen, dass durch manuelles Editieren fehlerhafte Einträge erzeugt wurden oder dass ungünstige Werte eingetragen wurden, die zufälligerweise das Trennzeichen der Datei enthalten, so dass ein Wert mehr in der Zeile steht als vorgesehen war. Solche Zeilen werden vom Parser ignoriert und als Fehlermeldung ausgegeben. Alle Datenbankwrapper-Objekte implementieren die Methode convert(), durch die die Transformationen und das Schreiben der Daten in die Datenbank ausgeführt werden. Diese Methode ist je nach Wrapper unterschiedlich implementiert. In der Basisklasse CSVBasisWrapper werden bereits einige Funktionen, wie beispielsweise adjustdataformat oder getvalue4currentrow implementiert, so dass diese in den abgeleiteten Klassen zu Verarbeitung der Datensätze benutzt werden können und dort nur noch die logischen Beziehungen in Form der Relationen der Datensätze in der Implementierung umgesetzt werden muss, um die Datenintegrität des Datenbankmodells sicherzustellen.

17 17 / 86 Abb zeigt eine schematisierte Übersicht der Datenbankwrapper des Importmoduls. Abb schematisiertes Klassendiagramm der DatenbankWrapper 4.2Transformation der Datensätze Bevor die Daten in die Tabellen eingetragen werden können, muss bestimmt werden, wohin die Einträge geschrieben werden sollen. Um die Daten in die Shoptabellen einzutragen, wird eine Mappingdatei benötigt, die angibt, welche Spalten der CSV-Datei in welche Tabelle eingetragen werden sollen. Dabei können mehrere CSV-Spalten zu einer Datenbanktabellenspalte zusammengefasst werden oder eine Spalte in mehrere Tabellen eingetragen werden. In besonderen Fällen müssen die Informationen aus CSV-Dateien ergänzt werden, die andere Schlüsselbezeichner verwenden, wie beispielsweise für die Artikelbeschreibung, die aus der Preislistendatei des Kompashop-Shopsystems stammt und als Bezeichner eine UFP- eigene ID verwendet. In diesem Fall muss die Beziehung zu den Shopdatenbankeinträgen über eine Mappingtabelle hergestellt werden. Um diese Transformation bereits beim Datenimport flexibel durchführen zu können, wird der passende Datenbankwrapper zur Laufzeit geladen. Die zu verwendende Wrapperklasse wird über die zentrale Konfigurationsdatei CSVImport.properties festgelegt. Der Name der XML-Mappingdatei ist dabei der Schlüssel für die zu ladende Klasse. Beispiel 2: Aufruf des Herstellerimports Shell> java de.ithaus.csvmodul.csvimport -config. -csv PRODUCER.CSV -mapping Supplies_Producer.xml

18 Beispiel 3: Zuordnung 18 / 86 der Datenbankwrapper zur CSVImport.properties Konfigurationsdatei Mappingdatei in der ####################################### ## Datenbankwrapper ####################################### # Wrapper,die auf OMECO-Tabellen mappen Supplies_Categories=de.ithaus.persistence.SuppliesCSVCategoriesWrapper Supplies_Producer=de.ithaus.persistence.SuppliesCSVHerstellerWrapper Supplies_Artikel=de.ithaus.persistence.SuppliesCSVArtikelWrapper Das objektrelationale Mapping, das durch diese Dateien festgelegt wird, beschreibt dabei, welche Einträge der CSV-Datei in welche Tabellen und die dazugehörenden Spalten eingetragen werden sollen. Anders als bei den bekannten O/R-MappingFrameworks, wie zum Beispiel dem OpenSource-Projekt Hibernate11, geschieht das Mapping nicht über spezielle Businessobjekte, deren Attribute auf Tabellenspalten gemappt werden, sondern etwas allgemeiner über die Klassenstruktur, wie sie in Abb dargestellt wird. Die Mappingdateien werden von einem SAX-Parser eingelesen und als Objekte vom Typ TableCSVMap in einer java.util.arraylist dem Datenbankwrapper übergeben. Der Datenbankwrapper kann dadurch entscheiden, welche Werte in welche Tabellenspalten eingetragen werden sollen. 11 Hibernate ist ein Open-Source-Persistenz-Framework für Java, über das der Zustand eines Objektes in einer relationalen Datenbank gespeichert werden kann [hibernate].

19 Abb Klassendiagramm CSVImport-Modul 19 / 86

20 20 / 86 In der XML-Mappingdatei wird die Beziehung zwischen Datenbanktabellen und CSV-Datei definiert. Das Tag <csv-import> ist die Wurzel des XML-Dokuments. Als Attribut kann hier hasheader=true false eingetragen werden. Durch diese Angabe wird dem Wrapper vermittelt, ob er über den Spaltennamen oder den Spaltenindex den Eintrag aus dem ParsedCSVFile-Objekt suchen soll. Eine Tabelle wird über das Tag <csv-map> dargestellt, wobei der Wert des nächsten Elements <dest-tablename> den Namen der Datenbanktabelle definiert. Jede zu füllende Tabellenspalte wird durch das Element <table-field> repräsentiert. Als Attribut für das Element <table-field> muss der Datentyp des Datenbankfeldes angegeben werden. Es wird hier zwischen den Datentypen: VARCHAR, INTEGER, DECIMAL und TIMESTAMP unterschieden. Durch die Angabe des Datentyps kann in den Wrappern das SQL-Statement mit der richtigen Syntax erstellt werden. Beispielsweise müssen Zeichenketten in Hochkommata eingeschlossen werden oder Datumseinträge vom Format dd.mm.yyyy in das Datenformat Timestamp yyyy-mm-dd HH:mm:ss konvertiert werden. Die Datenbanktabellen werden in der Reihenfolge gefüllt, die durch die Reihenfolge der Tags <csv-map> in der Mappingdatei festgelegt sind. Die Mappingdateien können mehrere Tabelleneinträge enthalten, beziehen sich aber immer nur auf eine CSV-Datei. Die Zuordnung, die in der Mappingdatei festgehalten wird, wird durch ein Objekt vom Typ TableCSVMap repräsentiert. TableCSVMap-Objekte ordnen die CSV-Einträge einer Datenbanktabelle zu. Diese Zuordnungen der Tabellenspalten zu den Spalten einer CSV-Datei werden durch Objekte vom Typ CSVValue definiert, die im Objekt TableCSVMap in einer HashMap gespeichert werden. Als Schlüssel für diese Einträge werden die Tabellenspaltennamen der Datenbanktabellenspalten verwendet. Die CSVValue-Objekte repräsentieren jeweils eine der in der XML-Datei eingetragenen Zuordnungen. Über diese Objekte werden die CSV-Spalten den Tabellenspalten zugeordnet. Durch sie wird der erwartete Datentyp für die Generierung des SQLStatements im Wrapper festgelegt. Weiterhin kann über das Attribut type festgelegt werden, wie der aktuelle Wert für den Eintrag in die Datenbanktabelle modifiziert werden soll. Dieses Attribut wird in der XML-Datei durch den Wert des Attributs des Tags <source> festgelegt. Als Attribut für das Tag <source> können csv, constant oder complex angegeben werden. Wenn das Attribut type=csv gesetzt ist, wird der Wert aus dem Objekt ParsedCSVFile ermittelt. Wenn das Attribut type=constant gesetzt ist, wird der hier eingetragene Wert für alle Einträge verwendet. Ist der Typ auf complex gesetzt bedeutet dies, dass dieser Datenbankeintrag vorher durch einen definierten Filter transformiert werden soll. Diese Filter können als Attribute filter=... des Tags <source> über den vollqualifizierten Klassenbezeichner der Filterklasse zur Unterstützung des Datenbankwrappers zusätzlich integriert werden. Die Filterklassen realisieren eine zusätzliche Logik. Sie werden beispielsweise dazu verwendet, einen einzutragenden Wert aus der CSV-Datei vorher zu modifizieren oder einen Eintrag aus zwei Spalten zusammenzusetzen. Die Filterklassen müssen dafür von der abstrakten Klasse Filter abgeleitet werden, so dass in den Wrapper-Objekten auf diesen Typ gecastet werden kann.

21 Beispiel 4: DTD für die Mappingdateien <?xml version="1.0" encoding="utf-8"?> <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ATTLIST <!ATTLIST csv-import (csv-map+)> csv-map (dest-tablename,table-key+,table-field+)> dest-tablename (#PCDATA)> table-key (source)> table-field (source)> source (#PCDATA)> csv-import hasheader (true false) "true"> table-key name CDATA #REQUIRED type (VARCHAR INTEGER DECIMAL TIMESTAMP) #REQUIRED> <!ATTLIST table-field name CDATA #REQUIRED type (VARCHAR INTEGER DECIMAL TIMESTAMP)#REQUIRED> <!ATTLIST source type (csv complex constant) #REQUIRED const-value CDATA #IMPLIED filter CDATA #IMPLIED> In Beispiel 5 wird dargestellt, wie die Werte im Wrapper ermittelt werden. Beispiel 5: Implementierung der Methode getvalue4currentrow if (csvvalue.gettype() == CSVValue.TYPE_CONSTANT) { csventry = "" + csvvalue.getconstvalue(); csventry = adjustdataformat(csvvalue,csventry); } else if(csvvalue.gettype()== CSVValue.TYPE_COMPLEX) { Filter filter = (Filter)csvValue.getFilterClass(); filter.setconnection(con); filter.setcurrentrow(currentcsvrow); filter.setparsedcsvfile(csv); csventry = filter.filter(csvvalue); csventry = ""+adjustdataformat(csvvalue,csventry); } else { csventry = csv.getvalue(currentcsvrow, csvvalue.getname().trim()); } return csventry; 21 / 86

22 22 / Beschaffung der neuen Daten Die Artikeldaten werden monatlich aktuell auf FTP-Verzeichnissen zum Download bereitgestellt. Um Prozesse automatisch zu starten, kann unter Linux/UnixUmgebungen der cron-prozess eingestellt werden. Dieser Prozess wird beim Systemstart automatisch gestartet. Er wird einmal pro Minute aktiv und liest aus der Datei /etc/crontab, welcher Job als nächstes ausgeführt werden soll. Alternativ können aber auch Benutzer ihre eigenen cron-jobs definieren. Dazu braucht der User das Recht, cron-kommandos auszuführen. Die benutzerdefinierten cron-jobs werden je nach Distribution in unterschiedlichen Pfaden abgelegt. Bei der hier verwendeten Distribution Suse Linux Enterprise Edition 9.x befindet sich dieses Verzeichnis unter /var /spool /cron. Damit der cron-deamon seine Aufträge versteht, müssen diese in einer fest vorgegebenen Syntax angelegt werden. Beispielsweise führt folgender Eintrag das Preislistenimportskript als Benutzer xy jeden Morgen um 8.10 Uhr aus und speichert die Ausgaben des Shellskriptes in der Datei /data/log/preise.log. Fünf Minuten später ist der Vorgang abgeschlossen und es wird eine Mail mit der Log-Datei des Preisimports an den Shopadministrator von ITHaus gesendet. Beispiel 6: Aufträge vom cron-deamon ausführen lassen #Min Hr Day Month WeekDay user Job # # Preislistenupdate jeden Tag um * * * xy /data/cron/preisimport.sh > /data/log/preise.log # Erfolg an administrator 15 8 * * * xy mail s Log shop@it-thaus.com < /data/log/preise.log Etwas Verwirrung schafft die Ausführung von benutzerdefinierten Kommandos. Wenn, wie in diesem Fall, ein Skript ausgeführt werden soll, das einen Javaprozess startet, muss dazu der CLASSPATH als Umgebungsvariable und JAVA_HOME/bin im Pfad vorhanden sein. Auch wenn der Prozess unter dem Benutzer xy ausgeführt wird, so sind die Umgebungsvariablen nicht wie gewohnt gesetzt. Aus diesem Grund werden die Umgebungsvariablen in jedem Shellskript nochmals ausdrücklich gesetzt. In Tabelle 1 werden weitere Umgebungsvariablen aufgezeigt, die typischerweise für den crondeamon eingestellt werden.

23 23 / 86 Umgebungsvariablen in cron-tabellen Umgebungsvariable Beschreibung MAILTO Normalerweise schickt cron sämtlichen Output per an den auftraggebenden Benutzer. MAILTO definiert einen anderen Empfänger. Pfad, in dem nach von cron auszuführenden Kommandos gesucht wird. Default ist /usr/local/bin:/usr/bin:/bin:. PATH Achtung: Setzt man PATH in der persönlichen crontab, wird dieser Wert vollständig überschrieben; Anhängen funktioniert nicht. SHELL Beispiel MAILTO=tux,harry #Der Output der #folgenden #Cronjobs geht jetzt #per Mail an die User #tux und harry... MAILTO="" #... und jetzt an # niemanden mehr. PATH=$PATH:/home/tux/bin #$PATH wird _nicht_ #expandiert; #es werden nunmehr #nur Kommandos aus #/home/tux/bin gefunden. Shell, in der die Kommandos ausgeführt SHELL=/usr/bin/tcsh werden sollen. #Statt /bin/sh wird Default ist /bin/sh #die tcsh verwendet. Tab 1: Umgebungsvariablen in cron-tabellen Durch das Modul de.ithaus.ftpsyn können die Daten von den FTP-Servern abgeholt werden. Das Herunterladen über FTP hätte man sicherlich auch über Tools wie wget12 realisieren können. Es bestand aber der Anspruch, zur Aktualisierung der Artikelbilder ein FTP-Programm zu benutzen, das zwei Verzeichnisse miteinander synchronisiert. Gleichzeitig sollte das Programm Änderungen im Verzeichnis dokumentieren können. Da für diese Aufgabe kein geeignetes Programm gefunden werden konnte, wurde kurzerhand ein eigener FTP-Client auf Grundlage des Jakarta commons net Projektes implementiert [Jakarta net ]. Die Aktualisierung erfolgt dabei nach den im cron-prozess angegebenen Zeiten. Die zu importierenden Daten stehen in verschiedenen FTP-Verzeichnissen zur Verfügung. Die Linux-Shellskripte werden dabei als Jobs vom cron-deamon ausgeführt. Diese Skripte haben die Aufgabe, die alten Import-Dateien und die dazugehörenden Log-Dateien als.tar-archiv zu sichern und anschließend den in Java realisierten FTP- 12 wget ist ein freies Tool aus dem GNU-Software Paket, um Dateien über HTTP, HTTPS oder FTP zu laden [GNU wget]

24 24 / 86 Client zu starten. Dem FTP-Client werden dabei als Argumente der FTP-Server, der FTP-Benutzername, das Passwort und das Zielverzeichnis mit angegeben. Die herunter geladenen Dateien müssen anschließend eventuell noch entpackt werden, bevor der Import gestartet werden kann. Da die Shellskripte sequenziell arbeiten, kann im Anschluss an den Download direkt die Importroutine für den Datenbankimport gestartet werden, wie er schematisch in Abb dargestellt wird. Die Ausgaben der Importroutinen werden per an den Shopadministrator versendet, so dass dieser über den reibungslosen Ablauf informiert ist oder gegebenenfalls eingreifen kann. Abb Aktivitätsdiagramm der Importroutine

25 25 / Unifizierung der Daten In diesem Shopsystem werden die Daten verschiedener Quellen in einer Datenbank zu einem Multi-Lieferanten-Artikelkatalog zusammengefasst. Um einen Datenabgleich zwischen verschiedenen Anwendungen zu ermöglichen, deren Datenhaltung unterschiedlich organisiert ist, müssen die Datensätze des einen Systems anhand eindeutiger Schlüssel den Datensätzen im anderen System eindeutig zuzuordnen sein. Die Struktur der Datensätze kann durch einen Transformationsvorgang bei der Ausgabe in ein Austauschformat durchgeführt werden oder muss beim Import in das Zielsystem transformiert werden, wie es hier der Fall ist Anlegen der Lieferanten Die Daten, die im Shop verwaltet werden, stammen aus unterschiedlichen Quellen. Bei der Integration von Daten aus mehreren Datenquellen für die Nutzung in einer Applikation, ist es wichtig, nachvollziehen zu können, woher die Daten stammen, um diese individuell an das Zielsystem anpassen zu können und redundante Datensätze zu vermeiden. Außerdem spielt die Herkunft beim Preisimport eine entscheidende Rolle. Der Preis, zu dem ein Artikel im Shop angeboten wird, wird durch eine Preisfindungslogik auf Seiten von IT-Haus bestimmt. Die daraus entstandene Preisliste wird tagesaktuell im Shop eingespielt. Um für die Abteilung Einkauf bei einer Bestellung aus dem Shop nachvollziehen zu können, wie der Preis kalkuliert wurde, ist die Angabe des Lieferanten wichtig. Da es sich hier um wenige Lieferanten handelt, wurden diese manuell im Shopsystem angelegt. Wichtig beim Anlegen der Lieferanten ist allerdings, dass sich diese Einträge nicht mehr ändern und damit auch eine eindeutige Zuordnung zwischen dem ERP-System und dem Shop geschaffen wird (vgl. Abb ).

26 26 / 86 Abb Select-Ausgabe der Zuordnung von Sage-Lieferantenkennung zu SHOP-Kennung 4.4.2Anlegen der Hersteller Der Import der Hersteller für den Bereich Verbrauchsmaterial setzt voraus, dass die Hersteller aus den CNET-Artikeldaten bereits eingetragen sind, da die Herstellerbezeichnungen, wie sie CNET liefert, in Zukunft als eindeutige Schreibweise im Shop verwendet werden sollen. Um die Herstellerbezeichnung im Shop eindeutig festzulegen, werden die Hersteller aus allen Datenquellen, in diesem Fall also die Preislisten der Lieferanten, in einer Tabelle zusammengefasst. Diese Tabelle IT_HERSTELLER_LIEFERANT dient zum Unifizieren der Herstellernamen. Sie bildet die unterschiedlichen Schreibweisen bzw. Herstellerbezeichnungen auf einen eindeutigen Eintrag in der Tabelle WS_HERSTELLER ab, der im Shop benutzt wird.

27 27 / 86 Abb Unifizierung der Herstellerbezeichungen Die Unifizierung der Herstellernamen ist wichtig, da Artikel im Shop zwar eindeutig über ihre ID identifiziert werden können, aber nach außen, also beispielsweise zur Suche in einer Preisliste, nur über den zusammengesetzten Schlüssel Artikelnummer und Hersteller eindeutig identifiziert werden können, da Artikelnummern einiger Hersteller oft nur fortlaufende Sequenzen sind, die genauso bei anderen Herstellern vorkommen können. Beim Import der Hersteller, der durch das Skript csvimport_shop_hersteller gestartet wird, wird zunächst geprüft, ob der Hersteller schon in der Tabelle IT_HERSTELLER_LIEFERANT vorhanden ist. Ist dies der Fall, so wird der Hersteller nur in dieser Tabelle mit der ID des Lieferanten, also beispielsweise 2 für Kompashop, angelegt. Ist der Hersteller noch nicht bekannt, so wird er in dieser Tabelle und der Tabelle WS_HERSTELLER angelegt. Zur Erhaltung der Datenkonsistenz muss in diesem Fall auch eine neue Adresse für den Hersteller angelegt werden, die über das Feld ANSPRECHPARTNER der Tabelle WS_HERSTELLER verknüpft wird. Die Datei PRODUCER.CSV enthält weit über 1000 Hersteller. Viele davon werden jedoch für den Bereich Verbrauchsmaterial nicht benutzt. Die Spalte IMPORTANCE

28 28 / 86 dieser Datei gibt dabei an, welchen Stellenwert der Hersteller hat. Für den Shop werden ausschließlich Hersteller importiert, die mit 1 gekennzeichnet sind. Diese Filterung übernimmt die Klasse Supplies_Hersteller_Importance Filter, die ihre Einstellungen über die XML-Konfigurationsdatei bezieht. Beispiel 7: Transformation durch Filterklasse <csv-map> <dest-tablename>it_hersteller_lieferant</dest-tablename> <table-key type="integer" name="hersteller"> <source type="complex" filter="de.ithaus.persistence.filter. Supplies_KompaHerstellerImportanceFilter"> PROD_ID </source> </table-key> Beispiel 8: Implementierung des Hersteller-Import-Filters public String filter(csvvalue key) throws Exception { String importance = file.getvalue(rownumber,"importance"); if(! "1".equals(importance)) throw new SQLException("Importance ="+importance); return file.getvalue(rownumber,key.getname()); }

29 29 / Anlegen der Kategorien Da im Shop der Artikelstamm verschiedener Lieferanten in einer Datenbank zusammengefasst werden sollte, musste die Kategorisierung angepasst werden, um die verschiedenen Sparten unterscheiden zu können. Eine Kategorisierung, wie sie von Kompashop geliefert wurde, hätte einfach abgebildet werden können. Hier musste jedoch die Kategorisierung nach dem Vorbild der CNET-Kategorisierung angepasst werden. Da die CNET-Kategorien als alphabetische Hierarchie dargestellt werden, mussten diese, um im Shop integriert werden zu können, in ein nummernbasiertes Schema umgewandelt werden. Dabei wurde das Schema so aufgebaut, dass die Zugehörigkeit zu einer Produktgruppe immer an der letzten Ziffer zu erkennen ist. Für den Bereich Hardware endet die ProduktgruppenID immer mit xxxx1, für den Bereich Verbrauchsmaterial endet die ProduktgruppenID mit xxxx3, wie in Abb in der rechten Darstellung zu erkennen ist. Ausgehend von dieser Grundlage musste die Kategorisierung der Verbrauchsmaterialien angepasst werden. Die Transformation, die dabei für die CNET-Kategorisierung aufgebaut wurde, konnte für den Bereich Supplies nicht umgesetzt werden. Die beiden Kategoriebäume unterscheiden sich deswegen sehr stark, weil die Kategorisierung der CNET-Daten sehr flach ist und viele Oberkategorien aufweist. Der Produktbaum der Verbrauchsmaterialien aus dem Kompashopdatenmodell ist hingegen sehr breit, also mit wenigen Oberkategorien, dafür enthält er aber sehr viele Unterkategorien. Nach dem Transformationsverfahren der CNET-Kategorisierung, die jeweils zwei Stellen für eine Hierarchieebene verwendet, so dass insgesamt 99 Unterkategorien gebildet werden können, würden die zur Verfügung stehenden 10 Stellen der Datenbankspalte ARTKATEGORIE nicht mehr ausreichen, da der Produktgruppenbaum der Kompashopgruppen an der breitesten Stelle eine Untergliederung von 6 Untergruppen hat. Somit musste das Verfahren leicht abgewandelt werden. Da nur die Einschränkung durch die CNET-Produktgruppentransformation gegeben war, dass keine Produktgruppen angelegt werden dürfen, die an der kleinsten Position eine 1 haben, wurde durch ein simples Verfahren die Nummerierung der Kategorie-IDs umgesetzt. Die Kategorisierung der Artikeldaten wird beim Import durch entsprechende FilterKlassen modifiziert. Die Importroutine berechnet aus der bereits vorhandenen ID eine neue ID, an deren kleinste Stelle die Hauptproduktgruppe zu erkennen ist, indem die führende Position um eins inkrementiert als letzt Stelle angefügt wird. Der neue Baum wird dabei durch die Importroutine aufgebaut. Die Einträge werden so in der Datenbank eingetragen, dass ohne Modifizierung der Logik des Shopsystems der Produktbaum sowohl im Frontend als auch im Backend rekonstruiert werden kann. Unerwünschte Kategorien oder leere Kategorien, wie beispielsweise die Kategorie Modelle, lassen sich über das Backend einfach auf inaktiv setzen. Inaktive Kategorien werden im Backend blau dargestellt und im Frontend nicht mehr angezeigt (vgl. Abb )

30 30 / 86 Abb Produktgruppenbaum im Front- und Backend Der Import und das Update der Kategorien für den Bereich Verbrauchsmaterial wird aus der Datei CATEGORIES.CSV gelesen. Beim Updatevorgang werden existierende Einträge nicht beeinflusst, neue Einträge werden als inaktiv angelegt. Da sich die Kategorisierung über das monatliche Update auf nichtvorhersehbare Weise ändern kann, sollten die Updates vom Shopadministrator manuell frei geschaltet werden oder durch Löschen der neuen Kategorien rückgängig gemacht werden können. Das Mapping der Einträge aus der Datei CATEGORIES.CSV wird durch die XMLDatei Supplies_Categories.xml festgelegt und durch die Klasse SuppliesCSVCategoriesWrapper realisiert. Die Einträge werden in die Tabellenstruktur, wie in Abb dargestellt, eingetragen. Die hierarchische Gliederung wird dabei durch die Tabelle WS_ARTKATEGORIE_LINK realisiert. Der Datenbankwrapper benutzt folgende Filterklassen Supplies_Categorie_Filter Supplies_Categorie_ParentFilter Supplies_Categorie_OrderFilter,

31 31 / 86 um aus der CategorieID und der Spalte Treeposition aus der CSV-Datei die Einträge für die Datenbank zu berechnen. Sollte sich die Kategorisierung einmal ändern, sind nur die Filterklassen auszutauschen. Abb ER-Diagramm Artikelkategorien 4.4.4Anlegen von Artikeln Nachdem Hersteller und Kategorien angelegt sind, können die Artikeldaten angelegt werden beziehungsweise aktualisiert werden. Um eine Anbindung der im Shop angelegten Artikel zu den Artikeln von Kompashop oder CNET herstellen zu können, werden die Artikel über ihre ArtikelID im Shop mit der ArtikelID aus dem Fremdsystem verknüpft. Auf diese Weise können Updates der Artikeldaten von Kompashop auf den Datensätzen in der Shopdatenbank ausgeführt werden. Die Verknüpfung zwischen Shopkennung und Kennung des Fremdsystems wird in der Tabelle IT_ARTIKEL_LIEFERANT, wie in Abb dargestellt, verwaltet.

32 32 / 86 Abb Mapping der Artikelnummern Für den Import der Artikelinformationen wird der Wrapper SuppliesCSVArtikelWrapper benutzt. Beim Anlegen der Artikeleinträge muss er für jeden Eintrag aus der CSV-Datei vorher die ID des Eintrags in der Tabelle IT_ARTIKEL_LIEFERANT abfragen. Existiert hier kein Eintrag, so wird der Artikel in den beiden Tabellen WS_ARTIKEL und IT_ARTIKEL_LIEFERANT neu angelegt, andernfalls wird der Datensatz in den Shoptabellen durch den Datensatz aus der CSVDatei aktualisiert. Das Einspielen der Artikeldaten ist ein komplexer Vorgang, da von dem Datenbankschema der Firma Kompashop in das Datenbankschema der Firma OMECO konvertiert werden muss. Die Artikeldaten werden in der Datei ARTICLE.CSV bereitgestellt. Aus dieser Datei wird der Hersteller, die Kategorie und der Artikeltext für jeden Artikel gelesen. Für jeden Artikeleintrag muss daher nochmals die Konvertierung des Herstellers und der Artikelkategorie durchgeführt werden. Für diese Konvertierung können die Filter, wie sie für den Herstellerimport und den Kategorieimport benutzt wurden, nochmals verwendet werden.

33 33 / 86 Zusätzlich müssen Standardeinträge, wie Mindestbestellmenge, Anlagedatum, gültig_von, gültig_bis, Frachtgruppe und weitere (vgl. Abb ), durch den Wrapper in die Datenbanktabellen eingetragen werden. Diese Einträge werden in der XML-Datei Supplies_Artikel.xml vordefiniert oder durch den Wrapper ergänzt. Da nicht alle Hersteller aus der Datei HERSTELLER.CSV im Shopsystem angelegt wurden, werden beim Update einige Artikel aus der aktuellen Datei ARTICLES.CSV nicht gefunden oder können nicht angelegt werden, weil der Hersteller unbekannt ist. Abb zeigt, wie die Einträge in der Datenbank organisiert werden müssen, um im Backend angezeigt werden zu können. Abb Artikelbeschreibungen

34 34 / 86 In den Kompashopdaten ist die Artikelbeschreibung nur rudimentär gegeben, z.b. Tinte gelb oder Druckkopf schwarz. Die Produktbeschreibung wird durch den Kurztext aus der Preisliste des alten Shopsystems, wie in Abb dargestellt, ergänzt, die ebenfalls vom FTP-Verzeichnis der Firma Kompashop herunter geladen werden können. Diese Datei liefert einen zusätzlichen Kurztext in den beiden Spalten DESC1 und DESC2, die zusammengesetzt als Kurztext für die Artikelbeschreibung im Shop benutzt werden. Abb Auszug aus der UFP-Preisliste Um eine Zuordnung zwischen der UFP-Artikelnummer und der KompashopArtikelnummer zu bekommen, wird die Tabelle IT_ARTIKEL_LIEFERANT verwendet. Diese Zuordnung kann aus der Datei mappingxml.csv übernommen werden, die vom FTP-Server der Firma Kompashop herunter geladen werden kann. Das Eintragen der Zuordnungen wird durch die Importroutine csvimport_ufp2kompashop ausgeführt. Die Artikelbilder, die über den FTP-Server der Firma UFP bezogen werden können, sind nach den UFP-ArtikelID benannt. Aus diesem Grund ist es wichtig, die Zuordnung der UFP-ArtikelNummer zu der ShopArtikelNummer herstellen zu können. Sie werden im Anschluss an die vorherige Importroutine durch die Importroutine csvimport_artikelbilder in die Tabellen WS_BILD und WS_ARTIKEL_BILD eingefügt. Über diese beiden Tabellen wird eine 1:n Beziehung der Artikelbilder zu den Artikeln hergestellt. 4.5Preisimport Der Preisimport wird jeden Morgen automatisch gestartet und setzt die tagesaktuellen Artikelpreise. Dieses Preisupdate ist in mehrere Schritte unterteilt. Zunächst wird jeden Morgen um 5.00 Uhr ein Skript auf dem Server ausgeführt, das eine Liste aller im Shop enthaltenen Artikel generiert, die mit neuen Preisen versehen werden sollen. Da die Einträge in der Shopdatenbank viele Informationen enthalten, die für die Ermittlung der Tagespreise nicht notwendig sind, werden über ein SQLStatement nur die unbedingt relevanten Informationen abgefragt. Diese sind die Artikelnummer und der Hersteller, die als zusammengesetzter Primärschlüssel zur Preisbestimmung aus den Preislisten verwendet werden. Zusätzlich werden dabei alle Artikel ausgeschlossen, die nicht aus dem Artikelstamm von Kompashop oder CNET stammen und nicht zu Kategorien gehören, zu denen es

35 35 / 86 eine Überschneidung der Artikeldaten der beiden Stammdatenquellen gibt. Dies kann auftreten, weil CNET ebenfalls eine Kategorie Verbrauchsmaterial mitliefert, die allerdings wesentlich weniger Artikel beinhaltet. Um zu vermeiden, dass Artikel dadurch doppelt im Shop angelegt sind, werden die Artikel, die aus der CNET Kategorie Verbrauchsmaterial stammen, auf inaktiv gesetzt und somit nicht mehr im Shop angezeigt. Auf Grundlage dieser Liste werden die tagesaktuellen Preise auf dem internen MSQL-Server der Firma IT-Haus ermittelt und als CSV-Datei über FTP wieder auf den Shopserver zurückgespielt. Dieser asynchrone Datenaustausch setzt voraus, dass der zeitliche Ablauf streng eingehalten wird. Zum Import der tagesaktuellen Preisliste in die Shop-Datenbank, wird jeden Morgen zu Geschäftsbeginn über einen cron-job das Update der Preise ausgeführt. Dabei werden zuerst für alle Artikel die Verfügbarkeit und das Anzeigenflag zurückgesetzt, um auszuschließen, dass nach dem Preisupdate noch Artikel im Shop vorhanden sind, die keinen Preis beziehungsweise keinen aktuellen Preis besitzen. Mit dem Setzen des neuen Preises wird auch das Anzeigenflag wieder auf aktiv gesetzt sowie die Verfügbarkeit eingetragen. Der Shop kennt dabei drei Stufen der Verfügbarkeit: 0 Artikel ist nicht verfügbar rotes Fähnchen 1 Artikel ist kurzfristig verfügbar gelbes Fähnchen 2 Artikel ist verfügbar grünes Fähnchen Tabelle 4.5. Verfügbarkeit der Artikel Zusätzlich wird auch das Gültigkeitsdatum dieser Artikel um einen Tag verlängert. Der Zeitraum, um wie viele Tage das Gültigkeitsdatum verlängert werden soll, lässt sich über die zentrale Konfigurationsdatei einstellen. Anhand des Gültigkeitsdatums eines Artikels kann die Datenbank von Zeit zu Zeit aufgeräumt werden. Da ein stetig wachsender Artikelstamm die Performance des Shops verringert, ist es sinnvoll, in gewissen Zeitintervallen alte Artikel aus der Datenbank zu löschen. Bei Artikeln, die seit einer bestimmten Zeit keinen Preis mehr erhielten, liegt somit auch das Gültigkeitsdatum weit in der Vergangenheit. Da dieser Vorgang so vereinzelt durchgeführt wird, war es nicht sinnvoll, dies automatisiert ablaufen zu lassen, sondern er soll vom Shopadministrator direkt auf der Datenbank durchgeführt werden.

36 36 / 86 Die Entscheidung, welcher Artikel nun endgültig aussortiert werden soll oder ob er vielleicht nur temporär nicht nachgefragt wird, bedarf hier der Kontrolle eines Vertriebsmitarbeiters. Abb zeigt die Felder der beim Preislistenimport gesetzten Werte: Abb Felder, die durch das Preislistenupdate aktualisiert werden

37 37 / 86 5Kundenmodul Wer etwas verkaufen will, muss sicher sein, dass er es zu dem verlangten Preis los wird. Das praktische Preis-Marketing sucht den optimalen Absatzpreis für ein Produkt oder eine Dienstleistung. Dabei geht es nicht nur um die Höhe des konkreten Verkaufspreises. Dazu kommen Liefer- und Zahlungsbedingungen und gegebenenfalls Rabatte, die als nicht zu unterschätzendes, absatzpolitisches Mittel bei der Auftragserteilung mitwirken. 5.1Analyse des Funktionsumfangs Das Webshopsystem der Firma Omeco bot in seiner Grundausstattung bereits viele Funktionen, die für den B2B-Bereich von großer Bedeutung sind. Im B2B-Bereich ist es notwendig, dass Kunden mit mehreren Rechnungs- und Lieferanschriften angelegt werden können, da hier verschiedene Organisationsformen vertreten sind. Einkäufe können entweder zentral von einer Einkaufsabteilung abgewickelt werden und die Lieferung erfolgt an verschiedene Werke oder sie werden von den Filialen selbst getätigt, wobei dann aber der Rechnungsempfänger die Firmenzentrale oder die Buchhaltungsstelle der Firma sein kann. Diese Möglichkeiten sind bereits im Omeco-Webshop berücksichtigt und können über das Backend entsprechend angelegt werden. Auch war bereits die Möglichkeit vorhanden, dass der Shop nur für registrierte Kunden zugänglich sein soll. Kunden können sich über ein Anmeldeformular registrieren lassen. Die Anmeldung wird von den Zentralen der Firma IT-Haus geprüft und freigegeben. Das Anlegen eines Kunden im Backend ist unabhängig von der Freischaltung des Shopzugangs. Auf diese Weise kann ein Kunde zwischenzeitlich von der Nutzung des Webshops ausgeschlossen werden, sollten z.b. noch offene Posten vorliegen. Der Funktionsumfang des Omeco-Webshops bietet darüber hinaus die Möglichkeit, Kunden nur einzelne Produktgruppen anzubieten. Über die Zuordnung einer Produktgruppe zu einer Kundenklasse wird diese Produktgruppe nur für Kunden dieser Kundenklasse angezeigt. Daraus ergeben sich vielfältige Möglichkeiten, die Kundenbeziehungen zu definieren. Über diese Funktion kann beispielsweise Missbrauch vorgebeugt werden, indem Einkäufern, die nur Hardware bestellen dürfen, die Bestellung von Tinte oder Toner für den Eigenverbrauch gar nicht erst ermöglicht wird. Der Funktionsumfang des Webshopsystems bietet damit schon eine gute Grundlage für den Einsatz im B2B-Bereich. Erweiterungen sind aber in dem Bereich der Kundenverwaltung zu realisieren. Kunden des Webshops müssen auch im ERP-System zu finden sein. Es muss eine Zuordnung der Kundendaten zu den Datensätzen im ERP-System hergestellt werden können. Weiterhin kann eine Firma mehrere Einkäufer haben, die zu unterschiedlichen Höchstbestellsummen einkaufen dürfen. Daher muss für den Kunden diese Höchstsumme im Backend einstellbar sein.

38 38 / 86 Als wichtigstes Merkmal einer Kundenbeziehung ist sicherlich die Kundenkondition zu nennen, die für den Kunden auf einzelne Produkte oder Produktlinien vereinbart werden kann. Im Rahmen der projektbezogenen Erweiterungen des Omeco-Webshops mussten hier neue Lösungen gefunden werden, zusätzlich zu den bereits angebotenen Möglichkeiten der Personalisierung, die Preisfindung durch ein erweitertes Preismodell zu ergänzen, durch das der Verkaufspreis kundenbezogen bestimmt werden kann. 5.2Analyse und Umsetzung der kundenbezogenen Rabattierung 5.2.1Ermittlung des Basispreises Die Preisvergabe der im Shop angebotenen Artikel konnte bisher nur für jeden Artikel einzeln eingestellt werden. Dies machte allerdings bei einem Artikelstamm, der mehrere tausend Artikel umfasst, keinen Sinn und wäre eine kaum zu bewältigende Aufgabe. Darum musste hier eine Möglichkeit geschaffen werden, die Preise der angebotenen Artikel effizienter zu gestalten. Der Weg zu einer effizienteren Preisvergabe konnte nur der sein, dass durch einen Arbeitsschritt die Preise für mehrere Artikel eingestellt werden können. Die Idee, einen prozentualen Aufschlag auf Gruppen von Artikeln zu vergeben, schien dabei die zweckmäßigste Lösung zu sein. Dabei darf die Menge der Artikel natürlich nicht willkürlich zusammengefasst werden. Die Gruppierung von Artikeln nach ihren Gemeinsamkeiten findet sich bereits in der Produktgruppe wieder. Die Bepreisung alleine nach der Produktgruppe war allerdings noch zu grob, da man auch die Möglichkeit haben sollte, Artikel eines gewissen Herstellers bevorzugt anzubieten und diese durch günstigere Preise am Markt stärker abzusetzen. Darum wurde dem Produktgruppenkatalog eine zusätzliche Ansicht hinzugefügt, in der die Hersteller, die in dieser Produktgruppe vertreten sind, gelistet werden. Das Anzeigen der in einer Produktgruppe vertretenen Hersteller erfolgt ausschließlich durch das Selektieren eines Blattes im Produktbaum. Grundsätzlich sind Artikel nur in Blättern des Produktgruppenbaums zu finden. Dies muss durch die Artikelverwaltung sowie durch die Importroutinen sichergestellt sein.

39 39 / 86 Über diese neue Ansicht Preise (vgl. Abb ) lassen sich prozentuale Aufschläge eintragen, die dynamisch, d.h., wenn sie im Frontend angezeigt werden, auf den Einkaufspreis des jeweiligen Artikels, aufgeschlagen werden. Abb Prozentualer Aufschlag auf herstellerbezogene Produktgruppe Die hier eingetragenen prozentualen Aufschläge werden mit einem Standardwert initialisiert und müssen anschließend einmalig von einem Vertriebsmitarbeiter eingestellt werden. Dieser Vorgang der Vergabe der prozentualen Aufschläge lässt sich nicht automatisiert einstellen, da hierzu die Intuition und Erfahrung eines Vertriebsmitarbeiters notwendig sind, um die Aufschläge richtig zu kalkulieren. Jede Preiskalkulation sollte zunächst berücksichtigen, welche Kosten es im Unternehmen verursacht ein Produkt herzustellen und zu verkaufen. Hinzu kommt, der Verkaufspreis sollte alle dazugehörigen Kosten plus einen Gewinn abdecken. Sind die Preise für die Kundschaft oder im Verhältnis zur Konkurrenz zu hoch, bedeutet dies, dass herausgefunden werden muss, wieviel der Kunde bereit ist zu zahlen und welchen Preis die Konkurrenz für vergleichbare Produkte verlangt. An beiden Vorgaben muss sich der kalkulierte Preis ausrichten.

40 40 / 86 Der verwendete Standardaufschlag lässt sich im Backend unter dem Menüpunkt: Shops-> Shopattribute einstellen. Im folgenden Beispiel soll dieser beispielhaft mit 100% Aufschlag berechnet werden (vgl. Abb ): Abb Einstellen des Standardaufschlags

41 41 / Kundenbezogene Preisgestaltung Die Preisberechung über den prozentualen Aufschlag auf alle Artikel eines Herstellers einer Produktgruppe bietet allerdings noch nicht die notwendige Flexibilität, um die gesamte Preisfindung des Shopsystems komplett abzudecken. Mit der Anforderung, Artikel eines Herstellers verstärkt zu verkaufen, indem sie günstiger angeboten werden, als die Artikel eines anderen Herstellers, liegt auch die Idee nahe, jedem Kunden individuell Artikel eines Herstellers günstiger anbieten zu können als z.b. Artikel eines anderen Herstellers. Die prozentualen Aufschläge auf die Artikel eines Herstellers einer Produktgruppe bilden somit nur die Basis für die Preisgestaltung. Es muss also für einen Kunden einstellbar sein, welche Artikel eines Herstellers dem Kunden bevorzugt angeboten werden und welche zu normalen Konditionen angeboten werden sollen. Aus diesen Gründen müssen die prozentualen Aufschläge über die Hersteller einer Produktgruppe für einen Kunden individuell überschrieben werden können, so dass nach dem Login eines Kunden die Verkaufspreise der Artikel dynamisch aufgrund der für den Kunden individuell eingestellten prozentualen Aufschläge berechnet werden. Werden für Hersteller oder ganze Produktgruppen keine kundenspezifischen Einstellungen gemacht, so sollen die Einstellungen des Basispreisaufschlags auf den Einkaufspreis gelten. Diese Einstellung gehört zu den individuellen Daten eines Kunden. Darum wurde die neue Eingabemaske im Kundenmodul realisiert. Nachdem die Produktgruppe über den Navigationsbaum, genau wie aus dem Produktgruppenkatalog bereits bekannt, ein Blatt ausgewählt wurde, lassen sich die Basisaufschläge aus dem Produktkatalog individuell für den Kunden anpassen. Abb zeigt, wie die prozentualen Aufschläge nach Erstellen einer Produktgruppe für einen Kunden eingestellt werden. Es wird zusätzlich die Information darüber gegeben, wie viele Artikel von diesem Aufschlag betroffen sind.

42 42 / 86 Kundenbezogene Aufschläge sind leicht an dem roten X zu erkennen, über das die Einstellung wieder gelöscht werden kann. Abb Kundenbezogene Aufschläge auf Hersteller und Produktgruppe Die Preisfindung, wie sie bisher beschrieben wurde, deckt vorwiegend den Bereich Hardware ab. Für den Bereich Verbrauchsmaterial musste die Unterteilung nochmals verfeinert werden. Da sich Tinten und Toner eines Herstellers, abhängig vom Modell, sehr stark unterscheiden, z.b. darin, wie oft sie nachgefragt werden oder ob es sich um spezielle Ausprägungen einer Tinte oder eines Druckkopfs handelt, etwa Tinte speziell für den Photodruck, variiert der Aufschlag innerhalb der Artikel sehr stark. Aus diesem Grund wurde hier die Möglichkeit geschaffen, wenn für einen Kunden ein individueller Aufschlag eingetragen wurde, diese herstellerbezogene Artikelgruppe weiter zu untergliedern.

43 43 / 86 Nach dem Eintragen eines kundengebundenen Aufschlags, verlinkt der Herstellereintrag auf die Folgeseite, wie in Abb dargestellt: Abb Eingabemaske zum Gruppieren von Verbrauchsmaterialartikel über Teilstrings der Artikelnummern Aus obiger Abbildung ist zu erkennen, dass sich die Gliederung der Untergruppen über Teile der Artikelnummer zusammenfassen lässt. Über das Auswahlfeld Artikelnummern wird eine Übersicht über alle Artikelnummern dieser Produktgruppe angeboten. Rot markierte Einträge sind nur temporär angelegt und noch nicht in der Datenbank gespeichert. Die angelegten Unterkategorien müssen eindeutig sein. Wenn eine Unterkategorie angelegt werden soll, die bereits existiert, wird eine Fehlermeldung, wie in Abb zu sehen, dargestellt. Für den Bereich Verbrauchsmaterial gilt, dass ähnliche Produkte auch ähnliche Produktnummern besitzen. Somit kann über dieses Merkmal die Produktgruppe des Herstellers nochmals zu kleineren, freidefinierbaren Subkategorien zusammengefasst werden. Die Auswahl des anzuwendenden Preisaufschlags folgt dem Prinzip: Longest match first : der längste Eintrag, der die Artikelnummer des Artikels am genauesten trifft, wird als Aufschlag berechnet.

44 44 / 86 Wenn beispielsweise, wie in obiger Abbildung, ein Artikel mit der Artikelnummer C4814AE an den Kunden verkauft werden soll, so werden 8.0% auf den Einkaufspreis dieses Artikels berechnet, weil nur die Gruppe C48, nicht aber C484, zu der Artikelnummer passt. Abb Fehler beim Anlegen einer bereits vorhandenen Untergruppe 5.2.3Artikelgebundene Kundenkonditionen Nachdem das Preismodell die Preisfindung von Artikelgruppen abdeckt, kann der Kunde aber auch einen Festpreis auf ausgewählte Artikel erhalten. Dieses Feature hatte der Omeco-Webshop bereits in seiner Grundversion realisiert. Das Einstellen eines Festpreises für einen Kunden erfolgt in der Artikelkatalogansicht unter dem Tab myproducts (vgl. Abb ). Jeder Artikel kann einem Kunden für einen Festpreis oder einen prozentualen Aufschlag auf den Einkaufspreis angeboten werden. Das Vergeben eines prozentualen Aufschlags wurde an dieser Stelle für IT-Haus hinzugefügt. Um einen solchen Aufschlag für den ausgewählten Artikel den Kundenkondition eines Kunden hinzufügen zu können, muss der Kunde über seine Kundennummer ausgewählt werden. Durch die Validierung der Benutzereingaben werden dabei ungültige Eingaben zurückgewiesen, es können z.b. nur ein Festpreis oder ein prozentualer Aufschlag vergeben werden. Werden beide Werte gesetzt, wird der Vorgang abgebrochen und eine Fehlermeldung ausgegeben.

45 45 / 86 Abb Vergabe von Kunden-Artikel-Relationen Der Controller dieser Tabulatoransicht wurde für die Firma IT-Haus so angepasst, dass automatisch die Artikelbeschreibungen des ausgewählten Artikels übernommen werden. In der Grundversion dieser Ansicht waren die Felder leer und sollten individuell für den Kunden gefüllt werden. Dies ist im projektbezogenen Umfeld von IT-Haus jedoch nicht sinnvoll, da die Artikel in einer Bestellung auch im Warenwirtschaftsystem der Firma IT-Haus zu finden sein müssen. Eine individuelle Artikelbeschreibung oder sogar eine individuelle Artikelnummer könnte durch dieses System nicht verarbeitet werden.

46 46 / 86 Um den Überblick über Kunden-Teile-Relationen eines Kunden zu geben, wurde unter dem Kundenmodul ein zusätzliches Tabulatorfeld myproducts hinzugefügt, dass alle Kunden-Teile dieses Kunden als Übersicht auflistet. Abb Übersicht der Kunde-Teile-Relation 5.2.4Kundenobjekt als Vorlage benutzen Die Einstellungen eines Kunden hinsichtlich der prozentualen Aufschläge und das Anlegen von Kunden-Teile-Relationen ist ein verhältnismäßig großer Aufwand. Darum lag der Wunsch nahe, einen Kunden anlegen zu können, der ähnliche Konditionen besitzt, indem man die Einstellungen eines anderen Kunden zu Grunde legt. Zu diesem Zweck wurde der Tabulator Copy im Kundenmodul ergänzt. Über diese Maske lässt sich der aktuell ausgewählte Kunde mit seinen kundenspezifischen Preisaufschlägen als Vorlage für einen neuen Kunden benutzen. Es kann dabei optional ausgewählt werden, ob nur Kundenartikel oder auch die Kundenzuschläge mit übernommen werden. Nach betätigen des Kunde_klonen Buttons ist der Kunde bereits in der Datenbank angelegt und es wird mit dem neuen Kundenobjekt gearbeitet. Es müssen nun für dieses neue Kundenobjekt noch die neuen Kundendaten wie Anschrift, Rechnungsanschrift und Lieferanschrift eingetragen werden, da diese aus Sicherheitsgründen nicht mit kopiert werden. Beim Kopieren eines Kundenobjektes wird automatisch vom System eine neue Shopkundennummer vergeben.

47 47 / 86 Abb Kundenobjekte mit Eigenschaften kopieren Das Kundenobjekt wurde um die Eigenschaft SAGE-Kundennummer ergänzt, um den Kunden eigene Kundennummern zuordnen zu können, so wie sie im ERP-System der Firma IT-Haus eingetragen sind. Die vom Shopsystem vergebenen Nummern sind durch die Shoplogik festgelegt und können auch vom Administrator des Backends nicht beeinflusst werden. Außerdem wurde dem Kunden das Feld maximale Bestellsumme hinzugefügt, das die Obergrenze der Bestellsumme des Kunden festlegt.

48 Abb zeigt eine Kopie des Kundenobjekts mit der Kundennummer Abb Ansicht Defaultkundeneinstellung 48 / 86

49 49 / Technische Realisierung Die beschriebenen Änderungen am Kundenmodul bedeuten teilweise massive Änderungen auf der Datenebene. Bei der Umsetzung der Änderungen für die Firma ITHaus wurde das von der Firma Omeco vorgeschlagene Verfahren angewandt. Um die projektbezogenen Erweiterungen am Backend genauer beschreiben zu können, wird im Folgenden zunächst ein kurzer Überblick über die Architektur des Backends vermittelt Einbindung projektspezifischer Erweiterungen Um diese Erweiterungen vor dem Überschreiben durch ein mögliches Update des Shopsystems zu bewahren, mussten die neuen Bestandteile vom Basisprojekt entkoppelt werden. Die Änderungen werden, wie in Abbildung dargestellt, in dem projektspezifischen Ordner de/omeco/webshop/customerextension umgesetzt. Unterhalb dieses Ordners wird die Dateistruktur des Shopsystems für die projektbezogenen Erweiterungen nachgebaut. Es wurden keine Änderungen in OriginalQuellcodedateien vorgenommen, sondern die betroffenen Klassen wurden entweder abgeleitet oder neu implementiert. Abb Aufbau der Dateistruktur

50 50 / 86 Die Ordnerstruktur im Verzeichnis de/omeco/webshop/customerextension gliedert dabei die funktionalen Komponenten in die gleichen logischen Einheiten, so wie sie im Basisprojekt angelegt wurden. Gliederung der funktionalen Einheiten durch die Ordnerstruktur:../webui/core hier liegen die Controller und Tabulatoren../business/core hier liegen die Businessobjekte und InfoManager../business/datasource hier liegen die Interfaces der Wrapper-Klassen../business/datasource/mysql hier liegen die Datenbankwrapperklassen../business/locales hier liegen die Dateien zur Sprachparametrisierung 5.3.2Architektur des Backends Das Backend des Webshops übernimmt die administrativen Aufgaben das Shops. Es läuft auf einem JSP1.1- bzw. Servlet 2.2- tauglichen Web-Container. Für Version 3.0 des Omeco-Webshops wird dabei aber ausschließlich der Resin-Webserver des kalifornischen Herstellers Caucho in Version unterstützt. Durch die Implementierung des MVC-2-Konzepts [sun MVC] wird eine saubere Trennung der Businesslogik von der Darstellung erreicht und erleichtert dadurch dem Entwickler die Realisierung und Wartung der Anwendung. Im MVC-2-Modell dienen die Servlets als Controller und die JSPs als View für die Darstellung der Daten (vgl. Abb ). Somit werden die einzelnen Komponenten klar voneinander getrennt. Die Model-1-Architektur (vgl. Abb.5.3.2) hingegen beschreibt die Datenhaltung, Geschäftslogik und View in einer JSP, was bei einer komplexen Anwendungslogik zu Problemen führt, weil nach kürzester Zeit die JSP unüberschaubar wird und sich nur sehr schwer warten lässt. Zwar könnte dieses Problem durch die Verwendung von TagLibs verringert werden, es bliebe aber immer noch das konzeptionelle Problem der Vermischung von Präsentation und Funktionalität.

51 51 / 86 Abb MVC1 Architektur [sun MVC] Abb MVC2 Architektur [sun MVC]

52 52 / 86 Weiterhin bietet die Architektur des Backends Schnittstellen an, um den Zugriff auf das zugrunde liegende Datenbanksystem aus Sicht der Businesslogik transparent zu gestalten und vom vorhandenen Datenbanksystem zu abstrahieren. Die Trennung der einzelnen Schichten wird durch die Implementierung der Interfaces InfoManager und DatasourceWrapper realisiert. Die implementierenden Klassen basieren auf dem Factory-Pattern13. Dadurch sind Änderungen in dieser Schicht ohne großen Aufwand zu realisieren. Der Benutzer kann über seinen Browser Anfragen an das System stellen. Diese werden über einen HTTP-Request an den Web-Server gesendet. Der Web-Server leitet diesen HTTP-Request an den entsprechenden Controller weiter. Wegen der zustandslosen Verbindung über das HTTP-Protokoll zwischen Client und Server in einer Webanwendung ist es nicht möglich, dass das Model seine Views bei Veränderungen benachrichtigt, wie es im eigentlichen MVC-Entwurfsmuster realisiert wird. Da die Views im Browser des Benutzers durch einfache HTML-Seiten dargestellt werden, können Änderungen am Modell erst bei einem erneuten Request dem Client mitgeteilt werden. Der Controller stellt die Verbindung zur Datenbank über das entsprechende InfoManager-Objekt her. Das InfoManager-Objekt bezieht die Daten über das entsprechende DatasourceWrapper-Objekt und liefert diese an den Controller zurück. Der Controller stellt die initialisierten Objekte über das Session-Management der Businesslogik bereit. Danach gibt der Controller die Kontrolle an die Ergebnisseite ab. Die Ergebnisseite hängt vom Zustand des Models ab und ist im Controller an entsprechender Stelle fest codiert. Je nach Kontext verweist dieser auf eine andere Ergebnisseite. Diese Ergebnisseite ist wieder eine Java-Serverpage (JSP), die über das SessionObjekt14 Zugriff auf das Model hat. Die JSP kann die neuen Daten aus dem Model nehmen und in HTML konvertieren. Im letzten Schritt wird der durch die JSP erzeugte HTML-Code an den Browser gesendet, der das Ergebnis anzeigt. 13 Eine Factory ist in der Lage, je nach Kontext verschiedene spezialisierte Klassen eines gewissen Types bzw. einer Schnittstelle zu erzeugen, ohne dass der Aufrufer diese speziellen Klassen kennen muss. [Esser 2001] 14 Das Session-Objekt gehört zu dem Interface HttpSession des Paketes javax.servlet.http. Es ermöglicht den Zugriff auf die Sitzungen der Servlets und JavaServerPages.

53 53 / 86 Abb veranschaulicht die Architektur des Backend und zeigt die Trennung der einzelnen Schichten. Abb MVC-Architektur des Backends 5.3.3Gliederung der Views Die Views werden im Backend durch JSP-Seiten realisiert, die HTML-Code ausgeben. Sie sind die Präsentationskomponente der Businessschicht. Die JSPAnweisungen werden in der projektbezogenen Erweiterung für die Firma IT-Haus direkt in den HTML-Code eingebettet, so wie es im gesamten Projekt umgesetzt worden ist. Es werden keine Tag-Libs oder Frameworks, wie z.b. das Struts-Framework, zur Strukturierung der Seiten eingesetzt, da dies Änderungen an der Architektur des Backends voraussetzt und damit der Support durch die Firma Omeco nicht mehr gewährleistet wäre.

54 54 / 86 Die Views werden vom jeweiligen Kontroller direkt referenziert. Zur besseren Strukturierung und um eine größere Wiederverwendbarkeit zu erreichen, werden die Views in drei Teile gegliedert: 1. Einen Head, der die Kopfzeilen und Tabulatoren der entsprechenden Katalogansicht darstellt und die Fehlermeldungen anzeigt. 2. Einen Body, der für jede View individuell gestaltet werden muss und die Präsentation der vom Kontext abhängigen Daten übernimmt. 3. Einen Foot, der die Schaltelemente zum Übernehmen von Änderungen der dargestellten Daten bietet. Head und Body werden in den jeweiligen JSP-Seiten über die Include-Direktive eingebunden. Abb Gliederung der Views 5.3.4Aufbau der Controller In der Businessschicht wird die Geschäftslogik durch die Controller abgearbeitet und in der Persistenzschicht gespeichert. Die Businessobjekte repräsentieren im einfachsten Fall die Daten eines Tabelleneintrags. Oft repräsentieren diese Objekte aber datentechnisch mehrere Tabellen, die über Relationen miteinander verknüpft sind. Die Businessobjekte dienen als Model der Anwendung. Sie werden in den entsprechenden Katalogansichten durch die Controller initialisiert und anschließend in der Session verwaltet. Zur Präsentation der Daten werden in den Views die Objekte aus der Session geladen und über die JSP dargestellt. Die von der Klasse javax.servlet.http.httpservlet abgeleiteten Controller und die Tabulatorklassen bilden zusammen die Controller-Komponente. Über diese Klassen werden die Abläufe im Backend gesteuert.

55 55 / 86 Die Servlets bilden die erste Stufe der Abarbeitung eines Requests. Für die komplexeren Ansichten des Backends, also denen, die aus mehreren Tabulatoren bestehen, dienen die Servlets nur zum Delegieren des Requests an den verantwortlichen Action-Handler, der in diesem Fall eine von der Basisklasse Tabulator abgeleitete Klasse ist. Ob ein Tabulator einen Request entgegennimmt oder der Request im Controller behandelt wird, kann im Konstruktor des Tabulators über den Parameter setrequestprocessing(true); gesetzt werden. Der Controller kann über das aktuelle Formular den selektierten Tabulator ermitteln. Grundsätzlich können im Backend zwei Arten von Sichten unterschieden werden: 1. einfache Sichten ohne Tabulatoren 2. und Sichten mit Tabulatoren. Die Sichten ohne Tabulatoren werden direkt über ein Formular referenziert. Die Abarbeitung der Businesslogik muss dann in den Servlet-Objekten erfolgen. In Sichten mit Tabulatoren wird die Businesslogik der dargestellten Komponente direkt im selektierten Tabulator ausgeführt.

56 56 / 86 Abb zeigt den Aufbau der an der Businesslogik beteiligten Komponenten: Abb Klassendiagramm: Controllerkomponenten des Backends

57 57 / 86 In den von der Basisklasse HttpServlet vererbten Methoden dopost() oder doget()wird zunächst die Methode checksessionvalidity() aufgerufen. Hier wird die Gültigkeit der Anfrage geprüft und anschließend durch Aufruf der Methode processrequest() weiterverarbeitet. Ist die Session nicht mehr gültig, wird eine Exception ausgelöst, die in der Methode checksessionvalidity() abgefangen und durch eine Weiterleitung auf die JSP-LoginSeite behandelt wird. In der Methode processrequest() des Controllers wird entschieden, wie die Action zu behandeln ist. Wie bereits erwähnt, wird in den Sichten, die keine Tabulatoren besitzen, der Request direkt im entsprechenden Controller behandelt. Kann die Action vom aktuellen Tabulator behandelt werden, so wird über ein forward der HTTPRequest an diesen weitergeleitet. Hier wird die Verbindung zur Geschäftslogik hergestellt und diese aktualisiert. Das Ergebnis dieser Ausführung wird anschließend im Session-Objekt abgelegt. Danach wird über ein forward die View aufgerufen, die die im Session-Objekt abgelegten Daten als JSP darstellt. Änderungen werden temporär an den Business-Objekten vorgenommen und erst nach der Action update persistent in der Datenbank abgelegt. Die in Abb dargestellten Aktionen list und command werden in den Controller durch die Methoden processlistrequest() bzw. processcommandrequest() verarbeitet und dienen der Steuerung der Frames im Backend. Sie werden im Kontext dieser Arbeit nicht weiter ausgeführt, da eine Implementierung eines Action-Handlers für diese Events nur dann notwendig wäre, wenn ein neues Hauptnavigationselement, also ein Button, im linken Teil des Frameworks der Hauptnavigation der Katalogansicht hinzugefügt würde.

58 58 / 86 Abb Sequenzdiagramm Ablauf Die Objekte, der von der Basisklasse Formular abgeleiteten Klassen, werden mit den im Deployment Descriptor registrierten Tabulatoren im Login-Controller initialisiert. Jede Katalogansicht basiert auf einem Formular, das über das Session-Objekt für die jeweilige Sitzung von dem entsprechenden Controller referenziert werden kann. Die Tabulator-Objekte existieren somit nur im Scope15 der Session, d.h. sie sind an die aktuelle Sitzung gebunden. Die von der Klasse Tabulator vererbten Methoden werden in den abgeleiteten Klassen überschrieben. Die Methoden zur Ablaufsteuerung besitzen in der Basisklasse Tabulator keine Implementierung, d.h. einen leeren Methodenrumpf. Je nach Kontext sind nur einige dieser Methoden zu überschreiben Zugriff auf die Persistenzschicht Die Persistenzschicht besteht aus dem Datenbanksystem, das die entsprechenden Daten dauerhaft in Tabellen ablegt und der Abstraktionsschicht, die den Zugriff auf die Datenbank aus Sicht der Businesslogik, die in den Controllern abgearbeitet wird, transparent macht. Diese Abstraktionsschicht wird durch die Klassen gebildet, die das Interface InfoManager implementieren. Diese Klassen sind nach dem Singleton-Designpattern implementiert, um sicherzustellen, dass immer nur eine Instanz dieser Klasse erstellt wird. Für den Zugriff auf die Persistenzschicht werden verschiedene Klassen bereitgestellt, die in der Terminologie von Omeco allgemein als Datenbankwrapper bezeichnet werden, weil sie den Zugriff auf die Datenbank kapseln. Durch die Klasse de.omeco.webshop.business.datasource.datamanager, die nach dem Factory-Pattern realisiert ist, wird der entsprechende Datenbankwrapper bereitgestellt. Die Datenbankwrapper werden in der Properties-Datei $BACKENDHOME/WEBINF/wrapper.properties registriert. Es wird hier für jeden Wrapper ein Eintrag erstellt, der der jeweiligen Wrapperbezeichung den vollqualifizierten Klassennamen der zu verwendenden WrapperKlasse zuordnet. Bei projektspezifischen Erweiterungen müssen in dieser Klasse die neuen Datenbankwrapper zuerst als Attribute vom Typ: java.lang.class angelegt werden. Diese Class-Objekte werden dann im Konstruktor instanziiert. Zu jeder Klasse existiert eine entsprechende Getter-Methode, die ein Wrapper-Objekt an die aufrufende Instanz, also einen InfoManager, zurückliefert. Das Interface DatasourceWrapper dient als Basisinterface für die eigenen Wrapper. Für den Zugriff auf die kundenbezogenen prozentualen Preisaufschläge implementiert die Klasse ItHausItemGroupWrapper dieses Basisinterface. Der Zugriff auf dieses Objekt erfolgt in der Klasse ItHausItemGroupInfoManager. Sie implementiert das Interface InfoManager und abstrahiert somit vom eigentlichen Datenbankzugriff. 15 Das Scoping regelt die Sichtbarkeit von Objekten innerhalb ihrer Web-Applikation.

59 Bekanntmachen des wrapper.properties Datei: 59 / 86 neuen Wrappers als Schlüssel-Wert-Paar in der Beispiel 6: Eintrag in der wrapper.properties ItHausItemGroupPriceWrapper=de.omeco.webshop.customerextension.ithaus. business.datasource.mysql.ithausitemgrouppricewrapper Beispiel 7: Instanziieren des neuen Wrappers private Class classithausitemgrouppricewrapper; public DataManager() { classithausitemgrouppricewrapper= Class.forName(prop.getProperty("ItHausItemGroupPriceWrapper")); } Um sich den passenden Datenbankwrapper über die Abstraktionsschicht geben zu lassen, muss schließlich noch die entsprechende Methode ergänzt werden. Beispiel 8: Implementierung einer Getter-Methode public DatasourceWrapper getithausitemgrouppricewrapper() { try { return (DatasourceWrapper) classithausitemgrouppricewrapper.newinstance(); } catch(exception e){ e.printstacktrace(); } return null; }

60 60 / 86 In Abb wird die Struktur als Klassendiagramm vereinfacht dargestellt: Abb Klassendiagramm Persistenzschicht 5.3.6Internationalisierung der Web-Anwendung Im Backend wird über das Objekt BackofficeContext der sprachspezifische Eintrag aus der Datei locales_xx_xx.properties geladen. Die Zeichen xx bzw. XX stehen dabei für die entsprechenden Länderkürzel, für Deutschland wäre das also die Datei locales_de_de.properties. Das Laden dieser sprachspezifischen Felderbeschriftungen erfolgt beim Login. Anhand des Kundenlogin kann die Spracheinstellung des Benutzers ermittelt und die entsprechende Sprachdatei geladen werden. Diese Aufgabe realisiert das BackofficeContext-Objekt. Anschließend kann über dieses Objekt, das für die Gültigkeit der Session zur Verfügung steht, der sprachspezifische Wert zu einem Schlüssel abgefragt werden. Beispiel 9: Sprachspezifischer Text in einer JSP ausgeben: BackofficeContext boc = (BackofficeContext) session.getattribute("backofficecontext"); boc.getstring("itemloading");

61 61 / Realisierung der Preisfindung Im B2B-Umfeld sind für eine gute Kundenbeziehung gute Kundenkonditionen wichtig. Die Berechung eines individuellen Verkaufspreises für jeden Kunden ist dabei gerade in diesem Umfeld sehr stark ausgeprägt. Im Zuge der Erweiterung für IT-Haus wurde daher der Webshop um ein komplexes Preismodul erweitert, um eine kundenbezogene Preisgestaltung zu ermöglichen. Abb soll einen ersten Überblick über den Prozess der Preisfindung geben: Abb Aktivitätsdiagramm Preisfindung

62 62 / Einstellen des Basispreises Die Basispreisfindung ist die erste Stufe des mehrstufigen Preisfindungsprozesses. Sie deckt den allgemeinen herstellerbezogenen, prozentualen Aufschlag auf alle Produkte einer Produktgruppe ab. Als Aufschlag wird zunächst ein Standardwert eingetragen, der über das Backoffice festgelegt werden kann. Er wird als Basiswert beim Anlegen neuer herstellerabhängiger Produktgruppen verwendet. Um diesen Basiswert individuell für jeden Hersteller einer Produktgruppe einstellen zu können, wurde im Produktkatalog die neue Sicht Preise erstellt. Nach dem Model-View-Controller Paradigma muss für die neue View auch eine Controller-Komponente und ein Model entworfen werden. Durch die modulare Gestaltung des Backends können jedoch für einfache Erweiterungen, wie das Hinzufügen einer neuen View, die bereits vorhandenen Komponenten genutzt werden. Wie bereits im vorherigen Kapitel erläutert, wird eine View über eine JSP realisiert, die fest an die Ablauflogik gebunden ist, welche von einer Instanz der Klasse Tabulator festgelegt wird. Um diese View zu integrieren und mit Daten zu versorgen, wurde die Klasse ItemGroupHerstellerTab als projektspeziefische Erweiterung des Backend-Frameworks angelegt. Beispiel 10: Registrierung eines neuen Tabulators an einem Formular: <servlet servlet-name="logincontrol" servlet-class="de.omeco.webshop.webui.core.logincontrol">... <init-param> <param-name>itemgroupformulartabs</param-name> <paramvalue> ItemGroupBaseTab, ItemGroupImageUploadTab, ItemGroupCustomerTab, de.omeco.webshop.customerextension. ithaus.webui.core.itemgroupherstellertab </param-value> </init-param>... </servlet> Die Aufgabe des neuen Tabulators besteht darin, die herstellerbezogenen Aufschläge zu verwalten. Die Requests werden von der Instanz der Klasse ItemGroupControl an den Tabulator weitergeleitet, der, je nachdem, welche Action ausgeführt werden soll, entscheidet, welche Methode des Tabulators ausgeführt wird.

63 63 / 86 Beim Auswählen des Tabulators Preise wird z.b. die Methode enter() aufgerufen, die den Session-Kontext für diese Sicht initialisieren soll. In diesem Fall müssen die Standardzuschläge für die Hersteller, die in der ausgewählten Produktgruppe vertreten sind, aus der Datenbank geladen werden. Als Datenstruktur für die Standardzuschläge und für die kundenspezifischen Zuschläge wurde die Klasse ItHausItemGroupPrice angelegt. Für jeden Hersteller der Produktgruppe wird ein Objekt dieser Klasse angelegt. Um den Zugriff und die Verwal-tung der Objekte über das Session-Kontext-Objekt zu vereinfachen, wurden alle Objekte in einer ArrayList gespeichert. In folgendem Beispiel wird die Implementierung der Methode enter() der Klasse ItemGroupHerstellerTab dargestellt: Beispiel 11: Implementierung der Methode enter public void enter(httpservletrequest request, MultipartRequest mrequest, HttpServletResponse response) { HttpSession session = request.getsession(false); ItemGroup selectedgroup = (ItemGroup) session.getattribute("itemgroup"); int gruppenid = selectedgroup.getid(); ItHausItemGroupInfoManager infomanager = ItHausItemGroupInfoManager.instance(); } ArrayList list = (ArrayList) infomanager.get(gruppenid); session.setattribute("itemgrouploading", list); Das Speichern der Benutzereingaben wird in der Instanz der Klasse ItemGroupController durch die Aktion update veranlasst. Der Kontroller führt daraufhin die Methode onupdate() auf den Tabulatoren des Formulars aus. Bevor jedoch die Daten in die Datenbank geschrieben werden, ist es sinnvoll, die Eingaben vorher zu validieren. Werden fehlerhafte Eingaben festgestellt, wie in diesem Fall z.b. die Eingabe eines ungültigen Wertes für einen Aufschlag, wird die Aktion abgebrochen und der Benutzer über den Fehler informiert. Für diesen Fall wurde von der Firma Omeco eine Fehlerbehandlung geschaffen, über die dies sehr einfach möglich ist. Vor dem Speichern der Daten muss abgefragt werden, ob ein HTMLFormErrorObjekt in der Session existiert. Ist dieses vorhanden, ist die Aktion zu beenden. Die Ausgabe der Fehlermeldung wird über den Head -Teil der inkludierten JSP realisiert, so dass sich der Entwickler an dieser Stelle nicht explizit darum kümmern muss. Wird ein Fehler durch die Validierung im Tabulator festgestellt, so wird ein Objekt vom Typ HTMLFormError in die Session geschrieben.

64 64 / 86 Beispiel 12: Fehlermeldung über die Session vorbereiten HTMLFormError err = new HTMLFormError(); err.adderrormessage(boc.getstring("it_invalidepreis") + " für Hersteller " + hname); session.setattribute("formularerrors", err); Zur Aktualisierung der Sicht werden die geänderten prozentualen Herstelleraufschläge nun vom Tabulator in die Session geschrieben. Anschließend wird über ein forward auf die JSP weitergeleitet. Die View für den Standardaufschlag wird durch die JSP /backoffice/customerextension/item_group_price.jsp realisiert. Diese kann sich die Daten, wie im folgenden Beispiel gezeigt, aus der Session holen und zur Darstellung an den Browser des Benutzers senden. Beispiel 13: Ausgabe der Daten in der JSP ArrayList arraylist = (ArrayList) session.getattribute("itemgrouploading");... <% for(iterator iter = arraylist.iterator();iter.hasnext();) { de.omeco.webshop.customerextension.ithaus. business.core.ithausitemgroupprice itemgroupprice = (de.omeco.webshop.customerextension.ithaus. business.core.ithausitemgroupprice) iter.next(); %> String name = itemgroupprice.getherstellername(); float aufschlag = itemgroupprice.getzuschlag(); <tr> <td class="label"><%=name %>:</td> <td> </td> <td class="label"><input type="text" class="text" name="hersteller<%=name%>" value="<%=aufschlag%>"style="width: 150px;"> </tr> <%}%> 5.4.2Kundenspezifische Aufschläge Die kundenbezogenen Preisaufschläge sind der nächste Schritt des Preisfindungsprozesses und überschreiben die Basisaufschläge. Über die ID des jeweiligen Kundenobjektes wird der Preis für jeden anzuzeigenden Artikel individuell ermittelt. Dieses Strategie wird in Front- und Backend gleichermaßen benutzt.

65 65 / 86 Die Berechnung des Preises für einen einzelnen Artikel erfolgt dabei zur Zeit des Seitenaufrufs durch das Frontend. Aus der Session des Frontends wird die ID des eingeloggten Kunden ermittelt und die Preise der ausgewählten Artikelgruppe individuell für ihn berechnet. Die Preisberechnung wird dabei, wie im Beispiel unten gezeigt, bereits auf der Datenbankebene durchgeführt. Beispiel 14: Preisberechnung durch das Frontend: select *, ROUND((WS_ARTIKEL.EKPREIS + (WS_ARTIKEL.EKPREIS / 100 * z.zuschlag)),2) as ITHPREIS from WS_ARTIKEL, IT_HERSTELLER_ARTKAT_KUNDE_ZUSCHLAG z where WS_ARTIKEL.HERSTELLER= and z.kundeid = and z.artkategorie = Die neuen Sichten werden über den Kontrollfluss der einzubindenden Tabulatoren referenziert. Neue Tabulatoren werden für den Kundenkatalog als init-parameter des Login-Controllers, wie im Beispiel unten gezeigt, registriert. Beispiel 15: Registrierung neuer Tabulatoren <servlet servlet-name="logincontrol" servlet-class="de.omeco.webshop.webui.core.logincontrol"> <init-param> <param-name>customerformulartabs</param-name> <param-value> de.omeco.webshop.customerextension.ithaus. webui.core.ithauscustomerdefaulttab, CustomerBillingTab, CustomerDeliveryTab, de.omeco.webshop.customerextension.ithaus. webui.core.ithauscustomerarticletab, de.omeco.webshop.customerextension.ithaus. webui.core.ithauscustomerarticlegrouploadingtab, de.omeco.webshop.customerextension.ithaus. webui.core.ithauscustomerclonetab </param-value> </init-param> </servlet>

66 66 / 86 Um für jeden Kunden individuelle, herstellerabhängige Aufschläge auf Produktgruppen vergeben zu können, müssen diese für den jeweiligen Kunden ausgewählt werden. Aus diesem Grund wurde dem Kundenkatalog ein zusätzlicher Tabulator hinzugefügt, der die Navigation über einen Produktgruppenbaum erlaubt und über den die Produktgruppen für einen Kunden ausgewählt werden können. Anders als im Produktgruppenkatalog wurde hier allerdings die Navigation auf einen neuen Tabulator ausgegliedert, um die Suchfunktion des Kundenmoduls weiterhin nutzen zu können. Der Tabulator ItHausCustomerArticleGroupLoadingTab muss die Aktionen für folgende drei Sichten behandeln: 1. customerextension/ithaus/customer/customerloadinggrouptree.jsp 2. customerextension/ithaus/customer/ithauscustomerarticlegrouploadingtab.jsp 3. customerextension/ithaus/customer/ customerarticlesubgroupproducer.jsp In der ersten Sicht muss der Tabulator die Kontrolle für die Navigation über den Produktbaum übernehmen. Diese Implementierung konnte weitestgehend aus dem ItemGroupController übernommen werden und brauchte nur in diesem Tabulator eingebunden zu werden. Für die zweite Sicht muss die Controller-Logik der Navigation des Produktbaumes zunächst ermitteln, wann ein Blatt selektiert ist, um dann die nächste JSP ausführen zu können. Als Controller für die Sicht ItHausArticleGroup LoadingTap.jsp muss der Tabulator die Verwaltung der ItHausItemGroupPriceObjekte übernehmen, die die Daten für diese View liefern. Schließlich muss der Tabulator für die letzte Sicht die Verwaltung der Untergruppen der vorher ausgewählten herstellerbezogenen Produktgruppe übernehmen. Diese Untergruppen werden durch Businessobjekt vom Typ ItHausItemGroupSubPrice ge-bildet. Der Controller muss dabei die erstellten Untergruppen dem aktuellen ItHausItemGroupPrice-Objekt zuordnen können. Die Verwaltung der ItHausItemGroupPrice-Objekte wird durch die Klasse ItHausItemGroupSession vereinfacht. Das Objekt wird, sofern es noch nicht vorhanden ist, beim ersten Aufrufen der Methode enter() der Tabulatorinstanz initialisiert und steht anschließend für die gesamte Dauer der Session zur Verfügung. In der JSP ithauscustomerarticlegrouploadingtab.jsp sollen sowohl die Basisaufschläge als auch die kundenspezifischen Aufschläge angezeigt werden, wobei die kundenspezifischen Aufschläge dabei die Basisaufschläge überschreiben sollen. Über die Methode getmergedartikelgroups() wird eine Instanz der Klasse java.util.hashmap erzeugt, in der zunächst alle ItHausItemGroupPriceObjekte der Basiszuschläge eingetragen werden. Die Einträge werden als SchlüsselWerte-Paare in dieser Datenstruktur abgespeichert. Als Schlüssel wird die Herstellerbezeichnung und als Wert das Objekt vom Typ ItHausItemGroupPrice verwendet, so dass ein bereits bestehender Eintrag für einen Hersteller durch das kundenspezifische Objekt überschrieben wird.

67 67 / 86 Die Reihenfolge der Ausgabe der ItHausItemGroupPrice-Objekte in der JSP hängt von der Reihenfolge der Einträge in der Liste ab, die von einer Methode der Klasse HashMap zurückgeliefert werden. Um eine einheitliche Reihenfolge der Herstellernamen in der Darstellung zu erreichen, werden die Objekte über die Methode sort(list) der Klasse java.util.collections, nicht zu verwechseln mit dem Interface Collection, sortiert. Soll ein ItHausItemGroupPrice-Objekt mit einem anderen verglichen werden, muss das Interface java.lang.comparable implementiert werden (vgl. Abb.5.4.2, S.68). Beispiel 16: Sortierung der Objekte in der JSP ItHausCustomerItemGroupSession obj_itemgroupsession = (ItHausCustomerItemGroupSession) session.getattribute("customerartikelgroupsession"); HashMap map = obj_itemgroupsession.getmergedarticlegroups(); ArrayList arraylist = new ArrayList(map.values()); Collections.sort(arrayList);

68 68 / 86 Abb Klassen zur Verwaltung der kundenbezogenen Preisaufschläge Die Daten der allgemeinen Preisaufschläge sowie die Daten der kundenbezogenen Preisaufschläge werden in der Datenbanktabelle IT_HERSTELLER_ ARTKAT_KUNDE_ZUSCHLAG abgespeichert.

69 69 / 86 Der Zugriff auf die Datenbank wird über das Objekt der Klasse ItHausItemGroupInfoManager von der eigentlichen Implementierung abstrahiert. Der Datenbankzugriff geschieht über eine Instanz des ItHausItem GroupPriceWrappers. Sie implementiert die Methoden des Interfaces Datasource Manager, um Daten anzulegen, zu aktualisieren oder zu löschen. Eine Besonderheit stellt die Methode getitemgroupcustomerprice(int arkatid) dar, die nur im Produktgruppenkatalog verwendet wird. Hier sollen beim Abrufen der Daten fehlende Einträge in der Tabelle ergänzt werden. Wenn z.b. durch Hinzufügen eines Artikels zu einer Produktgruppe ein neuer Hersteller in dieser Produktgruppe vertreten ist, für den noch kein Basisaufschlag angelegt wurde, soll dies automatisch nachgepflegt werden. Die prozentualen Aufschläge sind über die HerstellerID, die ArtikelgruppenID und die KundenID eindeutig (vgl. Abb.5.4.3) bestimmt. Die Basisaufschläge werden mit der KundenID 0 angelegt, da diese ID vom System nicht vergeben werden kann. Abb Auszug der kundenbezogenen Zuschläge Das Feld ZUSCHLAG_ID wird zur Verwaltung der Einträge und zur Referenzierung der Einträge aus der Tabelle IT_ARTIKELGRUPPE_ZUSCHLAG genutzt. In dieser Tabelle werden die Untergruppen gespeichert, die über Teile der Artikelnummern zusammengefasst werden ( siehe Abb ). Abb Auszug der kundenbezogenen Subgruppenzuschläge

70 70 / Kunden-Teile-Relation Die Kunden-Teile-Relation beschreibt die Beziehung zwischen Kunden und Artikeln. Die Preisgestaltung des Webshops ist so differenziert aufgebaut, dass für jeden Kunden auf jeden Artikel ein individueller Preis vergeben werden kann. Die Kunden-Teile-Relation wird durch die JSP /backoffice/customerextension /ithaus/itemcustomer.jsp dargestellt. Sie ersetzt die Original JSP. Der neuen Sicht wurde zusätzlich das Feld Aufschlag hinzugefügt, damit für einen Kunden nicht nur ein Fest-preis vergeben werden kann, sondern auch ein individueller prozentualer Aufschlag auf den Artikel. Um eine Übersicht über die Kunden-Teile-Relationen zu bieten, wurde in der Katalogansicht Kunde der zusätzliche Tabulator myproducts hinzugefügt, der alle Artikel auflistet, für die dem Kunden spezielle Konditionen gewährt wurden. Diese neue View wird durch die JSP /backoffice/customerextension/ithaus/customer/customerarticle.jsp realisiert. Zur Integration der eigenen Sichten in die Katalogansicht Artikel und die Katalogansicht Kunden mussten projektspezifische Tabulatoren implementiert werden, die von den Controllern referenziert werden. Für die Übersicht der Kunden-Artikel in der Katalogansicht ist der Controller ItHausCustomerControl verantwortlich. Wegen des modularen Aufbaus brauchte der Controller ItemControl für die Katalogansicht Artikel nicht ausgetauscht zu werden, sondern es musste nur ein neuer Tabulator eingebunden werden. Das Einbinden des neuen Tabulators geschieht über das Registrieren im Deployment Descriptor, wie es in den vorherigen Abschnitten bereits erläutert wurde. Eine Änderung, die für die Firma IT-Haus an dieser Sicht gemacht wurde, ist das automatische Füllen der Textfelder dieser Ansicht mit den Artikelbeschreibungen des ausgewählten Artikels. Da die Artikel ursprünglich für einen Kunden mit individuellen Artikelbeschreibungen ausgezeichnet werden sollten, arbeitet diese nicht mit dem Item-Objekt, wie die anderen Sichten des Artikelkataloges, sondern mit einem speziellen Objekt vom Typ CustomerItem. Das CustomerItem-Objekt beschreibt einen Artikel, der auf seine wesentlichen Merkmale reduziert wurde. Beim Auswählen des Tabulators myproducts wird vom Controller die Methode enter() des Tabulators aufgerufen. Hier wird initial ein ItHausCustomerItemObjekt mit den Daten des aktuellen Item-Objekts angelegt, dessen Daten über die JSP dargestellt werden. Wird ein Kunde ausgewählt, so wird das kundenspezifische Objekt dargestellt, wie es schon in der Basisversion realisiert wurde. Zur Verwaltung der CustomerItem-Objekte in der Session wird die Klasse ItemSession verwendet.

71 71 / 86 Abb Klassendiagramm CustomerItem Die Klasse ItHausCustomerItem wird 1:1 auf die Tabellenstruktur abgebildet. Dafür musste die Tabelle WS_KUNDE_TEIL durch die Tabelle IT_KUNDE_TEIL ersetzt werden, um das neue Feld Aufschlag aufzunehmen. Zum Zugriff auf die neue Tabelle wurde der Datenbankwrapper über die Datei wrapper.properties ausgetauscht: