Entwicklung eines Adobe Flex Webshops mit Anbindung an ein ERP-System

Aus Winfwiki

Name des Autors:	Christoph Thielen
Titel der Arbeit:	Entwicklung eines Adobe Flex Webshops mit Anbindung an ein ERP-System
Hochschule und Studienort:	FOM Essen

Inhaltsverzeichnis 1 Einleitung 1.1 Zielsetzung 1.2 Vorgehensweise 2 Grundlagen 2.1 E-Commerce 2.1.1 Onlineshops im Vergleich zu Marktplätzen 2.1.2 Beziehung der Transaktionspartner untereinander 2.1.2.1 Business to Consumer (B2C) 2.1.2.2 Weitere Beziehungen und ihre Eignung für einen Adobe Flex Onlineshop 2.1.3 Produkteignung für den Onlinevertrieb 2.2 Webapplikationen 2.2.1 Technologien 2.2.1.1 Serviceorientierte Architektur 2.2.1.2 Webservices 2.2.1.3 Rich Internet Applications (RIA) 2.2.2 Programmiersprachen für RIAs 2.2.2.1 Adobe Flex 2.2.2.2 Microsoft Silverlight 2.2.2.3 AJAX 2.2.2.4 Java 2.3 ERP-Systeme 3 Fachkonzept 3.1 Zieldefinition 3.1.1 Umzusetzende Funktionalität 3.1.2 Weitere erforderliche Funktionalität für den Produktiveinsatz 3.2 Produkteinsatz 3.3 Ablauf des Einkaufvorgangs 3.4 Systemarchitektur 3.5 Qualitätsanforderungen 3.5.1 Erweiterbarkeit 3.5.2 Wartbarkeit 3.5.3 Benutzbarkeit 3.6 Benutzerschnittstellen 3.6.1 Kommunikationsaufbau 3.6.2 Eingabemasken 4 Technisches Konzept 4.1 Systembeschreibung 4.1.1 Systemumgebung 4.1.2 Entwicklungsumgebung 4.1.3 Programmiersprache 4.1.4 Anforderungen an den PC des Anwenders 4.2 Datenbankaufbau 4.3 Definition der Schnittstellen 4.3.1 Produktdatenschnittstellen 4.3.2 Bestellungsdatenschnittstelle 4.4 Entwicklungen im ERP-System 4.5 Aufbau des Front-Ends 4.5.1 Fachklassen 4.5.2 Darstellungskomponenten 4.5.3 Steuerung der Ablauflogik 4.5.4 Kommunikation zwischen den Front-End-Komponenten 4.5.4.1 Produkte zum Warenkorb hinzufügen 4.5.4.2 Anzeigen der Vergleichsansicht 4.5.4.3 Durchführen des Bestellvorgangs 4.6 Durchzuführende Testschritte 5 Bewertung 5.1 Herausforderungen bei der Umsetzung der Applikation 5.2 Effekte auf Unternehmen durch die Integration eines Adobe Flex Onlineshops 5.3 Auswirkungen von Adobe Flex Shopapplikationen auf Kunden 5.4 Entwicklungsperspektiven 6 Schlussbetrachtung 7 Fußnoten 8 Literaturverzeichnis 9 Abkürzungsverzeichnis

1 Einleitung

In der heutigen Zeit kann man nahezu jedes Produkt im Internet kaufen. Abgesehen von wenigen exklusiven Waren stehen für den Kauf eines Produktes viele verschiedene Onlineshops zur Verfügung. Um sich von der Konkurrenz abzugrenzen, gibt es unterschiedliche Möglichkeiten für den Betreiber eines Onlineshops. Neben einem vergleichsweise günstigen Preis, einer besonders hohen Produktqualität und überdurchschnittlichen Serviceleistungen, spielt auch der Aufbau des Onlineshops und somit die Produktpräsentation eine wichtige Rolle bei der Erlangung einer USP (Unique Selling Proposition) und damit bei der Gewinnung neuer Kunden.

Sowohl im Internet als auch in Geschäften spielt die emotionale Ebene eine große Rolle bei der Anbahnung und Aushandlung von Geschäften. Im Internet kann diese emotionale Ebene hauptsächlich durch den Aufbau des Onlineshops und durch die Produktpräsentation angesprochen werden. Dieses Thema wird von den meisten derzeit bestehenden Onlineshops nahezu völlig ignoriert.

1.1 Zielsetzung

Im Rahmen dieser Diplomarbeit wird ein Konzept zur Erstellung eines neuen Onlineshops auf Basis von Adobe Flex erstellt und ein Prototyp dieses Onlineshops entwickelt. Um in der Vielzahl der existierenden Shopsysteme positiv herauszuragen und somit die Kundengewinnung des shopeinsetzenden Unternehmens zu unterstützen, wird in dem zu entwickelnden Onlineshop besonders auf eine ansprechende Produktpräsentation geachtet. Um dieses Ziel zu erreichen, werden unaufdringliche Animationen, die von dem Programmierframework zur Verfügung gestellt werden, sinnvoll eingesetzt. Im Vordergrund des Prototyps stehen also die Kundenbedürfnisse. Dies beinhaltet auch eine übersichtliche Navigationsführung und einen intuitiv ausführbaren Bestellvorgang.

Eine komplikationsfreie Anbindung des Shopsystems an auf Unternehmensseite existierende ERP-Systeme ist ein Ziel, welches verfolgt wird, um die Bestellabläufe der Unternehmen optimal umsetzen zu können.

Alle weiteren Funktionen, die für einen Produktiveinsatz des Shopsystems realisiert werden müssen, werden im Rahmen der Diplomarbeit kurz erläutert, sind aber nicht Bestandteil der Arbeit und werden deshalb im Prototyp nicht umgesetzt.

1.2 Vorgehensweise

Zu Beginn der Diplomarbeit wird ein Überblick über die betriebswirtschaftlichen und technischen Grundlagen, die im weiteren Verlauf der Arbeit relevant sind, gegeben. Dabei wird auch der Begriff E-Commerce definiert, da die zu entwickelnde Applikation im E-Commerce eingesetzt wird. Im Anschluss an die Grundlagen werden die Anforderungen an den Onlineshop aus Unternehmenssicht definiert. Auf Grundlage dieser Anforderungen wird danach das technische Konzept erstellt, in welchem die verschiedenen Tätigkeiten zur Erstellung des Shopsystems, sowie die Schnittstellen zur Kommunikation mit angebundenen ERP-Systemen spezifiziert werden. Dieses technische Konzept dient als Basis für die Entwicklung des Prototyps. Im Anschluss an die Entwicklung des Prototyps findet eine Bewertung des neu erstellten Shopsystems statt. Aufgrund des fehlenden Praxiseinsatzes des Shopsystems stehen für diese Bewertung keine auswertbaren Zahlen zur Verfügung. Deshalb wird bei der Bewertung hauptsächlich der Quervergleich zu klassischen Shopsystemen gezogen. Abschließend werden die Entwicklungsergebnisse in einem Fazit zusammengefasst und erläutert, unter welchen Umständen ein Einsatz des neuen Shopsystems sinnvoll ist.

2 Grundlagen

Immer mehr Einkäufe finden heutzutage im Internet statt. Dies liegt zum einen an einer gestiegenen Akzeptanz für Onlineshopping, zum anderen aber auch an dem steigenden Angebot an Produkten und Verkaufsplätzen im Internet. Mittlerweile sind nahezu alle Güter im Internet erwerbbar. Manche Güter können nur im Internet eingekauft werden. Die nachfolgenden Abschnitte behandeln die Grundlagen zum Thema E-Commerce und geben einen Überblick über die technischen Möglichkeiten, mit deren Hilfe Anwendungen für das E-Commerce erstellt werden können.

2.1 E-Commerce

In der Literatur und im allgemeinen Gebrauch finden sich heute eine Vielzahl an verschiedenen Definitionen zum Thema E-Commerce. Ähnlich wie andere Begriffe, die im Zusammenhang mit dem Internet gebraucht werden, wird der Begriff E-Commerce oft verwendet, ohne dass die jeweilige Bedeutung bzw. der Umfang des Begriffes dabei eindeutig geklärt ist^[1]. Je nach Sichtweisen auf das Thema E-Commerce werden unterschiedliche Aspekte davon betrachtet^[2]:

• Kommunikationssicht: Bereitstellung von Informationen, Produkten oder Bezahlmöglichkeiten über Netzwerke.
• Geschäftsprozesssicht: Umsetzung der Technologie zum Automatisieren von Geschäftsvorfällen.
• Servicesicht: Möglichkeit, die Kosten zu reduzieren bei gleichzeitiger Qualitätsverbesserung für Dienstleistungen.
• Onlinesicht: Fähigkeit, Güter und Informationen über das Internet und andere Netzwerke zu verkaufen.

Eine relativ frühe, weite Definition des Begriffs fasst alle wirtschaftlichen Tätigkeiten, auf Basis elektronischer Verbindungen, unter dem Begriff E-Commerce zusammen. Diese Definition wird mittlerweile für den Begriff E-Business genutzt. E-Commerce als Teilbereich des E-Business beschreibt die digitale Anbahnung, Aushandlung und Abwicklung von Transaktionen zwischen verschiedenen Wirtschaftssubjekten^[3]. Diese relativ einfache Definition führte dazu, dass der Aufwand, der zur erfolgreichen Implementierung von E-Commerce gehört, unterschätzt wurde. Neben dem Anbinden einer Katalogsoftware an ein SCM- oder ERP-System gehört auch eine Überprüfung und Anpassung der Ablauf- und Aufbauorganisation eines Unternehmens zur Implementierung von E-Commerce^[4].

2.1.1 Onlineshops im Vergleich zu Marktplätzen

Der Onlineshop, auch E-Shop genannt, ist eine Möglichkeit für Anbieter, Waren im Internet zu verkaufen. Normalerweise werden im Onlineshop nur Produkte von einem einzelnen Anbieter angeboten. Dieser hat die Wahl, ob er den Onlineshop selber betreibt oder Betrieb, Wartung, Support und weitere Dienstleistungen bei einem anderen Dienstleister einkauft. Es gibt sowohl fertige Shopsysteme, die nach dem Erwerb an das entsprechende Unternehmen angepasst werden können und ohne großen Aufwand betriebsbereit sind, als auch die Möglichkeit zur Eigenentwicklung. Zwischen den verschiedenen Shopsystemen bestehen erhebliche Unterschiede. Während manche Shopsysteme nur rudimentäre Funktionen zur Bestellabwicklung anbieten, ermöglichen andere Systeme eine komplett automatisierte Bestell- und Auftragsabwicklung. Angefangen bei der Präsentation des Produktkatalogs über die Erfassung von Kundenbestellungen bis hin zur Erstellung der Rechnung und dem Versenden der Ware können alle Aufgaben mit Hilfe des entsprechenden Shopsystems und den daran angebundenen weiteren Softwareprodukten automatisiert bewältigt werden. Eigenentwickelte Software kann hierbei am Besten an die eigenen Bedürfnisse und Geschäftsprozesse angepasst und in die bestehende Systemlandschaft integriert werden.

Der E-Marketplace bzw. elektronische Marktplatz ist im Gegensatz zum Onlineshop eine Plattform, über die der Marktplatzbetreiber alle notwendigen Informations- und Kommunikationstechnologien zur Unterstützung und Abwicklung von online Transaktionen für Anbieter von Waren zur Verfügung stellt. Im Gegensatz zu realen Marktplätzen sind elektronische Marktplätze weder durch zeitliche noch durch örtliche Begrenzungen eingeschränkt^[6]. Der Zugang für Nachfrager ist normalerweise offen. Anbieter müssen für die angebotenen Dienstleistungen i.d.R. bezahlen^[7]. Dafür erhalten sie in E-Marketplaces zumeist alle relevanten Funktionalitäten für das Einstellen und Verwalten von Produkten, für die Kommunikation mit potenziellen Kunden und für die gesamte Verkaufsabwicklung (siehe Abbildung "Leistungsaustauschmodell bei Marktplätzen"). Nachfrager können in elektronischen Marktplätzen Produkte suchen, vergleichen und bestellen^[8].

Teilweise treten Marktplatzbetreiber als Intermediäre oder Treuhänder bei Bestellvorgängen auf. Sie übernehmen dann das Versenden der Produkte, ziehen den fälligen Betrag vom Nachfrager ein und überweisen das Geld an den Anbieter. Dadurch wird die Sicherheit für Nachfrager und Anbieter erhöht.

Marktplätze können in horizontale und vertikale Marktplätze unterteilt werden. Horizontale Marktplätze bieten branchenübergreifende Ein- und Verkaufslösungen. Sie decken zumeist nicht die gesamte Wertschöpfungskette, sondern nur den Verkauf ab^[9]. Vertikale Marktplätze hingegen sind auf eine Branche spezialisiert. Sie sind auf die Bedürfnisse dieser Branche fokussiert und decken oft die gesamte Wertschöpfungskette ab^[10].

2.1.2 Beziehung der Transaktionspartner untereinander

Bei jeder Ein- bzw. Verkaufstransaktion treten mindestens zwei Akteure auf. Diese können in drei verschiedene Typen unterteilt werden^[12]:

• private Konsumenten (Consumer)
• Unternehmen (Business)
• Verwaltung / öffentliche Einrichtung (Administration)

Sowohl auf der Nachfrager- als auch auf der Anbieterseite können bei einer Transaktion Akteure dieser Typen teilnehmen. Dadurch ergeben sich neun verschiedene Kombinationen (siehe Abbildung "Vertriebswegskombinationen"). Die wichtigsten Beziehungen werden nachfolgend kurz erläutert und ihre Eignung für den zu entwickelnden E-Shop dargestellt.

2.1.2.1 Business to Consumer (B2C)

Im B2C-Bereich findet die Transaktion zwischen einem Unternehmen als Anbieter und einem privaten Konsumenten als Nachfrager statt. Der Marktkontakt ist dabei i.d.R. nur von kurzer Dauer. Neben der Produktauswahl stehen im B2C-Bereich die Bestellung und Bezahlung im Vordergrund des Kaufprozesses^[13]. Das Transaktionsvolumen ist im B2C-Bereich vergleichsweise gering. Als Ausgleich dafür finden aber relativ viele Transaktionen über diesen Vertriebsweg statt^[14]. Der zu entwickelnde Onlineshop ist besonders für Geschäfte im B2C-Bereich geeignet. Private Konsumenten legen viel Wert auf die Produktpräsentation und das Einkaufserlebnis. Diese Erwartungen können in einem Adobe Flex Onlineshop oder vergleichbaren Shopsystemen besser befriedigt werden, als in einem herkömmlichen Shopsystem.

2.1.2.2 Weitere Beziehungen und ihre Eignung für einen Adobe Flex Onlineshop

Neben dem B2C-Handel eignet sich ein Onlineshop ebenfalls im B2B- und C2C-Bereich.

Im B2B-Bereich sind die Geschäftsbeziehungen zwischen den beiden handelnden Unternehmen längerfristiger ausgelegt als im B2C-Bereich^[15]. Neben der reinen Beschaffung von Produktionsfaktoren steht eine Reduzierung der Transaktionskosten durch Optimierung der Geschäftsprozesse im Vordergrund der unternehmensübergreifenden Geschäftsbeziehungen. Diese Optimierung kann im E-Commerce, dank der erhöhten Preistransparenz und der vereinfachten Kommunikation zwischen den Geschäftspartnern z.B. durch eine Steigerung der Beschaffungsproduktivität, erfolgen^[16]. Die Produktpräsentation ist in dem Bereich eher nebensächlich. Längere Ladezeiten des Onlineshops und visuelle Effekte bei der Auswahl von Produkten wirken dem Ziel, die Beschaffungsproduktivität zu steigern, eher entgegen. Aus diesem Grund sind klassische Onlineshops im B2B-Bereich geeigneter als ein Onlineshop auf Adobe Flex Basis.

Eine eher untypische Geschäftsbeziehung tritt im C2C-Bereich auf. Hier handeln Konsumenten oder Privatpersonen untereinander. Dieser Handel wird durch kommerzielle Auktionsplattformen, wie z.B. eBay und Tauschbörsen, unterstützt und gefördert^[17]. Bei diesen Plattformen handelt es sich i.d.R. um horizontale elektronische Marktplätze. Da dort gewerbliche und private Anbieter parallel auftreten können, ist der Funktionsumfang für Anbieter meistens deutlich geringer als bei elektronischen Marktplätzen im B2C-Bereich. Privaten Anbietern reicht die Funktionalität zum Anbieten und Verkaufen ihrer Güter sowie zur Kontaktaufnahme mit potenziellen Kunden. Auch in diesem Bereich würden sich moderne Onlineshops auf Basis von Rich Internet Applications (siehe Abschnitt "Rich Internet Applications (RIA)") anbieten. Allerdings würde eine Anbindung zum ERP-System des privaten Anbieters wegfallen. Da Anbieter und Nachfrager bei dieser Geschäftsbeziehung gleichberechtigt sind, spricht man auch von einem Peer to Peer (P2P) Verhältnis^[18].

Onlineshops im B2A-Bereich eignen sich hingegen nur bedingt, da die öffentlichen Einrichtungen neben Produkten auch Informationen, Umsatzsteuermeldungen und statistische Daten von Unternehmen nachfragen^[19].

2.1.3 Produkteignung für den Onlinevertrieb

Obwohl alle erdenklichen Güter und Dienstleistungen über das Internet angeboten und vertrieben werden können, eignen sich einige Güter besser für den elektronischen Vertrieb als andere Güter. Prädestiniert für den online Vertrieb sind alle Produkte, die nicht oder nicht nur in physischer Form verfügbar sind und deren Distribution vollständig über elektronische Netzwerke erfolgen kann. Hierbei spricht man von digitalen Gütern^[20].

Produkte, bei denen die Lieferung nicht digital erfolgen kann, können nach dem 3-B-Modell (siehe Abbildung "3-B-Modell der Produkteignung") beurteilt werden, um ihre Eignung für den online Vertrieb herauszufinden. Dieses Modell beinhaltet die folgenden Kriterien^[22]:

• Digitale Beschreibbarkeit: Produkte, deren Eigenschaften gut für Kunden beschrieben werden können (bspw. PC-Hardware), eignen sich besser für den elektronischen Vertrieb als Produkte, deren Eigenschaften nicht ausreichend beschreibbar sind (bspw. Parfüm).
• Digitale Beurteilbarkeit: Beim Verkauf von Produkten über das Internet fehlt dem Kunden die Möglichkeit der realen Prüfung der Produkte. Nahrungsmittel und vergleichbare Produkte lassen sich über das Internet nicht auf ihre Frische hin beurteilen und deshalb schwerer über das Internet verkaufen, als Produkte, die digital beurteilt werden können.
• Digitaler Beratungsaufwand: Je mehr Informationen zur Beurteilung eines Produktes benötigt werden, umso wahrscheinlicher ist es, dass eine Beratung durch den Anbieter erforderlich ist, um den Kunden zum Erwerb des Produktes zu bewegen. Ein hoher Beratungsaufwand wirkt sich somit nachteilig auf die elektronische Vertriebseignung des Produktes aus.

Neben dieser Analysemöglichkeit gibt es aber auch diverse andere Kriterien zur Beurteilung der Online-Vertriebseignung von Produkten. Die Abbildung "Onlinevertriebseignung von Produkten" zeigt die Kriterien, die laut einer Studie der Firma United-Research vor dem online Vertrieb analysiert werden sollten.

2.2 Webapplikationen

Das Internet wird mittlerweile als Plattform für die Applikationsausführung genutzt. Neben konventionellen Webapplikationen, die bspw. in den Bereichen Internetbanking, E-Mail oder dynamischer Webseitengenerierung eingesetzt werden, werden inzwischen auch klassische Desktopapplikationen, z.B. zur Bild- oder Textverarbeitung, im Internet angeboten^[24]. Diese Anwendungen können über einen normalen Browser geöffnet bzw. geladen werden. Diesen Trend machen sich einige Unternehmen zu nutze. Sie stellen ihren Mitarbeitern Software zur Abwicklung von alltäglichen Aufgaben im Intranet zur Verfügung. Dadurch wird sowohl die Distribution als auch die Wartung der Software erheblich erleichtert, da diese nur noch an einem zentralen Ort, dem Web- oder Applicationserver gespeichert und ausgeführt wird. Allerdings kann ein Ausfall dieses Servers zu erheblichen Problemen führen, da die Software dann für die Dauer des Systemausfalls nicht ausführbar ist.

Moderne Webapplikationen werden nicht mehr nur auf dem Web- oder Applicationserver ausgeführt. Wenn sie ausgeführt werden sollen, wird die meiste Arbeit an den aufrufenden PC des Anwenders übertragen. Auf diesem PC muss dafür zusätzliche, i.d.R. kostenlose Software installiert sein. Diese Webapplikationen können durch die benötige Software zur Ausführung deutlich mehr Funktionen als gewöhnliche Webapplikationen anbieten.

In den folgenden Abschnitten werden Technologien und Programmiersprachen für moderne Webapplikationen erläutert.

2.2.1 Technologien

Moderne Webapplikationen setzen größtenteils auf die gleichen Technologien. Diese werden nachfolgend genauer beleuchtet.

2.2.1.1 Serviceorientierte Architektur

Bei der Serviceorientierten Architektur (kurz SOA) werden die Services als standardisierte Grundkomponenten von verteilten Anwendungen angesehen^[25]. Diese Services stellen normalerweise wiederholbare Arbeitsschritte eines Geschäftsprozesses dar^[26]. Sie können von verschiedenen Anwendungen aufgerufen werden und liefern i.d.R. das Ergebnis ihrer Arbeit an die aufrufende Applikation zurück. Anwendungen, die verschiedene wiederkehrende Arbeitsschritte abbilden, können durch die geschickte Orchestrierung von Services mit relativ geringem Aufwand realisiert werden. Die eingebundenen Services können bei Bedarf gegen vergleichbare Services von anderen Anbietern ausgetauscht werden. Die Korrektur bzw. Modifikation der Services kann ohne Änderungen an den einbindenden Applikationen durchgeführt werden. Oft werden die Services in Form von Webservices (vgl. Abschnitt "Webservices") von den Service-Anbietern zur Verfügung gestellt.

2.2.1.2 Webservices

Unter einem Webservice versteht man eine eigenständige Softwarekomponente, die im Internet eindeutig über ihre URL identifiziert und angesprochen werden kann. Webservices können von beliebigen Applikationen, unabhängig von ihrer Programmiersprache, aufgerufen werden. Sowohl der Aufruf als auch die Antwort erfolgt dabei nach einer fest definierten Spezifikation im XML-Format^[27].

Die Kommunikation zwischen Webservices untereinander oder zwischen Webservices und Applikationen erfolgt über SOAP. Dieses Protokoll wurde für die Übertragung von XML-Dateien im ASCII-Format entwickelt. Dadurch kann die Kommunikation ohne zusätzliche Codierung bzw. Decodierung erfolgen und ist auch problemlos zwischen verschiedenen Betriebssystemen möglich^[28].

Spezifiziert werden Webservices über die WSDL. Sie ist im XML-Format aufgebaut und beschreibt, was ein Webservice tun kann, wie er aufgerufen werden muss und wo er zu finden ist^[30]. In der Grafik "Zusammenhang von Webservices und WSDL" wird der Zusammenhang von Webservices und der WSDL dargestellt.

2.2.1.3 Rich Internet Applications (RIA)

Mit dem Begriff Rich Internet Application (RIA) wird eine relativ moderne Art von Webapplikationen bezeichnet. Im Gegensatz zu herkömmlichen Webapplikationen ist bei RIAs nicht der Webserver für die Präsentation der Anwendung auf dem Client zuständig. Diese Aufgabe wird bei RIAs vom Client selbst übernommen^[31]. Dadurch kann wesentlich schneller auf Benutzereingaben reagiert werden, da nicht mehr alle Anfragen an den Webserver gesendet werden müssen.

Bei RIAs wird die Anwendung i.d.R auf den PC des Anwenders geladen. Auf diesem muss ein entsprechendes Plug-In installiert sein, damit die heruntergeladene Anwendung ausgeführt werden kann. Diese Plug-Ins sind normalerweise kostenfrei und für die meisten Betriebssysteme verfügbar. In Abbildung "Aufgabenverteilung bei HTML-Applikationen und RIAs" wird dargestellt, welche Aufgaben vom Client und welche Aufgaben vom Server übernommen werden.

2.2.2 Programmiersprachen für RIAs

Die im Abschnitt "Rich Internet Applications (RIA)" beschriebenen RIAs können durch den Einsatz von verschiedenen Programmiersprachen realisiert werden. In den folgenden Abschnitten werden die wichtigsten dieser Programmiersprachen kurz vorgestellt. Eine komprimierte Gegenüberstellung dieser Programmiersprachen kann man der Tabelle "Vergleich der Programmiersprachen" entnehmen.

Vergleich der Programmiersprachen

	Flex	Silverlight	Java	AJAX
Entwickler	Macromedia / Adobe	Microsoft	Sun	Diverse
Plug-In	Flashplayer	Silverlight	JRE	ohne
Verbreitung	hoch	gering	sehr hoch	sehr hoch
Betriebssysteme	Windows, Mac OS X, Linux, Solaris[33]	Windows, Mac OS X, Linux[34]	Windows, Mac OS X, Linux, Solaris[35]	Windows, Mac OS X, Linux, Solaris
Layouterstellungskomplexität	mittel	mittel	hoch	hoch
Visuelle Effekte	viele	viele	wenige	nahezu keine
Erstellbare Applikationen	RIAs, Desktopanwendungen (AIR)	RIAs	RIAs, Desktopanwendungen, Webapplikationen	RIAs, Webapplikationen
Entwicklungslizenz	kostenfrei	kostenfrei	kostenfrei	kostenfrei

2.2.2.1 Adobe Flex

Seit 2002 gibt es die Möglichkeit, Flash nicht nur für Animationen sondern auch für die Entwicklung webbasierter Anwendungen einzusetzen. Dies wurde durch die Einführung der Skriptsprache ActionScript (AS) ermöglicht. Seit 2004 existiert die erste Version von Flex, eine Weiterentwicklung des Trends weg von den reinen Animationen, hin zur Anwendung^[36]. 2008 wurde von Adobe die dritte Version von Flex veröffentlicht. Diese Version ist im Gegensatz zu den Vorgängerversionen OpenSource und somit auch für Entwickler kostenfrei.

Neben AS gibt es seit Flex 2 die Möglichkeit, Teile der Anwendung in MXML zu entwickeln. MXML ist dabei besonders für den Präsentationsteil der Anwendung geeignet. Zum Ausführen von RIAs, die mit Flex 3 entwickelt wurden, wird der Flashplayer 9 benötigt.

2.2.2.2 Microsoft Silverlight

Die Antwort von Microsoft auf Adobe Flex nennt sich Silverlight. Diese Technologie beruht auf XAML. Anders als bei Flex werden Silverlight-Anwendungen nicht binär sondern im Textformat an den Client-PC übertragen. Dadurch sind Silverlight-Anwendungen leichter aktualisierbar und ihre Sicherheit kann besser von Firewalls überprüft werden^[37].

Nachteilig kann sich für Microsoft bei der Verbreitung von Silverlight allerdings auswirken, dass das Plug-In, welches zur Ausführung von Silverlight-Anwendungen benötigt wird, nicht annähernd so weit verbreitet ist, wie der Flashplayer. Das erforderliche Plug-In wird von Microsoft derzeit lediglich für Windows und für Mac OS X angeboten. Unter dem Namen Moonlight wird ein OpenSource Plug-In für Linux angeboten, welches nicht von Microsoft entwickelt wurde^[38].

2.2.2.3 AJAX

AJAX (Asynchronous JavaScript and XML) bezeichnet vielmehr eine Kombination verschiedener Technologien als eine Programmiersprache. Es greift auf die bekannten Komponenten (D)HTML und JavaScript zurück.

Die Präsentation der Webanwendung wird bei AJAX in den meisten Fällen durch (D)HTML übernommen. JavaScript wird verwendet, um auf Anwenderaktionen zu reagieren und Daten im Hintergrund bspw. über Webservices zu laden. Dadurch muss die Webseite nicht bei jeder Anwenderaktion komplett neu vom Webserver heruntergeladen werden und steht dem Anwender auch schon bereit, ohne dass die Daten komplett übertragen wurden.

AJAX kann von den meisten Browsern verarbeitet werden. Zur Ausführung von AJAX-Applikationen ist kein Plug-In erforderlich. Allerdings kann sowohl die Darstellung als auch die Ausführung der Applikation in den verschiedenen Browsern abweichen. Um AJAX-Applikationen für verschiedene Browser nutzbar zu machen, muss ein hoher Entwicklungs- und Testaufwand betrieben werden^[39].

2.2.2.4 Java

Java ist die Älteste der hier vorgestellten Programmiersprachen. Sie wurde 1993 von der Firma Sun entwickelt^[40]. Dadurch ist das erforderliche Plug-In, um Java-Applets ausführen zu können, auf den meisten PCs installiert. Dieses Plug-In, die so genannte JRE, gibt es für nahezu jedes Betriebssystem. Allerdings ist die Erstellung von ansprechenden grafischen Anwendungen, anders als in Flex oder Silverlight, wesentlich komplizierter. Da Java-Anwendungen zumindest in der Anfangszeit nicht performant waren, ist der Hype um Java-Applets ähnlich schnell wieder abgeklungen, wie er entstanden ist.

2.3 ERP-Systeme

ERP-Systeme zählen zur Kategorie der betriebswirtschaftlichen Standardsoftware. Mit Hilfe von ERP-Systemen können die betriebswirtschaftlichen Prozesse eines Unternehmens unterstützt werden. Die einzelnen Komponenten zur Unterstützung von Vertrieb, Materialwirtschaft, Controlling, Personalwirtschaft, etc. können an die Bedürfnisse der Unternehmen angepasst und von diesen weiterentwickelt werden. Als Grundlage für ERP-Systeme dient eine Datenbasis, auf die alle Komponenten des ERP-Systems Zugriff haben. Dadurch wird eine redundante Datenhaltung vermieden. ERP-Systeme sind verteilte Systeme. Mitarbeiter aus verschiedenen Abteilungen, auch von verschiedenen Standorten eines Unternehmens, können auf die verschiedenen Komponenten des ERP-Systems zugreifen^[41].

In Deutschland und vielen anderen Ländern ist SAP Marktführer im Bereich der ERP-Systeme. Die neueren Versionen der SAP-ERP-Systeme laufen in einer Systemlandschaft, die für das Bereitstellen von Webservices für den Datenaustausch mit weiteren Systemen gut geeignet ist. Aus diesen Gründen wird der zu entwickelnde Onlineshop an ein SAP-System angebunden.

3 Fachkonzept

In diesem Kapitel werden die Anforderungen an den zu erstellenden Prototypen des Adobe Flex Onlineshops näher erläutert. Dabei wird auch auf die Kommunikation mit dem ERP-System eingegangen.

3.1 Zieldefinition

In dem zu erstellenden Onlineshop sollen Notebooks, Desktop-PCs, Monitore, Drucker und PC-Zubehör vertrieben werden. Die Produkte sind alle fertig konfiguriert. Einzelne Komponenten können vom Anwender nicht geändert werden. Diese Produkte sind zwar nicht optimal für den Onlinevertrieb geeignet, bieten sich aber nach einer Analyse mit Hilfe des 3-B-Modells (vgl. Abschnitt "Produkteignung für den Onlinevertrieb") für den Verkauf in Onlineshops an. Nachfolgend werden die Funktionalitäten definiert, die für den Onlineshop im Rahmen der Diplomarbeit umgesetzt werden sollen. Anschließend werden die weiteren Funktionen beschrieben, die für die Produktivsetzung des Shops erforderlich sind.

3.1.1 Umzusetzende Funktionalität

Die folgenden, für den Onlinevertrieb notwendigen Funktionalitäten, werden umgesetzt:

• Produktpräsentation (Übersicht): Die zu verkaufenden Produkte sollen in dem Shopsystem übersichtlich in einer Matrix dargestellt werden. In dieser Darstellung sollen die wichtigsten Informationen (Bild, Hersteller, Name, Preis) angezeigt werden. Aus dieser Darstellung heraus soll es möglich sein, die Detailinformationen zu einem Produkt aufzurufen, es in den Warenkorb zu legen oder es für den Vergleich zu markieren.
• Detailinformationen: In der Detaildarstellung sollen alle für den Kunden relevanten Daten zu dem Produkt dargestellt werden. Auch in dieser Darstellung soll es möglich sein, das Produkt in den Warenkorb zu legen. Zusätzlich soll der Anwender die Produktdetails als PDF herunterladen können.
• Produktvergleich: Vom Anwender markierte Produkte sollen in der Vergleichsdarstellung tabellarisch nebeneinander dargestellt werden. In dieser Darstellung sollen zeilenweise die Produktdaten ausgegeben werden. Auch in der Vergleichsdarstellung soll es möglich sein, das Produkt in den Warenkorb zu legen. Zusätzlich soll es auch möglich sein, Produkte wieder vom Vergleich zu entfernen.
• Produktsuche: Der Anwender soll über eine Suchfunktion die Möglichkeit haben, die Übersichtsdarstellung auf Produkte, die den Suchkriterien entsprechen, einzuschränken. Diese Einschränkung soll für die in der Produktübersicht dargestellten Attribute möglich sein. Die Ergebnisausgabe hat analog zur Übersichtsdarstellung zu erfolgen.

Für die Aushandlung der Kauftransaktion werden die folgenden Basisfunktionen umgesetzt:

• Warenkorb: Im Warenkorb sollen alle für den Kauf markierten Produkte dargestellt werden. Die Darstellung soll zeilenweise in einer Tabelle erfolgen. Hier soll es möglich sein, die Produkte wieder aus dem Warenkorb zu entfernen, die Bestellmenge zu ändern und die Bestellung auszulösen. Zusätzlich soll pro Position der kumulierte Preis angezeigt werden. Die Gesamtsumme für den Einkauf soll ebenfalls im Warenkorb angezeigt werden.
• Bestellauslösung: Der Kunde soll aus jeder Darstellung die Bestellung auslösen können. Hierbei soll erst die Eingabe der Adressdaten, anschließend die Eingabe der Bankverbindung und nach einer abschließenden Bestätigung durch den Kunden die Übermittlung der Bestelldaten (Adresse, Bankdaten, Warenkorb) an das ERP-System erfolgen.
• Adresseingabe: In einer übersichtlichen Maske soll der Kunde seine Adress- und Kontaktdaten eingeben können. Die Eingabe soll vorerst auf eine Adresse beschränkt und nicht in unterschiedliche Liefer- und Rechnungsadressen aufgeteilt werden.
• Bankverbindungseingabe: Der Kunde soll für die Bezahlung per Lastschrift seine Bankdaten eingeben können. Auf eine sichere Übertragung kann im Rahmen des Prototyps vorerst verzichtet werden.
• Bestellbestätigung: Der Kunde soll nach Eingabe seiner Daten die Auslösung der Bestellung bestätigen und die AGB's des Onlineshops akzeptieren können.
• Bestellübertragung: Im Anschluss an die Bestellbestätigung sollen die Daten für die Bestellung an das ERP-System übertragen werden. In dem ERP-System soll anschließend der entsprechende Auftrag angelegt werden. Die erfolgreiche Auftragsanlage soll dem Kunden danach im Onlineshop bestätigt werden.

Für den Prototyp werden im ERP-System vorerst nur Produktdaten für Notebooks und Zubehör gepflegt. In dem bestehenden SAP-System müssen dafür neue Tabellen für die Produktattribute angelegt werden. Dadurch können zusätzliche Anschaffungskosten für ein Katalogsystem vermieden werden. Die Architektur des Shops soll aber das Anbinden von weiteren Systemen ohne großen Aufwand ermöglichen. Die Daten der Bestellungen sollen vorerst nur in das SAP-System übertragen und dort in einer Tabelle gespeichert werden. Das Anlegen der Aufträge kann mit diesen Daten vor der Produktivsetzung implementiert werden.

3.1.2 Weitere erforderliche Funktionalität für den Produktiveinsatz

Im Folgenden werden kurz die Funktionen erläutert, die für einen Produktiveinsatz des Onlineshops noch erstellt werden sollten:

• Bestätigungsmail: Aus rechtlichen Gründen (vgl. § 312e BGB) muss kurz nach Eingang der Bestellung eine Bestätigung an den Kunden versendet werden. Dies kann sowohl aus dem Front- als auch aus dem Back-End heraus getan werden.
• Preisauszeichnung: Zumindest auf der Bestätigungsseite vor der Bestellauslösung sollte angegeben werden, dass die Preise die gesetzliche Mehrwertsteuer beinhalten und ob, bzw. welche Versandkosten anfallen. Dadurch werden die Anforderungen des § 1(2) PAngV erfüllt.
• Kundenkonto: Bei jeder Bestellung werden die Kundendaten an das ERP-System übertragen. Dort oder in einem anderen System können die Kundendaten verwaltet werden. Durch die Implementierung eines Kundenkontos in dem Shopsystem, können sich Kunden bei der Bestellung anmelden und dadurch bereits bei früheren Bestellungen eingegebene Daten nutzen, ohne dass diese neu erfasst werden müssen.
• Adressverwaltung: In dem Prototyp kann nur eine Adresse eingegeben werden. Bei vielen Bestellungen weichen allerdings die Liefer- und die Rechnungsadresse voneinander ab. Aus diesem Grund sollte es für Kunden die Möglichkeit geben, bei Bedarf voneinander abweichende Adressen einzugeben.
• Zahlverfahrenauswahl: Die Bezahlung per Vorkasse, Nachnahme, Kreditkarte, etc. ist im E-Commerce durchaus üblich. Über eine Implementierung von weiteren Zahlverfahren sollte vor der Produktivsetzung des Shopsystems nachgedacht werden, um verschiedene Kundenwünsche zu berücksichtigen.
• Kontaktaufnahme: Für den Fall, dass Fragen auf Kundenseite auftreten, sollte ein Kontaktformular in dem Onlineshop implementiert werden.
• Sichere Datenübertragung: Gerade die erforderlichen Daten zur Bezahlung, aber auch die Adressdaten der Kunden sollten sicher im Internet übertragen werden. Dafür sollte die Datenübertragung SSL-verschlüsselt erfolgen.
• Bestandsanzeige: Damit der Kunde schon vor dem Absenden der Bestellung weiß, ob der gewünschte Artikel zeitnah versendet wird, sollte eine Bestandsprüfung implementiert werden. Es reicht dabei aus, anzuzeigen, ob der Artikel verfügbar ist, oder ob er erst bestellt werden muss. Eine genaue Angabe der verfügbaren Menge ist nicht erforderlich.

3.2 Produkteinsatz

Das zu entwickelnde Shopsystem soll als Prototyp genutzt werden. Ausgehend von diesem Prototyp kann später ein voll funktionsfähiges System für den Internetvertrieb von ausgewählten Produkten entwickelt werden. Die Funktionen des Prototyps können dabei als Grundlage für das einsetzbare Shopsystem genutzt werden.

Obwohl die zu entwickelnde Software von einem Unternehmen betrieben wird, wird sie hauptsächlich von privaten Endkunden genutzt. Diese können den Onlineshop im Internet aufrufen und über die zu entwickelnden Eingabemasken Einkäufe tätigen. Der Einsatz findet also primär im B2C-Bereich statt. Da die Anforderungen an Shopsysteme in anderen Bereichen (siehe Abschnitt "Weitere Beziehungen und ihre Eignung für einen Adobe Flex Onlineshop") von den umzusetzenden Funktionen abweichen, ist ein Einsatz des Shopsystems außerhalb des B2C-Bereichs nur bedingt empfehlenswert.

3.3 Ablauf des Einkaufvorgangs

Nach dem Aufruf des Onlineshops hat der Anwender die Möglichkeit, sich die Produkte der verschiedenen Kategorien (Notebook, Desktop-PC, Monitor, Drucker, Zubehör) anzusehen. Die Darstellung der Produkte ist dabei identisch. In jeder Produktkategorie ist eine Filterung der gewählten Produkte möglich. Neben dem Hinzufügen zum Einkaufswagen hat der Kunde die Möglichkeit, verschiedene Produkte miteinander zu vergleichen oder eine Detailansicht für einzelne Produkte aufzurufen. In der Detailansicht können Produkte ebenso zum Einkaufswagen hinzugefügt werden, wie in der Vergleichsansicht. Über einen Klick auf eine der Kategorien kann der Kunde jederzeit wieder die Ansicht, in der er sich gerade befindet, verlassen. Er bekommt dann die Daten der ausgewählten Kategorie angezeigt. Sowohl aus der Kategorieansicht als auch aus der Vergleichsansicht kann der Anwender in die Einkaufswagenansicht wechseln und dort die Bestellmenge einzelner Produkte ändern oder Produkte komplett aus dem Einkaufswagen entfernen. Der Einkaufswagen kann wieder über die Wahl einer Kategorie verlassen werden. Aus jeder möglichen Ansicht kann der Anwender den Bestellvorgang auslösen, wenn mindestens ein Produkt im Einkaufswagen ist. Nach der Bestellauslösung erscheinen der Reihe nach erst eine Eingabemaske für die Adressdaten, dann eine Eingabemaske für die Bankdaten und zum Abschluss eine Zusammenfassung mit allen relevanten Daten für die Bestellung. Auf der Zusammenfassungsseite können erneut alle Daten zur Bearbeitung ausgewählt werden. Der Abschluss der Bestellung und somit das Übertragen der Daten ins Back-End-System ist erst möglich, nachdem der Anwender die AGB's akzeptiert hat. Der gesamte Einkaufsvorgang wird in Abbildung "Use-Case des Einkaufvorgangs" als UML-Diagramm dargestellt.

3.4 Systemarchitektur

Das Shopsystem soll aus zwei Komponenten bestehen, dem Front-End und dem Back-End. Das Front-End ist die eigentliche Shopapplikation, die von den Kunden aufgerufen und bedient wird. Das Back-End ist das ERP-System. Dort werden die Produktdaten verwaltet und die Bestellungen angelegt. Als Back-End-System steht ein SAP ECC 6.0 zur Verfügung. Das Front-End soll auf einem beliebigen Webserver gehostet werden können.

3.5 Qualitätsanforderungen

Auch wenn es sich bei der zu erstellenden Software um einen Prototypen handelt, sollen bestimmte Qualitätskriterien erfüllt werden. Diese werden nachfolgend erläutert.

3.5.1 Erweiterbarkeit

Die Software soll ohne großen Aufwand um neue Funktionen erweitert werden können. Hauptaugenmerk soll dabei auf eine problemlose Integration, der für einen Produktiveinsatz erforderlichen Komponenten (siehe Abschnitt "Weitere erforderliche Funktionalität für den Produktiveinsatz"), gelegt werden. Es muss aber auch möglich sein, den Produktkatalog ohne großen Aufwand zu erweitern.

Die Anbindung von anderen Back-End-Systemen, bspw. für die Verwaltung der Kundendaten, muss ebenso möglich sein, wie ein Wechsel des ERP-Systems.

3.5.2 Wartbarkeit

Die Software soll so umgesetzt werden, dass Fehlerkorrekturen und kleinere Modifikationen durchgeführt werden können, ohne dass das gesamte Shopsystem geändert werden muss. Es ist erforderlich, dass Fehler nur in dem System (Front-End, Back-End) behoben werden müssen, wo sie entstehen. Die Auswirkungen auf andere Bereiche sollen minimal gehalten werden.

3.5.3 Benutzbarkeit

Auch wenn Probleme in Teilbereichen des Shopsystems auftreten (bspw. kurzfristige Nichtverfügbarkeit des Produktkatalogs) soll das Shopsystem für den Anwender weiterhin benutzbar sein. Dafür sollen bei Fehlern entsprechende Meldungen an den Anwender ausgegeben werden. Ein Absturz der Anwendung soll vermieden werden.

3.6 Benutzerschnittstellen

Der Onlineshop soll für Kunden über das Internet erreichbar sein. Wie die Kommunikation zwischen dem Anwender und dem Shopsystem stattfindet, wird in den folgenden Kapiteln beschrieben.

3.6.1 Kommunikationsaufbau

Mögliche Kunden können den Onlineshop jederzeit über das Internet aufrufen. Nach Eingabe der URL des Onlineshops wird überprüft, ob der für das Ausführen von Adobe Flex Anwendungen erforderliche Flashplayer 9 (FP9) auf dem PC des Anwenders installiert ist. Wenn dies nicht der Fall ist, wird dem Anwender ein Link auf den FP9 mit der entsprechenden Meldung präsentiert, dass der Onlineshop nach Installation des FP9 aufgerufen werden kann. Wenn der FP9 bereits installiert ist, wird die Anwendung auf den PC des Anwenders übertragen und dort ausgeführt. Der Abruf der Produktdaten erfolgt direkt im Anschluss an das Laden der Applikation. Dadurch kann die Anwendung danach ohne weitere Verzögerungen und Wartezeiten ausgeführt werden. Eingegebene Daten (Warenkorb, Adress- und Bezahldaten) werden nach Bestätigung der Daten vom PC des Anwenders an das Back-End-System übertragen.

3.6.2 Eingabemasken

Für die Bestellung notwendige Daten werden in ergonomisch gestalteten, für den Anwender intuitiv bedienbaren Formularen eingegeben. Die Eingaben werden vor dem Senden an das Back-End-System überprüft, evtl. aufgetretene Fehleingaben direkt markiert und der Anwender zur Korrektur aufgefordert. Dadurch wird die Datenlast auf das erforderliches Minimum reduziert. Erforderlich sind Eingabemasken für die Adress- und die Bezahldaten. Im Warenkorb können in dem Bestellmengenfeld für jede Position Eingaben erfolgen. Das Markieren von Artikeln für den Produktvergleich erfolgt über Auswahlboxen. Hierbei kann keine Fehleingabe erfolgen.

4 Technisches Konzept

Im folgenden Kapitel werden die Vorgaben aus dem vorherigen Kapitel konkretisiert und nähere Details zur Umsetzung erläutert. Der Aufbau der Datenbanktabellen und der Schnittstellen wird ebenso beschrieben, wie der Aufbau der verschiedenen Applikationsteile.

4.1 Systembeschreibung

Die Vorgaben zur Systemarchitektur aus dem Fachkonzept (Abschnitt "Systemarchitektur") werden in diesem Kapitel präzisiert. Ebenso werden die Programmiersprachen für die Entwicklung der Applikationsteile definiert und die u.a. aus der Wahl der Programmiersprachen resultierenden Anforderungen an den Anwender-PC beschrieben.

4.1.1 Systemumgebung

Für die Ausführung des zu entwickelnden Prototypen wird das Front-End vorerst auf einem lokal auf dem Entwicklungs-PC installierten Apache Webserver gehostet. Dadurch kann die Anwendung von jedem PC mit Zugriff zu diesem Webserver gestartet werden. Die Produktdaten werden aus dem Back-End-System gelesen. Das vorhandene SAP ECC 6.0 bietet durch den zum Betrieb notwendigen SAP NetWeaver Application Server die Möglichkeit, Webservices zur Kommunikation mit anderen Systemen zu implementieren. Die Datenbankanbindung wird von dem SAP-System bereitgestellt und ist somit nicht Bestandteil dieser Arbeit. Die Kommunikation zwischen dem Anwender-PC und dem Shopsystem wird in Abbildung "Kommunikation zwischen den Systemen" dargestellt.

4.1.2 Entwicklungsumgebung

Entwickelt wird das Shopsystem auf einen IBM-kompatiblen PC mit dem Betriebssystem Windows XP. Für die Erstellung der erforderlichen Programmteile im SAP-Umfeld ist auf dem PC ein SAP-GUI der Version 7.10 installiert. Das Front-End für den Anwender wird in dem installierten Adobe Flex Builder 3 erstellt. Ausgeführt wird dieser Teil des Shopsystems auf einem lokal installierten Apache Webserver.

4.1.3 Programmiersprache

Zur Erstellung der Applikationsteile werden verschiedene Programmiersprachen verwendet. Die Applikationslogik im Back-End wird in ABAP erstellt. Das Front-End wird in den beiden von dem Adobe Flex-Framework zur Verfügung gestellten Sprachen MXML und AS entwickelt. MXML dient dabei hauptsächlich der Erstellung der GUI für den Anwender. In AS wird die im Front-End bereitgestellte Applikationslogik entwickelt, die auf den PC des Anwenders ausgelagert werden kann. Durch die Wahl von Flex wird ein Programmierframework verwendet, welches sowohl ansprechende visuelle Effekte bietet als auch weit verbreitet und auf vielen Betriebssystemen ausführbar ist. Dadurch kann der Shop von vielen Nutzern aufgerufen werden und erfüllt deren Bedürfnisse besser als klassische Webshops.

4.1.4 Anforderungen an den PC des Anwenders

Um den Onlineshop uneingeschränkt nutzen zu können, benötigt der Anwender einen PC mit Internetzugriff. Über das Internet muss er sowohl das Front-End des Shopsystems erreichen können als auch eine Verbindung zu den Webservices herstellen können. Zur Ausführung der Shopapplikation muss der Flashplayer 9 auf dem Anwender-PC installiert sein. Damit die Anwendung komfortabel bedient werden kann, ist eine Auflösung von mindestens 925px x 690px empfohlen. Eingaben können über Tastatur und Maus erfolgen.

4.2 Datenbankaufbau

Der Zugriff auf die Datenbank erfolgt durch das SAP-System. Die Einstellungen, die zum Aufbau der Datenbankverbindung notwendig sind, müssen nicht geändert werden. Die im SAP-System zu entwickelnden Komponenten können mit Hilfe von Open SQL sowohl lesend als auch schreibend auf die Datenbank zugreifen. Die Produktdaten werden teilweise aus Standardtabellen, teilweise aus neu erstellten Kundentabellen gelesen. Die Daten der Bestellung werden nur in einer neuen Kundentabelle gespeichert. Nachfolgend werden die einzelnen Tabellen und die daraus benötigten Felder kurz erläutert:

• MARA: Aus dieser im SAP-Standard existierenden Tabelle werden die Materialnummer (MATNR) und das Gewicht (NTGEW) der Produkte gelesen.
• MBEW: Diese SAP-Standard Tabelle liefert in dem Tabellenfeld STPRS den Standardpreis der Produkte. Dieser Preis könnte auch bei der Ermittlung der Produkte über die SAP-Preisfindung ermittelt werden. Die Verknüpfung mit der Tabelle MARA erfolgt über das Feld MATNR.
• ZCT_PROD_NB_DET: In dieser Datenbanktabelle werden alle weiteren relevanten Attribute der zu vertreibenden Notebooks gespeichert. Der genaue Aufbau, inklusive Bedeutung der Tabellenfelder, wird in der Tabelle "Aufbau der Tabelle ZCT_PROD_NB_DET" dargestellt. Verknüpft wird diese Tabelle mit den Tabellen MARA und MBEW über die Materialnummer MATNR.
• ZCT_PROD_ZUB_DET: Daten für zu verkaufendes PC-Zubehör werden in dieser Kundentabelle gespeichert. Der Aufbau dieser Datenbanktabelle wird in der Tabelle "Aufbau der Tabelle ZCT_PROD_ZUB_DET" erläutert. Auch die Tabelle ZCT_PROD_ZUB_DET wird über die Materialnummer mit den Tabellen MARA und MBEW verknüpft.
• ZCT_ORDER_TEST: Diese Datenbanktabelle dient vorerst zur Speicherung der Daten von ausgelösten Bestellungen. Wie in Tabelle "Aufbau der Tabelle ZCT_ORDER_TEST" zu erkennen ist, entspricht diese Datenbanktabelle keineswegs der empfohlenen 3. Normalform und sollte für einen Produktivbetrieb des Onlineshops optimiert bzw. durch Normalisierung in entsprechende Tabellen für Adress-, Bank- und Produktdaten aufgeteilt werden. Das separate Speichern dieser Daten ist zwar nicht notwendig wenn die Bestellung direkt bei der Übertragung der Daten erzeugt wird, erleichtert aber bei möglichen Problemen das nachträgliche Erzeugen der Bestellung.

Um das Auslesen der Produktdaten zu erleichtern, werden die Datenbankviews ZCT_PROD_NB_V für Notebookdaten und ZCT_PROD_ZUB_V für Zubehör angelegt. In diesen Views wird die entsprechende Tabelle der Produktdaten mit den Tabellen MARA und MBEW verknüpft. Nur die im Onlineshop benötigten Felder (siehe Abschnitt "Definition der Schnittstellen" werden von den Views zurückgegeben.

Aufbau der Tabelle ZCT_PROD_NB_DET

Feld	Bedeutung
MANDT	Mandant des SAP-Systems
MATNR	Materialnummer
NAME	Produktname
HERSTELLER	Herstellername
PROZESSOR	Art des Prozessors
TAKT	Takt des Prozessors
HAUPTSPEICHER	Arbeitsspeicher
HDD	Festplattenkapazität
AKKU	Akkulaufzeit und -Art
DISPLAY	Displaygröße und -Auflösung
OPTISCHES_LW	Integrierte optische Laufwerke
GRAPHICS	Grafikkarte
SOUND	Soundkarte
LAN	Netzwerkkarte
WLAN	W-Lan - Standard
OS	Betriebssystem
GARANTIE	Garantieart und -dauer
SCHNITTSTELLEN	Weitere Schnittstellen
BESCHREIBUNG	Kurzbeschreibung des Notebooks
AKTIV	Kennzeichen ob das Notebook im Onlineshop angeboten wird

Aufbau der Tabelle ZCT_PROD_ZUB_DET

Feld	Bedeutung
MANDT	Mandant des SAP-Systems
MATNR	Materialnummer
NAME	Produktname
HERSTELLER	Herstellername
BESCHREIBUNG	Kurzbeschreibung des Zubehörs
AKTIV	Kennzeichen ob das Zubehör im Onlineshop angeboten wird

Aufbau der Tabelle Aufbau der Tabelle ZCT_ORDER_TEST

Feld	Bedeutung
MANDT	Mandant des SAP-Systems
NUM	Hochzuzählende Nummer als Primärschlüssel
KTO	Rechnungsdaten: Kontonummer
BLZ	Rechnungsdaten: Bankleitzahl
BANK	Rechnungsdaten: Kreditinstitut
INH	Rechnungsdaten: Kontoinhaber
MATNR	Warenkorbdaten: Materialnummer
MENGE	Warenkorbdaten: Bestellmenge
ANREDE	Adressdaten: Anrede
NAME	Adressdaten: Vor- und Nachname
STRASSE	Adressdaten: Straße und Hausnummer
PLZ	Adressdaten: Postleitzahl
ORT	Adressdaten: Ort
LAND	Adressdaten: maximal 3-stelliger Länderschlüssel

4.3 Definition der Schnittstellen

In dem zu entwickelnden Shopsystem werden verschiedene Schnittstellen für die Kommunikation zwischen Front- und Back-End benötigt. Diese werden alle im Back-End realisiert und vom Front-End aufgerufen. In den folgenden Abschnitten werden die verschiedenen Schnittstellen detailliert beschrieben.

4.3.1 Produktdatenschnittstellen

Die Produktdaten werden im XML-Format aus dem Back-End an das Front-End übertragen. Die übertragenen XML-Daten werden dynamisch durch BSP-Applikationen im SAP-System erstellt. Der Aufruf der Schnittstellen erfolgt als HttpService ohne Parameterübergabe aus dem Front-End heraus. Die Produktdaten für Zubehör werden in dem in Abbildung "Format zur Übertragung der Zubehördaten mit den zugehörigen Tabellenfeldern" dargestellten Format vom Back-End zur Verfügung gestellt. Der Aufbau der XML-Datei für Notebooks wird in Abbildung "Format zur Übertragung der Notebookdaten mit den zugehörigen Tabellenfeldern" veranschaulicht.

4.3.2 Bestellungsdatenschnittstelle

Die Schnittstelle zur Übertragung der Bestellungsdaten wird im Gegensatz zu den anderen Schnittstellen als echter Webservice definiert. Anders als die Daten der Produkte, werden die Bestellungsdaten vom Front-End in das Back-End übertragen. Der Webservice erhält beim Aufruf die Kundendaten und die Bankdaten als flache Strukturen und die Materialnummer mit den dazugehörigen Bestellmengen als Tabelle und gibt zur Verifikation der erfolgreichen Übertragung und Verarbeitung der Daten einen Ganzzahlwert zurück. Ein Überblick über den Aufbau der Schnittstelle kann dem Auszug der WSDL in Abbildung "WSDL des Webservices zur Übertragung der Bestellungsdaten" entnommen werden. Im SAP-System werden die ankommenden Daten an den zu erstellenden Funktionsbaustein Z_CT_CREATE_ORDER übergeben. Dieser speichert die Daten in der Datenbanktabelle ZCT_ORDER_TEST. In dem Funktionsbaustein kann später die Funktionalität zum Erstellen des SAP-Auftrags implementiert werden.

4.4 Entwicklungen im ERP-System

Neben den beschriebenen Tabellen, den Datenbankviews, dem Webservice, den BSP-Applikationen für die Produktdaten und dem Funktionsbaustein, der die Daten der Schnittstelle für die Bestellungsdaten verarbeitet, wird nur noch eine Klasse im SAP-System entwickelt. Diese Klasse dient zur Speicherung aller Produktdaten in internen Tabellen, die bei der Initialisierung der BSP-Applikation gelesen werden. Mit Hilfe dieser internen Tabellen werden die XML-Dateien gefüllt, die zur Übertragung der Produktdaten an das Front-End benötigt werden. Weitere Entwicklungen im SAP-System sind für den Prototypen nicht erforderlich. Allerdings muss auf jedem Back-End-Server eine XML-Datei gespeichert werden, die bei der Initialisierung des Front-Ends von diesem gelesen werden muss. Diese XML-Datei muss alle Domains enthalten, die die Webservices des Back-Ends aufrufen dürfen. Ohne diese XML-Datei ist ein Zugriff auf die Webservices aus dem Front-End heraus nicht möglich.

4.5 Aufbau des Front-Ends

Die Entwicklung des Front-Ends findet auf Grundlage der MVC (Modell-View-Controller)-Architektur statt. Die zu entwickelnden Fachklassen dienen der Datenhaltung und repräsentieren das Modell. Der View wird mit Hilfe der Darstellungskomponenten realisiert. Der Controller übernimmt die Steuerung der Ablauflogik. Diese drei Komponenten werden in den folgenden Abschnitten näher beschrieben.

4.5.1 Fachklassen

Für die Verwaltung der Daten im Front-End werden verschiedene Fachklassen, auch ValueObjects genannt, benötigt. Der Aufbau dieser Fachklassen wird in Abbildung "Fachklassen" dargestellt. Diese Abbildung verzichtet auf die zu implementierenden Methoden.

Die Beziehungen zwischen den einzelnen Klassen verdeutlicht das Klassendiagramm in Abbildung "Klassendiagramm". Die Verwaltung der Fachklassen wird von der Containerklasse DataManager übernommen. In dieser Klasse werden auch die erforderlichen Daten aus dem SAP-System gelesen und im Fall einer Bestellauslösung ins SAP-System übertragen. Die folgenden Fachklassen werden für die Entwicklung des Prototyps erstellt:

• Accessories: Das Zubehör enthält lediglich Attribute, die in der Product-Klasse schon definiert wurden. Es werden auch keine weiteren Methoden definiert. Lediglich eine bereits in der Product-Klasse bestehende Methode wird neu definiert. Diese Methode liefert die Informationen, die in der Vergleichsansicht dargestellt werden.
• Address: Die Klasse Address dient zur Verwaltung der Adressdaten, die vom Kunden im Verlauf des Bestellvorgangs eingegeben werden müssen. Diese Daten werden beim Abschluss der Bestellung ins SAP übertragen. Nur die Daten für das Land der Adresse müssen vor der Übertragung konvertiert werden, da im SAP die internationale Länderabkürzung erwartet wird.
• Billing: In dieser Klasse werden die eingegebenen Bezahlinformationen gespeichert. Da im Prototyp nur eine Bezahlung per Bankeinzug vorgesehen ist, enthält die Klasse Billing nur Attribute für die Kontonummer, die Bankleitzahl, den Namen des Kreditinstituts und den Namen des Kontoinhabers. Diese Daten können ohne weitere Konvertierungen ins SAP übertragen werden.
• Category: Das ValueObject Category wird zur Verwaltung der Kategoriedaten benötigt. Neben einer eindeutigen Identifikationsnummer der Bezeichnung der Kategorie und dem Namen der darzustellenden Grafik, werden in diesem ValueObject alle Hersteller, der höchste und der niedrigste Preis von Produkten dieser Kategorie gespeichert. Diese Daten werden in der Filteranzeige zur Auswahl angeboten.
• Filter: Für jede Kategorie wird ein Objekt der Filterklasse angelegt. In diesem Objekt werden die vom Anwender eingegebenen Kriterien zur Filterung der Produktauswahl verwaltet. Bevor Produkte in der Produktübersicht angezeigt werden, wird für jedes Produkt einer Kategorie in einer Methode der Klasse Filter überprüft, ob zu der ausgewählten Kategorie ein Produktfilter aktiv ist und ob das jeweilige Produkt zu den Filterkriterien passt.
• Notebook: In der Notebook-Klasse werden die einzelnen Daten für Notebooks verwaltet. Diese Klasse ist eine Unterklasse der Product-Klasse. Sie erbt alle Attribute und Methoden von der Product-Klasse. Die Methoden der Oberklasse für die Darstellung in der Vergleichs- und in der Detailansicht werden in der Notebook-Klasse überschrieben.
• Order: Die Order-Klasse wird zur Verwaltung einer kompletten Bestellung benötigt. Sie enthält eine Referenz auf die vom Kunden eingegebenen Adressdaten, eine Referenz auf die eingegebenen Kontoinformationen für den Bezahlvorgang und den aktuellen Warenkorb. Um eine redundante Datenhaltung zu vermeiden, wird eine Referenz auf den gesamten Warenkorb in der Order-Klasse gespeichert, obwohl für den Bestellvorgang nur die Produktnummern und die zugehörigen Bestellmengen benötigt werden. Zusätzlich wird in der Order-Klasse noch der aktuelle Status einer Bestellung gespeichert, der es ermöglicht, immer wieder in den gerade benötigten View (siehe Abschnitt "Darstellungskomponenten") zurückzukehren.
• Product: Die Oberklasse für alle im Onlineshop vertriebenen Produkte ist die Product-Klasse. Sie enthält Attribute für die Grunddaten, die jedes Produkt besitzt (Artikelnummer, Hersteller, Name, Beschreibung, Gewicht, Preis). Zusätzlich enthält sie noch die Information, ob ein Produkt für die Vergleichsansicht ausgewählt ist. In der Product-Klasse werden verschiedene Methoden zur Ausgabe der Produktdetails für die Vergleichs- und die Detailansicht implementiert. In dem zu entwickelnden Prototypen erben sowohl die Notebook- als auch die Zubehör-Klasse alle Attribute und Methoden der Product-Klasse. Die Produkte werden einmalig mit ihrem originären Klassentypen instanziiert, anschließend aber nur noch in Product-Referenzen verwaltet. Dadurch stehen die Attribute und Methoden des eigentlichen Objektes zur Verfügung, die einzelnen View-Komponenten müssen aber nicht für die verschiedenen Produktkategorien unterschiedlich implementiert werden.
• ShoppingCart: Das ValueObject ShoppingCart verwaltet alle Produkte, die dem Einkaufswagen hinzugefügt wurden. Zusätzlich enthält dieses ValueObject als Attribut die Gesamtsumme aller im Warenkorb gespeicherten Produkte. Wenn ein Produkt in den Warenkorb gelegt wird, wird in der Klasse ShoppingCart überprüft, ob sich das Produkt bereits im Warenkorb befindet. Ist dies der Fall, wird dieses Produkt nicht erneut in den Warenkorb gelegt, sondern die Menge des Produkts inkrementiert.
• ShoppingCartProduct: Für jedes in den Einkaufswagen gelegte Produkt wird ein Objekt der ShoppingCartProduct-Klasse instanziiert. Dieses enthält eine Referenz auf das in den Einkaufswagen gelegte Produkt, die Anzahl, wie oft das Produkt im Warenkorb ist und die Summe dieser Warenkorbposition.

4.5.2 Darstellungskomponenten

Neben der im Abschnitt "Steuerung der Ablauflogik" beschriebenen Controllerklasse sind auch die folgenden Klassen bzw. Komponenten für die Darstellung verantwortlich. Der Aufbau von einigen ausgewählten Komponenten wird in Abbildung "Aufbau des Layouts" grafisch veranschaulicht.

• AddressData: Diese Darstellungskomponente ist für die Erfassung der Adressdaten erforderlich. Die vom Anwender eingegebenen Daten werden mit verschiedenen Kriterien auf ihre Plausibilität hin überprüft, bevor der Anwender den nächsten Bestellschritt (die Eingabe der Bankdaten) ausführen kann.
• AGBs: Beim finalen Absenden der Bestellung muss der Anwender die AGB's des Onlineshops akzeptieren. Diese können von der AGBs-Klasse als PopUp dargestellt werden.
• BillingData: Die Erfassung der Bankdaten erfolgt in der BillingData-Klasse. Analog zur AddressData-Klasse werden die eingegebenen Daten auch hier anhand von verschieden Plausibilitätskriterien überprüft, bevor der letzte Bestellschritt (das Bestätigen der Bestellung) durchgeführt werden kann.
• Cart: Die Cart-Komponente wird zur Darstellung des Einkaufswagens benötigt. Sie wird sowohl bei der separaten Darstellung des Einkaufswagens mit der Möglichkeit zur Bearbeitung der Warenkorbpositionen als auch in der Komponente OrderSummary verwendet.
• CategoryView: Die CategoryView wird im oberen Bereich auf jeder Seite angezeigt. Sie dient zur Darstellung aller verfügbaren Produktkategorien. Diese sind in der CategoryView auswählbar, wodurch die Hauptnavigation im Onlineshop realisiert wird.
• CompareView: Die Darstellung der zum Vergleich ausgewählten Produkte findet in der CompareView-Klasse statt. Diese Produkte werden in einer horizontalen Liste dargestellt und können über verschiedene Buttons in den Einkaufswagen gelegt oder vom Vergleich entfernt werden.
• ConfView: Sowohl der Erfolg als auch ein Fehlschlag der Übertragung der Bestellungsdaten wird in dieser Komponente an den Anwender zurückgemeldet.
• DetailView: Diese Komponente dient der Darstellung der Produktdetails. Nur hieraus ist es für den Anwender möglich, ein Datenblatt des angezeigten Produktes herunterzuladen. Auch aus dieser Komponente können Produkte in den Einkaufswagen gelegt werden.
• FilterBox: In der FilterBox hat der Anwender die Möglichkeit, die in der ProductList darzustellenden Produkte über bestimmte Attribute zu filtern.
• HomePage: Diese Komponente ist die Startseite der Anwendung. Wenn ein Kunde den Onlineshop aufruft, wird automatisch die HomePage dargestellt.
• OrderSummary: Die OrderSummary wird als letzte Komponente vor dem Abschluss des Bestellvorgangs dargestellt. Alle relevanten Daten (Adressdaten, Bezahldaten und der Warenkorb) werden in der OrderSummary angezeigt. Auf dieser Komponente muss der Kunde die AGB's akzeptieren, bevor der Bestellvorgang abgeschlossen werden kann.
• OrderView: Die OrderView ist keine reine Darstellungskomponente. Sie ist die Controllerklasse für die Komponenten AddressData, BillingData und OrderSummary. Die Darstellung dieser Komponenten wird von der OrderView-Klasse gesteuert.
• ProductList: In der Komponente ProductList werden alle Produkte der ausgewählten Kategorie, die den Filterkriterien entsprechen, in einer Matrix dargestellt. Diese Produkte können in den Einkaufswagen gelegt, zum Vergleich markiert und in der Detailansicht aus der ProductList heraus aufgerufen werden.

4.5.3 Steuerung der Ablauflogik

Die Steuerung der Ablauflogik wird von der Controllerklasse Onlineshop übernommen. Sie enthält die notwendigen Referenzen auf ein Objekt der Containerklasse DataManager und auf die einzelnen Darstellungskomponenten. Neben der Ablauflogik wird von der Onlineshop-Klasse auch das Layout verwaltet. In dieser Klasse existieren Methoden, die auf die verschiedenen Anwenderaktionen reagieren. Innerhalb dieser Methoden werden die entsprechenden Operationen der Containerklasse ausgeführt und, falls notwendig, eine neue Darstellungskomponente aufgerufen. Um die Applikation möglichst flexibel zu halten und einzelne Komponenten bei Bedarf austauschen zu können, werden bei Anwenderaktionen in den Darstellungskomponenten Events ausgelöst. Diese Events werden von den entsprechenden Eventhandlern in der Onlineshop-Klasse verarbeitet. Neu zu integrierende Komponenten können dadurch ohne große Kenntnisse der Controllerklasse entwickelt werden und die Bearbeitung von verschiedenen Anwenderaktionen über neue Events an die Controllerklasse delegieren.

4.5.4 Kommunikation zwischen den Front-End-Komponenten

Im folgenden Abschnitt wird die Kommunikation zwischen den unterschiedlichen Klassen des Front-Ends bei verschiedenen Anwenderaktionen beschrieben. Da die Kommunikation zwischen den Front-End-Komponenten bei den meisten Anwenderaktionen ähnlich abläuft, werden nachfolgend nur wenige Anwenderaktionen exemplarisch erläutert.

4.5.4.1 Produkte zum Warenkorb hinzufügen

Das Hinzufügen eines Produktes zum Einkaufswagen kann aus verschiedenen Komponenten erfolgen. In jeder dieser Komponenten wird ein Event ausgelöst, welches das ausgewählte Produkt als Referenz an die Controllerklasse Onlineshop überträgt. In der Klasse Onlineshop wird aus dem Produkt ein Objekt des Typen ShoppingCartProduct erzeugt. Dieses beinhaltet neben der Produktreferenz auch noch die Menge, die bei der Initialisierung "1" ist und den Gesamtpreis, der sich durch die Multiplikation von Produktpreis und Menge berechnen lässt. Dieses ShoppingCartProduct wird von der Klasse Onlineshop an die Klasse ShoppingCart übertragen. Dazu wird die Methode addProduct der ShoppingCart-Klasse aufgerufen. Innerhalb dieser Methoden werden verschiedene weitere Methoden aufgerufen, um zu überprüfen, ob sich dieses Produkt bereits im Warenkorb befindet. Wenn dies der Fall ist, wird von dem bereits im Warenkorb existierenden ShoppingCartProduct die Menge um "1" erhöht. Befindet sich das Produkt noch nicht im Warenkorb, wird die Referenz auf das ShoppingCartProduct im Warenkorb gespeichert. In beiden Fällen wird anschließend die Gesamtsumme, die in dem ShoppingCart-Objekt gespeichert wird, neu berechnet. Dafür wird die Summe des Gesamtpreises von jedem ShoppingCartProduct gebildet. Abbildung "Sequenzdiagramm: Produkt zum Warenkorb hinzufügen" verdeutlicht den gesamten Ablauf grafisch.

4.5.4.2 Anzeigen der Vergleichsansicht

Das Anzeigen der Vergleichsansicht wird ebenfalls durch ein Event ausgelöst. Auch dieses Event wird in der Onlineshop-Klasse verarbeitet. Allerdings wird keine Product-Referenz in dem Event übertragen. In dem Onlineshop-Objekt wird beim Eintreffen des Events eine Methode zum Anzeigen der CompareView aufgerufen. In dieser Methode werden zuerst alle Produkte aus dem DataManager-Objekt ermittelt, die zu der ausgewählten Kategorie gehören und für die Vergleichsansicht markiert wurden. Hierfür wird in dem DataManager-Objekt eine Schleife über alle zu der Kategorie passenden Produkte ausgeführt. In dieser Schleife wird das Attribut der Produkte geprüft, das anzeigt, ob ein Produkt für die die Vergleichsansicht markiert ist. Nur markierte Produkte werden an das Onlineshop-Objekt zurückgegeben. Anschließend werden in dem Onlineshop-Objekt diese Objekte an die CompareView übergeben und die Darstellung der CompareView veranlasst. Der gesamte Vorgang wird in Abbildung "Sequenzdiagramm: Vergleichsansicht aufrufen" dargestellt.

4.5.4.3 Durchführen des Bestellvorgangs

Der Bestellvorgang kann unabhängig von der aktuell aktiven Darstellungskomponente durch einen Klick auf den Bestellen-Button ausgelöst werden. Dadurch wird ein Event ausgelöst, welches in der Controllerklasse verarbeitet wird. In dem Objekt der Controllerklasse wird überprüft, ob sich Produkte im Warenkorb befinden. Wenn dies nicht der Fall ist, wird eine entsprechende Meldung an den Anwender ausgegeben. Wenn sich Produkte im Warenkorb befinden, wird der Warenkorb über das Objekt der Containerklasse an das Objekt der Klasse Order übergeben. Anschließend wird die OrderView mit der Instanz der Klasse Order aufgerufen.

In dem Objekt der Order-Klasse befindet sich der aktuelle Status der Bestellung. Je nach Status wird in der OrderView eine andere Komponente aufgerufen. Die Adressdateneingabe wird bei Status "0", die Eingabe für die Bankdaten bei Status "1" und die Bestätigungsseite bei Status "2" aufgerufen. Wenn auf der Bestätigungsseite (OrderSummary) der Button zum Absenden der Bestellung geklickt wird und die AGB's akzeptiert werden, wird ein Event ausgelöst, auf welches wieder in der Controllerklasse reagiert wird. Dort werden dem Webservice, der die Daten ins SAP-System überträgt, die entsprechenden Argumente der Bestellung zugewiesen. Anschließend wird der Request an das SAP-System gesendet.

Im Front-End wird danach das Ergebnis (Erfolg oder Fehler) angezeigt und die Bestellungsdaten werden im Erfolgsfall wieder initialisiert. Der Ablauf wird leicht gekürzt im Sequenzdiagramm in Abbildung "Sequenzdiagramm: Bestellvorgang durchführen" verdeutlicht. Verzichtet wird in der Darstellung auf die Eingabe der Adress- und der Bankdaten. Die Meldungen an den Anwender, wenn die Bestellausführung mit einem leeren Warenkorb aufgerufen wird oder die AGB's nicht vor dem Absenden der Bestellung akzeptiert wurden, werden aus Gründen der Übersichtlichkeit nicht mit in dem Diagramm dargestellt. Ebenso wird die Überprüfung ob das Übertragen der Daten erfolgreich verlief, vor dem Initialisieren der Bestellungsdaten nicht in dem Sequenzdiagramm aufgeführt.

4.6 Durchzuführende Testschritte

Die Teststrategie zur Sicherstellung einer problemlos funktionierenden Software beinhaltet sowohl einen Komponenten- als auch einen Integrationstest. Da die zu entwickelnde Logik keine äußerst komplexen Abläufe beinhaltet, kann auf weitere Tests verzichtet werden. Das betriebssystemübergreifende Funktionieren kann im Rahmen des Integrationsstests durch den Aufruf der Anwendung von verschiedenen PCs mit unterschiedlichen Betriebssystemen getestet werden.

Der Komponententest findet für alle zu entwickelnden Komponenten statt, die losgelöst von den anderen Komponenten getestet werden können. Dazu gehören nahezu alle Komponenten, die im Back-End entwickelt werden. Die korrekte Selektion der Produktdaten kann nach Erstellung der Tabellen und Views durch einfache Datenbankabfragen auf die Views getestet werden.

Die Übertragung der Produktdaten an das Front-End kann getestet werden, indem die BSP-Applikationen im Browser aufgerufen werden. Die Struktur der dadurch angezeigten XML-Dokumente muss dem Aufbau der in Abschnitt "Definition der Schnittstellen" dargestellten XML-Dateien entsprechen. Der Funktionsbaustein, der die Bestellungsdaten von dem Webservice entgegen nimmt, wird im SAP in der Transaktion "SE37" über die integrierte Testfunktionalität getestet. Der Webservice an sich lässt sich nur gemeinsam mit dem Front-End richtig testen. Im Front-End ist nur teilweise ein Komponententest möglich. Lediglich die Formulare für die Adress- und Bankeingabe, inklusive der Datenprüfroutinen, und das Layout der verschiedenen Views können losgelöst von dem Back-End getestet werden.

Der korrekte Aufbau der Kommunikation zwischen Front- und Back-End kann im Integrationstest ohne große Probleme verifiziert werden. Wenn nach dem Aufruf der Shopapplikation Artikel in den Kategorien Notebooks und Zubehör vorhanden sind, wurden die Daten aus dem Back-End gelesen. Alle weiteren Requests, die von dem Front- an das Back-End gesendet werden, sind von der Art her vergleichbar mit dem Abruf der Produktdaten. Fehler innerhalb der Kommunikation sind bei korrekter Produktdatenübertragung nicht zu erwarten.

Im Integrationstest werden mehrere komplette Bestellvorgänge durchgeführt. Bei diesen Bestellvorgängen werden sämtliche Aktionen (Vergleich von Produkten, Anzeige von Produktdetails, Ändern der Bestellmenge von Produkten im Warenkorb, Suche nach Produkten in der Produktübersicht, korrekte und fehlerhafte Eingabe von Daten bei der Adress- und Bezahldateneingabe) durchgeführt und somit auf ihre Funktionalität hin geprüft. In der Tabelle ZCT_ORDER_TEST wird nach dem Abschließen der Bestellungen überprüft, ob die eingegebenen Daten fehlerfrei übertragen wurden.

Die Plausibilitätsprüfungen für die Adress- und Bezahldaten basieren auf dem Muster, dem die erwarteten Daten normalerweise entsprechen. Personen- Orts- und Kreditinstitutsnamen beinhalten i.d.R nur alphabetische und Sonderzeichen. Die Straße kann inklusive der Hausnummer aus alphanumerischen und Sonderzeichen bestehen. Postleitzahl, Bankleitzahl und Kontonummer bestehen im Normalfall nur aus numerischen Zeichen. Komplexere Prüfungen in der Art, ob die Postleitzahl zum eingegebenen Ort gehört, sind im Prototyp nicht hinterlegt. Zum Testen der Plausibilitätsprüfung ist es demnach ausreichend, Werte einzugeben, die dem erwarteten Muster nicht entsprechen.

Zum Abschluss der Tests wird der Onlineshop aufgerufen, während das Back-End nicht verfügbar ist. Wenn dies zu einem Hinweis an den Anwender führt, ohne dass die Anwendung abstürzt, sind die Tests des Prototyps damit abgeschlossen.

5 Bewertung

In den folgenden Abschnitten findet eine Bewertung des entwickelten Prototyps statt. Diese beginnt mit der Entwicklung an sich. Anschließend werden Besonderheiten für Unternehmen, die Onlineshops basierend auf Adobe Flex einsetzen, dargestellt. Die erwarteten Änderungen für Kunden werden danach beschrieben. Abschließend werden die Entwicklungsperspektiven aufgezeigt, die über die in Abschnitt "Weitere erforderliche Funktionalität für den Produktiveinsatz" geschilderten Funktionen hinausgehen.

5.1 Herausforderungen bei der Umsetzung der Applikation

Die Entwicklung der Back-End-Komponenten konnte ohne Schwierigkeiten innerhalb der geplanten Zeit abgeschlossen werden. Bei der Entwicklung der Komponenten des Front-Ends traten kleinere Probleme auf, die auf die fehlende Erfahrung im Umgang mit Adobe Flex zurückzuführen sind. Diese Probleme konnten aber mit Hilfe der Bücher [Tapper et al. (2008)] und [Widjaja (2008)] gelöst werden. Lediglich bei dem Ermöglichen der Kommunikation zwischen Front- und Back-End und bei der Übergabe der Bestellungsdaten an den Webservice traten größere Probleme auf, deren Lösung mehr Zeit als geplant in Anspruch genommen hat.

Der Aufbau der Verbindung von dem Front- zu dem Back-End erfolgte wie erwartet. Für das Aufrufen der Http- bzw. Webservices wird von dem FP9 allerdings überprüft, ob der Zugriff von dem Front- auf das Back-End überhaupt gestattet ist. Zu diesem Zweck wird ein XML-File von dem Root-Verzeichnis des Back-End-Systems gelesen. Diese Datei muss den Namen crossdomain.xml haben und einem von Adobe vorgegebenen Aufbau besitzen. Innerhalb dieser Datei werden alle Domains, von denen auf die Http- und Webservices zugegriffen werden dürfen, angegeben. Durch fehlende Zugriffsberechtigungen für das Root-Verzeichnis des SAP NetWeaver Application Servers konnte diese Datei nicht dort abgelegt werden und die Verbindung von dem Front- zu dem Back-End scheiterte. Erst nach längerer Suche im Internet konnte ein Workaround implementiert werden, durch den der FP9 die Zugriffsberechtigung mit Hilfe einer beliebigen anderen Datei, deren Aufbau identisch zu der Datei crossdomain.xml sein muss, überprüfen kann. Diese Datei wurde neben den BSP-Applikationen abgelegt.

Bei der Übergabe der Bestellungsdaten an den Webservice trat das Problem auf, dass in den Dokumentationen keine während der Entwicklung noch unbekannte Tabelleninhalte behandelt werden. Eine solche Tabelle muss aber für das Übertragen der Materialnummern und Bestellmengen an den Webservice übergeben werden. Diese Herausforderung konnte erst zufriedenstellend gelöst werden, nachdem der Aufbau der Webservicestruktur in Adobe Flex im Debugger analysiert wurde. Danach stellte die korrekte Datenübergabe kein Problem mehr dar.

5.2 Effekte auf Unternehmen durch die Integration eines Adobe Flex Onlineshops

Dadurch, dass der Prototyp bei keinem Unternehmen im Einsatz ist, können keine betriebswirtschaftlichen Effekte auf die Unternehmen analysiert werden. Da die Entwicklung allerdings nahezu innerhalb der geplanten Zeit erfolgte und die Entwicklung eines vergleichbaren Onlineshops auf Basis einer klassischen Webapplikation nicht weniger aufwändig wäre, können zumindest die Entwicklungskosten bei der Entscheidung zwischen klassischer Webapplikation oder RIA vernachlässigt werden. Durch die problemlose Anbindung an alle Webservicefähigen ERP-Systeme, kann der manuelle Aufwand zur Bearbeitung von Internetbestellungen auf ein erforderliches Minimum reduziert werden, sobald der Onlineshop in eine existierende Systemlandschaft integriert wird.

Durch den Einsatz des Prototyps werden verschiedene Kunden vom Einkaufen in dem bereitgestellten Onlineshop ausgeschlossen. Der Onlineshop entspricht weder den Prinzipien der Barrierefreiheit, noch ist er für Anwendern mit mobilen Endgeräten (Handy, PDA, ...) oder Computern ohne FP9 aufrufbar. Produkte, die hauptsächlich im M-Commerce vertrieben werden, oder die primär von Anwender gekauft werden, für die barrierefreie Applikationen erforderlich sind, sind deshalb für diesen Onlineshop nicht zu empfehlen.

Die Darstellung des Onlineshops findet auf allen unterstützten Betriebssystemen nahezu identisch statt. Anders als bei anderen Shopsystemen kann dadurch eine einheitliche Außendarstellung erreicht werden, ohne dass zusätzlicher Test- und Entwicklungsaufwand zu erwarten ist.

Durch die moderne, auf Events und Webservices basierende Architektur ist sowohl eine Erweiterung des Funktionsumfangs ohne große Änderungen an der bestehenden Applikation möglich als auch eine größtmögliche Flexibilität bei der Auswahl des Back-End-Systems gewährleistet. Andere ERP-, CRM- oder Katalogsysteme können ohne großen Aufwand in die Anwendung integriert werden. Die Wahl der Programmiersprache ermöglicht das Einbinden von Shockwave-Videos zur Produktpräsentation, wodurch sich Unternehmen noch deutlicher von Konkurrenz-Onlineshops abgrenzen können.

Der entwickelte Prototyp reduziert die Anfragen, die von Kunden an den Webserver gesendet werden deutlich, da bei der ersten Anfrage die gesamte Applikation an den Kunden übertragen wird und im Verlauf eines Einkaufsvorgangs keine weiteren Anfragen an den Webserver gesendet werden. Selbst bei vielen, nahezu gleichzeitig agierenden Anwendern, ist es deshalb unwahrscheinlich, dass der Webserver an seine Grenzen gerät und Anwenderrequests nicht mehr beantworten kann.

Mehraufwand ist allerdings bei der Auswertung der Anwenderzugriffe zu erwarten. Bei klassischen Webanwendungen stellt nahezu jede Anwenderaktion den Abruf einer Webseite von dem entsprechenden Webserver dar. Diese Abrufe können von dem Webserver in Log-Dateien gespeichert werden. Dadurch kann eine Auswertung von Anwender-Surfgewohnheiten, -Vorlieben, etc. erfolgen. Durch eine Analyse der Verweildauer auf verschiedenen Webseiten kann ermittelt werden, welche Produkte besonderes Interesse bei Kunden hervorrufen. Bei dem entwickelten Webshop finden nahezu keine Webseitenabrufe von dem Webserver statt. Dadurch ist in der jetzigen Version nahezu kein Logging und dementsprechend auch fast keine Auswertung des Kundenverhaltens möglich. Diese Informationen sind im Normalfall allerdings unverzichtbar für Unternehmen.

Ebenso unverzichtbar ist es für Unternehmen, dass ihr Onlineshop im Internet gefunden wird. Suchmaschinen sind aber mit dem korrekten Indizieren des Inhalts von Flash-Applikationen überfordert. Anwender, die Produkte suchen, welche in dem entwickelten Webshop angeboten werden, finden in Suchmaschinen keinen Verweis auf diesen Onlineshop. Dadurch ist es schwieriger für das Unternehmen, neue Kunden zu gewinnen.

In Abschnitt "Entwicklungsperspektiven" wird beschrieben, was notwendig ist, um die beiden zuletzt geschilderten Probleme zu lösen.

5.3 Auswirkungen von Adobe Flex Shopapplikationen auf Kunden

Auf mögliche Kunden gibt es durch den Einsatz des entwickelten Shopsystems verschiedene positive als auch negative Auswirkungen.

Die Ladezeit beim Aufruf des Onlineshops ist deutlich höher als bei klassischen Webapplikationen. Nach dem initialen Laden ist aber eine Bedienung völlig ohne Ladezeiten möglich. Dadurch das auch Flash-Applikationen im Browsercache abgelegt werden, ist die Ladezeit bei erneuten Aufrufen des Onlineshops wesentlich kürzer als beim initialen Aufruf. Der Status des Ladevorgangs wird durch eine automatische Ladestandsanzeige dargestellt. Während dem Anwender bei klassischen Webapplikationen nicht immer klar ist, ob eine Anfrage vom Webserver bearbeitet wird oder die Anwendung einfach nicht mehr reagiert, kann der Anwender in dem neuen Onlineshop den Status seiner Webserveranfrage anhand des Ladestandanzeigers nachvollziehen.

Da fast alle Applikationsteile auf den PC des Anwenders übertragen und dort ausgeführt werden, führt auch ein zwischenzeitlicher Abbruch der Internetverbindung in den meisten Fällen nicht zu einem fehlerhaften Verhalten des Onlineshops. Lediglich bei der Übertragung der Applikation an den Anwender-PC und beim Absenden einer Bestellung wirken sich Verbindungsabbrüche negativ aus. Klassische Webapplikationen sind bei einem temporären Verbindungsverlust nicht bedienbar.

Durch die modernen Möglichkeiten der Produktpräsentation und den Einsatz unaufdringlicher Animationseffekte, wird das Surferlebnis für den Anwender im Vergleich zu klassischen Webapplikationen deutlich verbessert und Kunden zum erneuten Aufrufen des Onlineshops eingeladen.

In der jetzigen Konfiguration ist für Kunden weder eine Navigation mit den Browserfunktionen (Zurück, Vorwärts), noch eine Speicherung von bestimmten Produktseiten unter den Favoriten möglich. Dies stellt einen Nachteil im Vergleich zu klassischen Webapplikationen dar, kann aber durch die in Abschnitt "Entwicklungsperspektiven" vorgestellten Erweiterungen nahezu an das Verhalten von klassischen Webapplikationen angepasst werden.

5.4 Entwicklungsperspektiven

Neben den in Abschnitt "Weitere erforderliche Funktionalität für den Produktiveinsatz" empfohlenen Erweiterungen für einen Produktiveinsatz gibt es zusätzliche Erweiterungsmöglichkeiten, die die Zufriedenheit auf Kunden- und Unternehmensseite erheblich steigern können. Diese werden nachfolgend kurz erläutert.

• Browserhistorie: Das Adobe Flex Framework bietet die Möglichkeit, die Browserhistorie mit Hilfe der vorhandenen Interfaces BrowserManager oder HistoryManager zu aktivieren. Durch das Einbinden von einem dieser Interfaces wird die Browsernavigation über den Zurück- und Vorwärtsbutton ermöglicht. Diese Navigation ist vergleichbar mit der Browsernavigation in klassischen Webapplikationen, aber nicht identisch. Das Hinzufügen eines Produktes zum Warenkorb, das Ändern der Bestellmenge, die Veränderung eines Produktfilters oder das Markieren eines Produktes für den Produktvergleich wird bspw. nicht in der Browserhistorie abgespeichert. Einfache Navigationsaufrufe, z.B. die Auswahl einer neuen Produktkategorie, können über diese Interfaces aber leicht zur Browserhistorie hinzugefügt werden.
• Produkteinzeladressierung: Wie bereits im Abschnitt "Auswirkungen von Adobe Flex Shopapplikationen auf Kunden" erwähnt, ist es in dem entwickelten Prototyp nicht möglich, einzelne Produktseiten bei den Browserfavoriten zu speichern oder den Link auf diese Seite an Freunde oder Bekannte zu mailen. Über das Einbinden des BrowserManager-Interfaces kann ein so genanntes Deep Linking innerhalb einer Adobe Flex Applikation ermöglicht werden. Eine vollständige Implementierung des Deep Linkings für den Onlineshop ist mit Hilfe dieses Interfaces in weniger als einem Arbeitstag problemlos möglich. Die beschriebene Browserhistorie würde dabei direkt mit aktiviert. Kompatibel ist das Deep Linking allerdings nur mit den Browsern Internetexplorer, Firefox und Safari^[42].
• Logging: Das Logging ist nicht ganz so einfach implementierbar, wie die bisher erläuterten Erweiterungsmöglichkeiten. Um das Logging von Seitenaufrufen zu ermöglichen, bietet es sich an, auf jeder Seite HttpRequests zu implementieren, die bei jedem Seitenaufruf relevante Informationen an das Back-End oder an den Webserver übertragen. Diese Informationen können dort gespeichert und später ausgewertet werden. Für den Anwender ergeben sich daraus keinerlei Nachteile, da die Applikation nicht auf eine Antwort auf die HttpRequests warten muss. Allerdings wird der Datenaustausch zwischen Front- und Back-End bzw. Webserver dadurch deutlich erhöht.
• Suchmaschinenoptimierung: Um das Problem zu umgehen, dass der Onlineshop bei Produktsuchen in einer Suchmaschine nicht gelistet wird, können verschiedene Lösungsansätze verfolgt werden. Es ist möglich, eine so genannte DoorPage zu implementieren, die eine Weiterleitung auf den eigentlichen Onlineshop vornimmt. Auf dieser DoorPage können statisch oder dynamisch die im Onlineshop angebotenen Produkte aufgezählt werden. So wird eine Suchmaschinenindizierung des Onlineshops ermöglicht. Allerdings wird dieses Vorgehen von Suchmaschinenbetreibern ungern gesehen und kann zu einem Ausschluss der Webseite aus der Suchmaschine führen. Besser ist deshalb eine Aufzählung der Produkte in den Metadaten der Webseite, auf der die RIA eingebunden wird. Dieses Vorgehen ist zwar nicht ganz so effektiv wie die DoorPage, führt dafür aber nicht zu einem Suchmaschinenausschluss.
• Druckfunktionen: Die bisherige Applikation ermöglicht es Anwendern nicht, aufgerufene Seiten oder die Bestellbestätigung zu drucken. Das Adobe Flex Framework bietet die Möglichkeit, das Drucken über das Einbinden der PrintJob Klasse zu aktivieren. Allerdings müssen einige der entwickelten Komponenten für eine optimale Ausdruckdarstellung angepasst werden. Um den Aufwand möglichst gering zu halten, dem Anwender aber trotzdem ein Ausdrucken von verschiedenen Seiten zu ermöglichen, sollten nur wesentliche Komponenten (Bestellübersicht und Vergleichsdarstellung) für den Druck optimiert werden. Die Produktdetaildarstellung kann hier ignoriert werden, da die Produktdetails als PDF herunter geladen werden können.
• Warenkorbspeicherung: Um Anwendern, die vor dem finalen Absenden der Bestellung noch Bedenkzeit benötigen, entgegen zu kommen, kann ein Feature implementiert werden, welches eine lokale Speicherung der Bestellungsdaten auf dem PC des Anwenders ermöglicht. Diese Speicherung findet in einem so genannten SharedObject statt. Dies kann zu einem beliebigen späteren Zeitpunkt wieder in die Anwendung geladen werden. Eine erneute Eingabe der Adress- und Bezahldaten wird dadurch ebenso überflüssig, wie ein erneutes Zusammenstellen des Warenkorbs. Die SharedObject Technologie kann ohne großen Mehraufwand innerhalb eines halben Arbeitstages implementiert werden und kann zu einer erheblichen Steigerung der Kundenzufriedenheit beitragen.
• Offlineversion: Wenn der Onlineshop für andere Produkte angepasst werden soll, bspw. für Produkte, die auch von Vertretern vertrieben werden, kann ohne großen Aufwand eine Offlineversion des Shops erstellt werden. Dafür kann die Technologie AIR (Adobe Integrated Runtime) verwendet werden. Immer wenn ein Internetzugang zur Verfügung steht, können die Produktdaten aus dem Back-End gelesen und offline getätigte Bestellungen von dem Front- an das Back-End übertragen werden.

6 Schlussbetrachtung

Nach dem Erstellen des technischen Konzeptes konnte der Onlineshop ohne große Schwierigkeiten nahezu innerhalb der geplanten Zeit implementiert werden. Die gute Unterstützung von Webservices und die große Auswahl an Designkomponenten vereinfachten die Entwicklung im Vergleich zu klassischen Webapplikationen dabei deutlich. Die Erwartungen, die vor der Entwicklung an das neue Shopsystem gestellt wurden, können in den Punkten Erweiterbarkeit, Wartbarkeit und Benutzerfreundlichkeit voll erfüllt werden.

Die derzeit noch fehlende Tauglichkeit für das M-Commerce, die Benötigung eines Plug-Ins auf dem PC des Anwenders, die hohe initiale Ladezeit und die fehlende Barrierefreiheit sorgen zwar für eine Verkleinerung der potenziellen Kundenanzahl, wirken sich aber für die meisten Produkte nicht so negativ aus, dass ein Einsatz des neuen Shopsystems gar nicht erst in Erwägung gezogen werden sollte.

Für sämtliche weiteren Schwachpunkte, z.B. fehlende Druckunterstützung, fehlendes Logging, schlechte Suchmaschinenoptimierung, etc. existieren Lösungsansätze, deren Implementierung einerseits Zeit in Anspruch nimmt und somit Kosten verursacht, andererseits aber die Chance bietet, nach vorheriger Analyse der Bedürfnisse sowohl die Kunden- als auch die Unternehmensanforderungen bestmöglich zu erfüllen.

Weder der erstellte Prototyp noch die erstellbare Produktivversion des Onlineshops stellen aufgrund der beschriebenen Schwächen neue Maßstäbe für Shopapplikationen auf. Durch die größere Kundennähe, die durch die verbesserten Produktpräsentationsmöglichkeiten in Verbindung mit dem gesteigerten Surf- bzw. Einkaufserlebnis erzielt wird und die hervorragenden Möglichkeiten zur Integration des Onlineshops in eine bestehende Systemlandschaft, bietet sich das neue Shopsystem aber als gute Alternative zu bereits existierenden Shopsystemen an. Die direkte Anbindung an neue oder bereits vorhandene ERP-Systeme ermöglicht dabei eine Automatisierung der Prozesse zum Anlegen von Kundenbestellungen im ERP-System. Die damit verbundenen Kosteneinsparungen können genutzt werden, um die bestehenden Schwächen des Onlineshops zu beseitigen und somit ein System zu erhalten, welches auf Kunden- und auf Unternehmensseite große Akzeptanz findet.

7 Fußnoten

1. ↑ vgl. Ahlreep et al. (2000) S. 19
2. ↑ vgl. Kalakota / Whinston (1997) S. 3
3. ↑ vgl. Fritz (2004) S. 26 f.
4. ↑ vgl. Beyer et al. (2003) S. 14 f.
5. ↑ angelehnt an: Wirtz (2002) S. 141
6. ↑ vgl. Kollmann (2007) S. 371
7. ↑ vgl. Ebel (2007) S. 79
8. ↑ vgl. Kollmann (2007) S. 375
9. ↑ vgl. Kollmann (2007) S. 386
10. ↑ vgl. Wirtz (2001) S. 334
11. ↑ angelehnt an: Merz (2002) S. 24
12. ↑ vgl. Albers et al. (1999) S. 10
13. ↑ vgl. Kollmann (2007) S. 38 f.
14. ↑ vgl. Ebel (2007) S. 46
15. ↑ vgl. Kollmann (2007) S. 39
16. ↑ vgl. Wirtz (2001) S. 274 f.
17. ↑ vgl. Ebel (2007) S. 46
18. ↑ vgl. Wirtz (2001) S. 39 f.
19. ↑ vgl. Ohne Verfasser (2006) S. 12
20. ↑ vgl. Ebel (2007) S. 42 und Orwat (2002) S. 9
21. ↑ angelehnt an: Kollmann (2007) S. 251
22. ↑ vgl. Kollmann (2007) S. 249 f.
23. ↑ angelehnt an: Wolf (2007) S. 93 ursprünglich erstellt von United-Research
24. ↑ vgl. Tchoukio (2004) S. 1
25. ↑ vgl. Liebhart (2007) S. 8
26. ↑ vgl. Liebhart (2007) S. 7
27. ↑ vgl. Pomberger / Pree (2004) S. 217 f.
28. ↑ vgl. Pomberger / Pree (2004) S. 218
29. ↑ angelehnt an: Liebhart (2007) S. 16
30. ↑ vgl. Liebhart (2007) S. 16
31. ↑ vgl. Lorenz et al. (2006) S. 20
32. ↑ angelehnt an: Lorenz et al. (2006) S. 21
33. ↑ vgl. Ohne Verfasser (2008b)
34. ↑ vgl. Ohne Verfasser (2008c)
35. ↑ vgl. Ohne Verfasser (2008d)
36. ↑ vgl. Widjaja (2008) S. 2
37. ↑ vgl. Moroney (2007)
38. ↑ vgl. Ohne Verfasser (2008e)
39. ↑ vgl. Tapper et al. (2008) S. 10 f.
40. ↑ vgl. Louis / Müller (2003) S. 21
41. ↑ vgl. Frick et al. (2008) S. 1 ff.
42. ↑ vgl. Ohne Verfasser (2008a)

8 Literaturverzeichnis

Ahlreep et al. (2000)	Ahlreep, Jens; Mocker, Helmut; Mocker, Ute: E-Commerce im Griff. 2. Auflage. Datakontext Fachverlag GmbH, Frechen, 2000
Albers et al. (1999)	Albers, Sönke; Clement, Michel; Peters, Kay; Skiera, Bernd (Hrsg.): eCommerce. F.A.Z.-Institut für Management-, Markt- und Medieninformationen GmbH, Frankfurt am Main, 1999
Beyer et al. (2003)	Beyer, Lothar; Frick, Detlev; Gadatsch, Andreas; Maucher, Irene ; Paul, Hansjürgen (Hrsg.): Vom E-Business zur E-Society. Rainer Hampp Verlag, München und Mering, 2003
Ebel (2007)	Ebel, Bernd; Olfert, Klaus (Hrsg.): Kompakt-Training E-Business. Friedrich Kiehl Verlag GmbH, Leipzig, 2007
Frick et al. (2008)	Frick, Detlev; Gadatsch, Andreas; Schaffer-Külz, Ute G.: Grundkurs SAP ERP. Friedr. Vieweg und Sohn Verlag, Wiesbaden, 2008
Fritz (2004)	Fritz, Wolfgang: Internet-Marketing und Electronic Commerce. 3. Auflage. Betriebswirtschaftlicher Verlag Dr. Th. Gabler GmbH, Wiesbaden, 2004
Kalakota / Whinston (1997)	Kalakota, Ravi; Whinston, Andrew B.: Electronic Commerce - A Manager's Guide. Addison Wesley Longman, Inc., 1997
Kollmann (2007)	Kollmann, Tobias: E-Business - Grundlagen elektronischer Geschäftsprozesse in der Net Economy. 2. Auflage. Betriebswirtschaftlicher Verlag Dr. Th. Gabler GmbH, Wiesbaden, 2007
Liebhart (2007)	Liebhart, Daniel: SOA goes real - Service-orientierte Architekturen erfolgreich planen und einführen. Carl Hanser Verlag, München, 2007
Lorenz et al. (2006)	Lorenz, Armin; Schöppe, Gunther; Consbruch, Felix; Knapp, Daniel; Sonnenberg, Frank: SAP-Anwendungen mit Adobe Flex. Galileo Press, Bonn, 2006
Louis / Müller (2003)	Louis, Dirk; Müller, Peter: Jetzt lerne ich Java. Markt+Technik Verlag, München, 2003
Merz (2002)	Merz, Michael: E-Commerce und E-Business: Marktmodelle, Anwendungen und Technologien. 2. Auflage. dpunkt.verlag GmbH, Heidelberg, 2002
Moroney (2007)	Moroney, Laurence; Microsoft Corporation (Hrsg.): Erste Schritte mit Silverlight. Internet. http://www.microsoft.com/germany/msdn/library/net/wpf/ErsteSchritteMitSilverlight.mspx?mfr=true. Version: 2007, Abruf: 21.09.2008
Ohne Verfasser (2006)	IT-Stab (Hrsg.): E-Government 2.0. Internet. http://www.kbst.bund.de/cln_012/nn_998588/SharedDocs/Publikationen/eGovernment/egov__2__0__programm,templateId=raw,property=publicationFile.pdf/egov_2_0_programm.pdf. Version: 2006, Abruf: 13.11.2008
Ohne Verfasser (2008a)	Ohne Verfasser; Adobe Systems Incorporated (Hrsg.): About deep linking. Internet. http://livedocs.adobe.com/flex/3/html/help.html?content=deep_linking_2.html. Version: 2008, Abruf: 16.11.2008
Ohne Verfasser (2008b)	Ohne Verfasser; Adobe Systems Incorporated (Hrsg.): Andere Version des Adobe Flash Player installieren. Internet. http://get.adobe.com/de/flashplayer/otherversions/. Version: 2008, Abruf: 16.11.2008
Ohne Verfasser (2008c)	Ohne Verfasser; Microsoft Corporation (Hrsg.): FAQ. Internet. http://www.microsoft.com/silverlight/overview/faq.aspx#sys-req. Version: 2008, Abruf: 16.11.2008
Ohne Verfasser (2008d)	Ohne Verfasser; Sun Microsystems (Hrsg.): Java-Downloads für alle Betriebssysteme. Internet. http://www.java.com/de/download/manual.jsp. Version: 2008, Abruf: 16.11.2008
Ohne Verfasser (2008e)	Ohne Verfasser; Mono Project (Hrsg.): Moonlight. Internet. http://www.mono-project.com/Moonlight. Version: 2008, Abruf: 16.11.2008
Orwat (2002)	Orwat, Carsten: Innovationsbedingungen des E-Commerce - der elektronische Handel mit digitalen Produkten. Internet. http://www.tab.fzk.de/de/projekt/zusammenfassung/hp8.pdf. Version: 2002, Abruf: 21.09.2008
Pomberger / Pree (2004)	Pomberger, Gustav; Pree, Wolfgang: Software Engineering: Architektur-Design und Prozessorientierung. 3. Auflage. Carl Hanser Verlag, München, 2004
Tapper et al. (2008)	Tapper, Jeff; Labriola, Michael; Boles, Matthew; Talbot, James: Adobe Flex 3 Das offizielle Trainingsbuch. Addison-Wesley Verlag, München, 2008
Tchoukio (2004)	Tchoukio, Gael: Aufbau einer Web-Anwendung (JSP o. ASP o. PHP). Internet. http://www4.informatik.uni-erlangen.de/Lehre/SS04/PS_KVBK/talks/Handout-Webanwendung-2.pdf. Version: 2004, Abruf: 21.09.2008
Widjaja (2008)	Widjaja, Simon: Rich Internet Applications mit Adobe Flex 3. Carl Hanser Verlag, München, 2008
Wirtz (2001)	Wirtz, Bernd W.: Electronic Business. 2. Auflage. Betriebswirtschaftlicher Verlag Dr. Th. Gabler GmbH, Wiesbaden, 2001
Wirtz (2002)	Wirtz, Bernd W.: Kompakt Lexikon eBusiness. Betriebswirtschaftlicher Verlag Dr. Th. Gabler GmbH, Wiesbaden, 2002
Wolf (2007)	Wolf, Volkhard: E-Marketing. Oldenbourg Wissenschaftsverlag GmbH, München, 2007

9 Abkürzungsverzeichnis

Abkürzung	Bedeutung
(D)HTML	(Dynamic) Hypertext Markup Language
ABAP	Advanced Business Application Programming
AGB	Allgemeine Geschäftsbedingungen
AIR	Adobe Integrated Runtime
AJAX	Asynchronous JavaScript and XML
AS	ActionScript
ASCII	American Standard Code for Information Interchange
B2A	Business to Administration
B2B	Business to Business
B2C	Business to Consumer
BGB	Bürgerliches Gesetzbuch
BSP	Business Server Page
C2C	Consumer to Consumer
CRM	Customer Relationship Management
E-Business	Electronic Business
E-Commerce	Electronic Commerce
E-Mail	Electronic Mail
E-Marketplace	Electronic Marketplace
E-Shop	Electronic Shop
ECC	ERP Central Component
ERP	Enterprise Resource Planning
FP9	Flashplayer 9
GUI	Graphical User Interface
i.d.R.	in der Regel
JRE	Java Runtime Environment
M-Commerce	Mobile Commerce
MVC	Modell-View-Controller
MXML	Macromedia eXtensible Markup Language
Open SQL	Open Structured Query Language
P2P	Peer to Peer
PAngV	Preisangabenverordnung
PC	Personal Computer
PDA	Personal Data Assistent
PDF	Portable Document Format
px	Pixel
RIA	Rich Internet Application
SAP	Software Anwendungen Produkte
SCM	Supply Chain Management
SOA	Service-Oriented Architecture
SOAP	Simple Object Access Protocol
SSL	Secure Socket Layer
UML	Unified Modelling Language
URL	Uniform Resource Locator
USP	Unique Selling Proposition
WSDL	Web Service Description Language
XAML	eXtensible Application Markup Language
XML	eXtensible Markup Language