1.1 Firma – SAP Hosting AG & Co. KG

Fachbereich Digitale Medien
Raiffeisenring 15
Studiengang Medieninformatik
68789 St. Leon-Rot
Robert-Gerwig-Platz
78120 Furtwangen
Diplomarbeit
Systematisch Portieren
Entwicklung eines Verfahrens zur Portierung ASP basierter
Webanwendungen auf SAP® R/3® Technologien
vorgelegt von:
Ulrike Koch
Referent: Prof. Wilhelm Walter
Matrikelnummer: 200129
Koreferent: Prof. Dr. Günther Hentrich
Pestalozzistraße 13
76669 Bad Schönborn - Mingolsheim
St. Leon - Rot, den 30.06.2004
Eidesstattliche Erklärung
Ich erkläre hiermit an Eides statt, dass ich die vorliegende Diplomarbeit selbstständig und ohne
unzulässige fremde Hilfe angefertigt habe. Alle verwendeten Quellen und Hilfsmittel sind
angegeben.
St. Leon-Rot, den...
II
Kurzdarstellung der Diplomarbeit
Die SAP Hosting AG & Co. KG in St. Leon-Rot, eine 100%-ige Tochter der SAP AG, ist spezialisiert auf
das Betreiben von SAP-Anwendungen. Durch die große Anzahl der betreuten (Kunden-)Systeme, wurden
Anwendungen geschaffen, um die betriebenen Systeme zu überwachen und zu verwalten. Einige dieser
Anwendungen verfügen über eine Web basierte Oberfläche, die beispielsweise zum Großteil auf
Microsoft Produkten (MS Windows, MS Internet Information Server, MS SQL Server, ASP und Perl)
basiert. Eine dieser Anwendungen zur Administration von Servern wird derzeit auf eine SAP R/3Umgebung portiert: Linux (OS), Web Application Server (SAP Webserver), MaxDB (SAP Datenbank)
und BSP (Business Server Pages, SAP eigenes Framework für Web basierte Applikationen).
In der Praxis wird solch ein Vorhaben oft planlos angegangen. Ohne größere Vorbereitung wird
begonnen, die Anwendung umzuschreiben. Zwar scheint diese Methode Zeit einzusparen, aber eine
unstrukturierte Vorgehensweise nimmt letztendlich meistens mehr Zeit in Anspruch als die strukturierte.
Das liegt daran, dass der Programmierer Arbeitsschritte umsetzt, die ihm unverhofft einfallen, obwohl sie
besser schon vorher hätten erledigt werden sollen oder an einem späteren Zeitpunkt im Verlauf besser
angesiedelt wären. Als Folge daraus zieht sich die Portierung unnötig in die Länge. Womöglich wären
manche Arbeitsschritte aber auch nutzlos oder gar vollkommen falsch. Aufgrund solcher Fehler treten
teilweise wieder Folgefehler auf – eine „Spirale“ an Fehlern entsteht.
Auch bewirkt das fehlende Eingehen auf die Ausgangsituation im Vorfeld, dass die gesamten
Anforderungen an die Zielsituation nicht definiert werden. Dies hat zur Konsequenz, dass eine
vollständige Machbarkeit der Portierung zu Beginn des Projektes noch vollkommen ungewiss ist. So
können mögliche Grenzen der Zielplattform erst festgestellt werden, wenn man an der Portierung eines
betroffenen Teils scheitert.
Als Lösungsansatz dieses Problems wird in dieser Diplomarbeit zunächst ein Konzept entwickelt,
welches eine durchdachte Vorgehensweise zum Portieren vorgibt, um einen möglichst reibungslosen
Übergang von der einen Plattform zur anderen zu beschreiben. Dabei wird insbesondere auf die oben
genannten Technologien eingegangen. Anschließend wird dieses Portierungskonzept anhand einer
beispielhaften Portierung der bereits erwähnten Webanwendung geprüft. So wird sich mit dem Konzept
kritisch auseinander gesetzt und es kann ein Ausblick für die Zukunft gegeben werden.
III
Inhaltsverzeichnis
Eidesstattliche Erklärung............................................................................................................ II
Kurzdarstellung der Diplomarbeit ............................................................................................ III
Inhaltsverzeichnis ....................................................................................................................... IV
1
Umfeld der Arbeit ...................................................................................................................1
1.1
Firma – SAP Hosting AG & Co. KG ............................................................................... 1
1.1.1
Überblick................................................................................................................... 1
1.1.2
Die Dienstleistungen ................................................................................................. 3
1.1.2.1
Evaluation Hosting ............................................................................................ 3
1.1.2.2
Implementation Hosting .................................................................................... 4
1.1.2.3
Application Hosting ........................................................................................... 4
1.1.2.4
Remote Application Operation .......................................................................... 5
1.1.2.5
Application Management .................................................................................. 5
1.1.2.6
Upgrade Hosting ................................................................................................ 6
1.1.2.7
Hosted Learning ................................................................................................ 6
1.1.2.8
emaro ................................................................................................................. 9
1.2
Abteilung – GOS RST Technology & Infrastructure I .................................................. 10
1.3
Aufgabenstellung ........................................................................................................... 10
1.4
Verwandte Arbeiten ....................................................................................................... 12
2
1.4.1
Vorhandene Literatur .............................................................................................. 13
1.4.2
Nutzbare Literatur ................................................................................................... 13
Betrachtete Technologien.....................................................................................................14
2.1
Ausgangsplattform ......................................................................................................... 14
2.1.1
IV
Microsoft SQL Server ............................................................................................. 14
2.1.2
Microsoft Internet Information Server .................................................................... 14
2.1.3
Active Server Pages ................................................................................................ 14
2.2
3
Zielplattform................................................................................................................... 14
2.2.1
MaxDB.................................................................................................................... 15
2.2.2
SAP® Web Application Server ............................................................................... 16
2.2.3
Business Server Pages............................................................................................. 18
2.2.4
Entwicklungsumgebung .......................................................................................... 19
Portierungsverfahren ...........................................................................................................28
3.1
Allgemeines zu Portierung ............................................................................................. 28
3.1.1
Aufwand .................................................................................................................. 28
3.1.2
Vorgehensweisen .................................................................................................... 29
3.1.2.1
Top Down ........................................................................................................ 29
3.1.2.2
Bottom Up ....................................................................................................... 30
3.2
Portierungsschrit 1/6: Kennen lernen der Ausgangsanwendung.................................... 31
3.3
Portierungsschrit 2/6: Machbarkeitsprüfung .................................................................. 32
3.3.1
Datentypen der Programmiersprache ...................................................................... 32
3.3.2
Datentypen der Datenbank ...................................................................................... 37
3.3.3
HTMLB................................................................................................................... 42
3.3.4
MVC Design Pattern in BSPs ................................................................................. 45
3.3.5
Funktionlitäten ........................................................................................................ 47
3.4
Portierungsschrit 3/6: Analyse der Ausgangsanwendung .............................................. 48
3.5
Portierungsschrit 4/6: Optimierung ................................................................................ 49
3.5.1
Daten ....................................................................................................................... 49
3.5.2
Ablauflogik ............................................................................................................. 49
3.5.3
Oberfläche ............................................................................................................... 50
3.5.4
Datenbank ............................................................................................................... 50
3.6
Portierungsschrit 5/6: Implementierung der BSP Anwendung ...................................... 56
V
3.6.1
Vorarbeiten ............................................................................................................. 56
3.6.2
Datenportierung ...................................................................................................... 57
3.6.3
Umsetzung .............................................................................................................. 66
3.7
4
Portierungsschrit 6/6: Nacharbeiten ............................................................................... 66
Anwendung und Prüfung des Portierungsverfahrens ......................................................67
4.1
Kennen Lernen der Ausgangsanwendung ...................................................................... 67
4.2
Machbarkeitsprüfung ..................................................................................................... 69
4.3
Analyse der Ausgangsanwendung ................................................................................. 70
4.4
Optimierung ................................................................................................................... 70
4.5
Implementierung der BSP Anwendung.......................................................................... 70
4.6
Nacharbeiten................................................................................................................... 70
5
Zusammenfassung und Ausblick ........................................................................................71
A. Anhang...................................................................................................................................72
A.a.
Glossar spezifischer Ausdrücke und Abkürzungen ....................................................... 72
A.b.
Abbildungsverzeichnis ................................................................................................... 73
A.c.
Tabellenverzeichnis ........................................................................................................ 75
A.d.
Programmkodeverzeichnis ............................................................................................. 75
A.e.
Literaturverzeichnis ........................................................................................................ 76
VI
1 Umfeld der Arbeit
1.1 Firma – SAP Hosting AG & Co. KG
1.1.1 Überblick
SAP Hosting AG & Co. KG ist eine weltweit operierende, hundertprozentige Tochtergesellschaft
der SAP AG mit Hauptsitz in St. Leon-Rot. Weitere Niederlassungen befinden sich Walldorf,
Philadelphia, Palo Alto, Tokyo, Sydney, Singapore und Bangalore.
Die Firma wurde im August 2000 gegründet und als eine Gruppe von Spezialisten im Bereich
Beratung aus der SAP AG herausgelöst.
SAP Hosting AG & Co. KG bietet umfassende Hosting Dienstleistungen, mit denen
Unternehmen schnell und effektiv auf die neusten SAP Lösungen zugreifen können.
Die Services sind optimal auf die Bedürfnisse von Kunden der mySAP Business Suite
abgestimmt und umfassen das im Folgenden noch näher erläuterte Evaluation Hosting,
Implementation Hosting, Application Hosting, Remote Application Operations, Application
Management und Hosted Learning, sowie den Service emaro.
Im Juli des Jahres 2004 sind bei der SAP Hosting AG & Co. KG ca. 350 Mitarbeiter beschäftigt.
Weltweit kann die Firma auf ca. 100 Kunden verweisen. In Deutschland zählen
Berufsförderungswerk GmbH, Braunschweig-IT, CDI Deutsche Private Akademie, ECKART,
LS training and services, Linde AG und TERTIA zu den Kunden. In den Vereinigten Staaten von
Amerika hat die SAP Hosting AG & Co. KG Kunden wie C & H Sugar Company, Day &
Zimmermann Inc., Global Brand Marketing, Gold Banc, Sauer Danfoss Company und York
International Corporation.
Neu: saphosting.de
SAP Hosting AG & Co.KG ist eine weltweit operierende, hundertprozentige Tochtergesellschaft
der SAP AG. SAP Hosting bietet umfassende Hosting Services, mit denen Unternehmen schnell
und effektiv auf die neuesten SAP Lösungen zugreifen können.
1
Der Trend, Dienstleister mit dem teilweisen oder vollständigen Management beziehungsweise
dem Betrieb der Unternehmenssystem zu beauftragen, wird stärker. Hauptursachen sind immer
komplexer werdende IT-Landschaften und ein allgemein steigender Wettbewerbsdruck, der die
Konzentration auf Kernkompetenzen forciert.
Daher stellt SAP Hosting ein Service Portfolio bereit, welches es ermöglicht, dass sich SAP
Kunden auf die eigenen Kerngeschäfte konzentrieren können und gleichzeitig für den Betrieb
professionelle Unterstützung erhalten.
Von Carmen
SAP Hosting AG & Co. KG ist als hundertprozentige Tochter der SAP AG auf Services für den
Betrieb von Lösungen der mySAP Business Suite spezialisiert. Heute arbeiten mehr als 220
Mitarbeiter weltweit daran Dienstleistungen im Bereich Installation, Optimierung und Betrieb
von mySAP Business Suite Lösungen für die Kunden der SAP anzubieten.
Unser Leistungsangebot deckt von der Evaluation und Bewertung über die Implementierung bis
zum Produktivbetrieb und dessen Optimierung das gesamte Spektrum des Lebenszyklus von SAP
Lösungen ab.
Der direkte Zugriff und die Nähe zur Entwicklung und dem Support der SAP AG erlauben den
Kunden von SAP Hosting, zeitnah an tiefgreifendem Know-how zu partizipieren und garantiert
eine schnelle Lösung in Problemfällen. SAP Hosting greift hierbei auch auf ein breites Partner
Netzwerk zu, um spezielle Kundenanforderungen zu erfüllen und einen klaren Mehrwert zu
liefern.
Die ‚state-of-the-art’ Hochleistungsrechenzentren in St. Leon-Rot, Walldorf und Philadelphia
sind die solide Basis für die angebotenen Dienstleistungen, garantieren Hochverfügbarkeit und
höchste Sicherheitsstandrads. SAP Hosting Service und Support Niederlassung rund um den
Globus garantieren zusätzlich höchste Dienstleistungsqualität und einen führenden 7x24 Stunden
Kundensupport.
2
SAP Hosting hilft den Kunden bei der Umsetzung der jeweiligen Unternehmens- und ITStrategie mit flexiblen Dienstleistungen, welche die Wettbewerbsfähigkeit des Kunden stärken
ohne seine unternehmerischen Spielraum einzuschränken.
1.1.2 Die Dienstleistungen
SAP Hosting AG & Co. KG verschafft seinen Kunden den Zugang zu Applikationen und der
dazu notwendigen Infrastruktur, die sein Business erfolgreich machen. Dabei handelt es sich um
Lösungen, die sofort einsatzbereit sind und sich den wachsenden Anforderungen des Kunden
anpassen. So profitieren die Kunden von der schnellen Einführung, den überschaubaren Kosten
und dem Vorteil sich auf ihre Kernkompetenzen konzentrieren zu können.
Mit SAP Hosting AG & Co. KG Dienstleistungen schöpfen die Kunden das volle
Anwendungspotential des führenden Anbieters von integrierten E-Business-Lösungen aus. Dabei
versteht sich die mySAP Business Suite als Gesamtpaket aus Software und Serviceleistungen, die
Kunden,
Partnern
und
Mitarbeitern
eine
erfolgreiche
unternehmensübergreifende
Zusammenarbeit ermöglichen - jederzeit und überall.
SAP Hosting AG & Co. KG Services sind für die Bedürfnisse von mySAP Business Suite
Kunden entwickelt worden, ganz gleich ob es sich um das Hosten von einzelnen Komponenten
oder ganze Landschaften der mySAP Business Suite handelt.
Die SAP Hosting AG & Co. KG unterstützt ihre Kunden von der Evaluierung, über die
Implementierung, bis hin zum optimierten Betrieb ihrer mySAP Business Suite Lösungen mit
folgenden Dienstleistungen:
1.1.2.1 Evaluation Hosting
Mit der Dienstleistung Evaluation Hosting stellt SAP Hosting AG & Co. KG die geeignete
Umgebung zur Verfügung, die das Bewertungsverfahren zur Auswahl einer SAP Lösung
unterstützt. Experten von SAP Hosting AG & Co. KG betreiben die Systemumgebung, dadurch
kann sich der Kunde allein auf die Evaluierung der Software konzentrieren. Zu diesem Zeitpunkt
muss sich der Kunde um Hardware, Sizing oder sonstige IT Ressourcen nicht kümmern.
3
Die Bereitstellung dieser Dienstleistung erfolgt innerhalb kurzer Zeit. Wenn sich der Kunde für
eine Implementierung der SAP Lösung entschieden hat, unterstützt SAP Hosting AG & Co. KG
ihn durch die Dienstleistung Implementation Hosting.
1.1.2.2 Implementation Hosting
Mit Hilfe der Dienstleistung Implementation Hosting kann sich der Kunde auf das Wesentliche,
die Einführung Ihrer mySAP Business Suite konzentrieren. Insbesondere vor einem SoftwareEinführungsprojekt, gibt es oft herausfordernde Anforderungen an die zeitliche Planung und die
erfolgreiche Umsetzung des gesamten Projektes. Durch einen sicheren und stabilen Betrieb der
Systemumgebung werden Planungsrisiken reduziert und die Konzentration auf eine optimale
Abbildung Ihrer betrieblichen Prozesse möglich.
Die Dienstleistung Implementation Hosting bietet die kurzfristige Verfügbarkeit des
Entwicklungssystems zu einem Festpreis. Dies bietet die Möglichkeit, die Planungssicherheit zu
erhöhen und auf diese Weise die Einführungskosten kalkulierbar zu gestalten. Es wird zudem
Flexibilität im Rahmen des zur Verfügung stehenden IT-Budgets gewonnen.
Personalfragen, wie beispielsweise zusätzliche Mitarbeiter, Ausbildung/Skills und Fragen
bezüglich des Betriebs stellen sich zu diesem Zeitpunkt nicht. Mit der Dienstleistung
Implementation Hosting nutzt der Kunde eine optimal auf seine Bedürfnisse zugeschnittene
Hardware in den Hochleistungs-Rechenzentren der SAP Hosting AG & Co. KG.
Durch eine kurze Laufzeit, lässt sich diese Dienstleistung ganz besonders an den zeitlichen
Rahmen des Einführungsprojektes anpassen. Sobald die Einführung abgeschlossen ist, kann der
Kunde die SAP Lösung selbst betreiben oder die SAP Expertise und Erfahrung der SAP Hosting
AG & Co. KG im Betrieb von Lösungen der mySAP Business Suite im Rahmen des Application
Hosting für den produktiven Betrieb nutzen.
1.1.2.3 Application Hosting
Das Motto „SAP Produktivbetrieb auslagern und auf Kernkompetenzen konzentrieren“
verwirklicht die Dienstleistung Application Hosting.
Immer mehr Unternehmen entscheiden sich dafür, ihre mySAP™ Business Suite Lösung von
SAP-Experten der SAP Hosting AG & Co. KG sicher und stabil betreiben zu lassen. Mit der
Dienstleistung Application Hosting profitieren Kunden zudem von transparenten Kosten,
4
garantierten Verfügbarkeiten, einer skalierbaren IT-Lösung und dem spezifischen SAP Knowhow der SAP Hosting.
In einem verschärften Wettbewerb benötigen Unternehmen alle Ressourcen, um sich auf ihre
Kernkompetenzen zu konzentrieren. Insbesondere in Zeiten immer komplexer werdender ITLandschaften ist es für Unternehmen sinnvoll, den Produktivbetrieb ihrer mySAP™ Business
Suite Lösungen einem kompetenten und spezialisierten Partner zu übertragen. Dafür bietet SAP
Hosting AG & Co. KG die Dienstleistung Application Hosting an. Mit SAP Application Hosting
können Infrastruktur-Investitionen reduziert, Ausbildungskosten für Personal gesenkt, und
neueste Technologie problemlos eingesetzt werden.
1.1.2.4 Remote Application Operation
Mit der Dienstleistung Remote Application Operation (RAO) überlässt der Kunde der SAP
Hosting AG & Co. KG die Verantwortung für den Betrieb seiner produktiven mySAP Business
Suite.
Für den Fall, dass das Sicherheitskonzept des Kunden den Betrieb der mySAP Business Suite in
dessen Rechenzentrum erfordert, bietet die SAP Hosting AG & Co. KG ihm die Dienstleistung
Remote Application Service. Das bedeutet, es wird ein störungsfreien Betrieb via RemoteAnbindung garantiert.
Über den weltweiten 7x24h Support ist jederzeit ein mit dem Kundensystem vertrauter
Ansprechpartner für diesen erreichbar.
1.1.2.5 Application Management
Mit der Dienstleistung Application Management greift der Kunde auf das erfahrene Personal
und die SAP-Expertise der SAP Hosting AG & Co. KG zu. Dieses kümmert sich darum, dass die
Kunden mySAP Business Suite Lösung anwendungsseitig reibungslos funktioniert. Die SAP
Hosting AG & Co. KG deckt damit die betriebswirtschaftliche Seite der mySAP Business Suite
Lösung ab und entlastet von Tätigkeiten, die innerhalb der Anwendung durchgeführt werden
müssen.
Der Kunde erhält:

Zugriff auf die mySAP Business Suite Kompetenz
5

Zugriff auf die mySAP Business Suite Experten

Klare und transparente Support-Struktur mit Second Level Support für seine Anwendung

Anwendungsseitige Unterstützung, Monitoring, Wartung, Pflege
Der Umfang der erforderlichen, anwendungsseitigen Tätigkeiten hängt von der mySAP Business
Suite Lösung ab, die beim Kunden im Einsatz ist oder die dieser plant einzusetzen.
Application Management wird für Systeme angeboten, die im SAP Hosting AG & Co. KG
Rechenzentrum stehen oder auch ‚remote' für Systeme im Rechenzentrum des Kunden.
Der Kunde profitiert außerdem vom direkten Draht in die SAP-Produktentwicklung. Damit wird
sicher gestellt, dass selbst neueste Erkenntnisse in den Produktivbetrieb des Kunden einfließen.
Application Management entlastet zu Festpreisen für die gewünschte Leistung von
krankheitsbedingten Ausfällen, Urlaubssituationen und sonstigen Planungsrisiken.
1.1.2.6 Upgrade Hosting
Mit Upgrade Hosting haben die Kunden die notwendigen Ressourcen zur Verfügung - genau für
den von ihnen benötigten Zeitraum.
Diese Möglichkeit ist insbesondere bei einem engen Upgrade-Zeitplan mit benötigter
Planungssicherheit oder bei mangelnder Erfahrung mit den neuen Technologien des neuen
Releases oder bei temporär zusätzlich benötigten Ressourcen sehr wertvoll.
Die SAP Hosting AG & Co. KG unterstützt Sie mit unterschiedlichen Dienstleistungen bei
Upgrades

Upgrade Hosting während des Upgrade-Projektes

Application Hosting für das produktive System nach dem Upgrade
1.1.2.7 Hosted Learning
E-Learning Services der SAP Hosting
Moderne E-Learning- oder Blended-Learning-Konzepte leisten einen wichtigen Beitrag, wenn es
darum geht, Mitarbeiter und Partner auf dem aktuellen Stand des Wissens zu halten.
Der Aufbau und die Betreuung der notwendigen technischen Infrastruktur sollte in der
Verwirklichung Lernkonzepte des Kunden nicht zum Stolperstein werden. SAP Hosting AG &
6
Co. KG bietet Services, die es ihm erlauben, sich voll auf die eigentlichen Inhalte und Prozesse
der Personalentwicklung mit E-Learning zu konzentrieren.
SAP Hosting AG & Co. KG bietet Kunden und Partnern die Möglichkeit, IDES Test- und
Demosysteme auf Mietbasis zu nutzen. Für Trainingszwecke liefert die SAP Hosting AG & Co.
KG im Rahmen von Bildungspartnerschaften und Angeboten der SAP Educational Services den
Zugang zu gehosteten IDES Trainingssystemen.
Auf diese Weise stellt die SAP Hosting AG & Co. KG einen kostengünstigen und professionellen
Zugang zu den aktuellen IDES-Szenarien des mySAP Business Suite Produktspektrums zur
Verfügung.
Installation und Betrieb von IDES-Landschaften der mySAP Business Suite erfordern know-how,
Zeit und Investitionen in die technische Infrastruktur - Ressourcen, die einem Unternehmen
sicher für andere Zwecke dringender gebraucht werden.
Mit dem Hosting von IDES-Systemen erschliesst die SAP Hosting AG & Co. KG eine neue
Option für die Bereitstellung von Demo- und Trainingslandschaften mit wesentlichen Vorteilen:
Der Kunde erhält schnell, kostengünstig und unkompliziert Zugang zu IDES-Landschaften, die
mit SAP-know-how aus erster Hand nach höchsten Standards betrieben werden. Damit eröffnen
sich neue Dimensionen an Qualität, kurzfristiger Verfügbarkeit und Kosteneinsparungen beim
Betrieb von Demo- und Trainingslandschaften.
SAP Learning Solution
Implementation Hosting
Die neue SAP Learning Solution wird durch den Implementation-Hosting-Service der SAP
Hosting AG & Co. KG für den Kunden innherhalb weniger Wochen als Plattform für dessen ELearning-Konzept verfügbar. Lange Vorlaufzeiten für die Hardwarebeschaffung, Einarbeitung
und Systemaufbau gehören der Vergangenheit an.
Technical Operations
7
Für die individuelle Lösung bieten bietet die SAP Hosting AG & Co. KG gemeinsam mit ihren
Partnern nach der Implementierung den produktiven Betrieb im Application Operations sowie
zusätzliche begleitende Dienste an.
Beratung
Integration in bestehende Prozesse
Die Integration einer Lernplattform in bestehende betriebliche Prozesse und Systemlandschaften
erfordert besonderes know-how. Neben der Applikationsberatung und technischen Beratung zur
SAP Learning Solution unterstützt die SAP Hosting AG & Co. KG ihre Kunden durch
qualifizierte Beratung und Projektmanagement an den Schnittstellen zu den Bereichen HR,
Billing, Portale, Web-Content-Management und mySAP Business Intelligence, sowie zur
Organisation des Betriebes auf funktionaler Ebene.
ASP - Plattform plus Inhalt
Eine wesentliche Aufgabe in der Umsetzung eines E-Learning oder Blended-Learning-Konzepts
ist die Beschaffung bzw. Produktion der Lerneinheiten. Das Ziel der SAP Hosting AG & Co. KG
ist es, für mySAP Business Suite Produkte ein ASP-Angebot zur Verfügung zu stellen, das neben
der Nutzung der SAP Learning Solution auch ein Set von modularen Lerneinheiten einschließt.
Diese können dann - z.B. im Rahmen eines SAP-Einführungsprojektes - direkt für den internen
Trainingsbedarf des Kunden genutzt werden oder als Basis für die Erstellung kundenspezifischer
Curricula dienen.
Durch die kombinierte Bereitstellung von Tools und Standardinhalten in einem ASP-Angebot
bietet die SAP Hosting AG & Co. KG dem Kunden eine schnell verfügbare Basis für sein ELearning-Projekt, die er in der Organisation seines internen Rollouts einen großen Schritt
vorwärts bringt.
Sonstiges
Nach Vereinbarung übernimmt die SAP Hosting AG & Co. KG auch Aufgaben des ContentManagements
oder
anderer
Dienstleistungen
Produktionsprozesses für E-Learning.
8
zur
Definition
und
Unterstützung
des
1.1.2.8 emaro
emaro steht für Kompetenz und Leistungsfähigkeit in der elektronischen Beschaffung.
emaro (Geschäftsbereich der SAP Hosting AG & Co. KG) bietet Lösungen zur elektronischen
Beschaffung von katalogbasierten Gütern und Dienstleistungen. Dabei übernimmt emaro den
Betrieb der Beschaffungsplattform, die Sicherstellung des Dokumentenaustausches sowie die
technische Integration der Systeme (Beschaffungs- wie ERP-Systeme). Dienstleistungen im
Katalogmanagement und Sourcing-Bereich runden das Leistungsportfolio ab.
Im Bereich Geschäftsreisemanagement bietet emaro eine innovative Lösung, die sämtliche im
Reiseprozess anfallenden Informationen sammelt und für spätere Prozessschritte (z.B.
Auswertungen) im geeigneten Format bereitstellt.
Im Einzelnen besteht das Produktportfolio der SAP Hosting AG & Co. KG im Bereich der
elektronischen Beschaffung aus:

emaro.integration
o Dokumentenaustausch
o Systemintegration

emaro.procure
o Hosting von eProcurement-Software
o Applikationsmanagement

emaro.catalog
o Katalogmanagement
o Kataloghosting

emaro.sourcing
o Lieferantenmanagement
o Ausschreibungen & Auktionen
9
1.2 Abteilung – GOS RST Technology & Infrastructure I
Die Abkürzung GOS RST steht für Global Operational Services - Regional Service Team
Dieser Gruppe gehören alle Mitarbeiter an, die
Beim Team Tools (engl. steht im Zusammenhang dieser Diplomarbeit für Anwendungen) handelt
sich um ein kleines „Zwei Mann Team“, welches Monitoring Anwendungen programmiert.
Während ein Kollege das sog. Alert Cockpit, einen Monitor auf R/3 Basis betreut und entwickelt,
ist mein Betreuer Andreas Mazzola mit der Entwicklung des Information Administration Centers
(im Folgenden IAC genannt) beschäftigt. Dieser Monitor basiert auf Microsoft SQL Server, ASP
und Perl. Genaueres zu diesem Tool, wird in 1.3 Aufgabenstellung berichtet.
1.3 Aufgabenstellung
Zur Verwaltung der gesamten Hardware, die die SAP Hosting AG & Co. KG durch die SAP
eigenen und Kundensysteme zu betreuen hat, gibt es ein Portal, das sog. IT Administration Portal
Abbildung 1.1 – IT Administration Portal
10
(vgl. Abbildung 1.1). Dort kann der Benutzer direkt Aktionen durchführen (vgl. orangener
Rahmen) oder hat die Möglichkeit, zu einer Vielzahl anderer Administrations- und Monitoring
Anwendungen zu gelangen (vgl. blauer Rahmen).
Dieses Portal ist während der Portierung des sog. IAC entstanden.
Das IAC ist eine Anwendung, die seit dem Jahr 2001 zur Verwaltung der
Hardware aufgebaut wurde. Zwischenzeitlich hatte das IAC Funktionalitäten
(vgl. Abbildung 1.2) wie das Pflegen aller möglichen zu einem Server
gehörenden Daten (IP Adresse, Equipment Nummer, Seriennummer,
Systemname, Hardware, Verrechnung/Fakturierung, System, Dateisystem,
Netzwerk, Backup, Dienste, Software, Verantwortlicher, Hotline, Adresse
und Rechenzentrumsplatz) oder das Herunterladen dieser Daten als Excel
Tabelle. Alle Server konnten auch nach bestimmten Daten durchsucht
werden. Außerdem prüfte und zeigte das IAC die Netzwerkerreichbarkeit
eines Servers an. Server unabhängige Daten (Standorte, technischer Support,
wichtigen Nachrichten, Hotline Listen, Hersteller, Vereinbarung der
Verfügbarkeitsgewährleistung,
Zustände,
Servertypen,
Kostenstellen,
Service Gruppen, Service Einheiten, Niederlassungen und Benutzern)
Abbildung 1.2 – wurden ebenfalls im IAC allerdings an separater Stelle gepflegt. Da das IAC
IAC Menü
selbst mit seiner aus immerhin sechs Servern bestehenden Systemlandschaft
auch verwaltet werden musste, gibt es Funktionen zur Benutzerverwaltung
(Berechtigungsvergabe), zum „Killen1“ der IAC Prozesse, zum Resetten2 und Rebooten3 der
einzelnen Server und zum Umverteilen der Serveraufgaben (Webserver, Applikationsserver,
Datenbankserver).
1
Killen: Beenden eines Prozesses
Resetten: hier: stoppen und wieder anstarten alle IAC Prozesse (nur softwaretechnisch)
3
Rebooten: herunter fahren und wieder hoch fahren, also restarten des Servers (hardwaretechnisch)
2
11
Zur damaligen Implementierung des IAC hatte man sich überwiegend für die Verwendung von
Microsoft Produkten entschieden und es mit MS Internet Information Server, MS SQL Server
2000 und ASP realisiert. Wenn ASP nicht genügend Funktionalität bot, griff man zu Perl.
Parallel zum IAC wurden jedoch noch andere ähnliche Tools auf verschiedenen Plattformen
entwickelt. So gibt es zum Beispiel einen Monitor, der speziell Datenbank Server verwaltet und
spezifische Datenbank Informationen wie den Festplattenplatz oder den Stand des Backups
ermittelt. Diese zahlreichen Tools hatten alle ihre eigene Datenbank mit nicht selten denselben
Daten wie sie schon auf einer anderen existierten. Als Notwendigkeit aus dieser Tatsache ergab
sich, dass alle Redundanzen durch den Aufbau einer völlig neuen Datenbank, die von allen Tools
genutzt würde, beseitigt würden. Da sich die Tools in ihren alten Versionen der verschiedensten
Technologien bedienten, musste sich zur Vereinheitlichung für dieselben Technologien
entschieden werden. Natürlich fiel die Wahl auf die SAP eigenen Technologien Web Application
Server (SAP Webserver), MaxDB (SAP Datenbank) und BSP (Business Server Pages, SAP
eigenes Framework für Webbasierte Anwendungen) unter dem Betriebssystem Linux.
Durch das Zusammenlegen aller Daten in eine Datenbank verloren die meisten Tools einen Teil
ihrer Verwaltungsaufgaben, so auch das IAC. Es verlor sogar alle Funktionen, die
hardwarespezifische Daten pflegten. Die Hauptaufgabe des IAC sollte zukünftig in der grafischen
Aufbereitung in anderen Tools gepflegter Daten und zum Teil automatisch selbst gesammelter
Daten (z.B. Scan nach vorhandenen Hotfixes) liegen. Eine außerdem wichtige Funktionalität
stellte die Suche innerhalb aller Daten dar.
All diese Anwendungen existieren zwar schon, laufen aber noch auf der alten Plattform. Die
Aufgabe meines Betreuers (Andreas Mazzola) und mir soll es sein, diese Anwendungen auf die
SAP Umgebung zu portieren. Dabei ist es sehr sinnvoll, sich zunächst einmal um Portierung
generell Gedanken zu machen, damit sie so effektiv wie möglich verläuft.
Ziel dieser Diplomarbeit ist also, ein Verfahren zur Portierung ASP basierter Webanwendungen
auf SAP® R/3® Technologien zu entwickeln und dieses dann anhand des praktischen Beispiels
anzuwenden und zu prüfen.
1.4 Verwandte Arbeiten
Bei der Literaturrecherche zeigt sich, dass es zum exakten Thema dieser Diplomarbeit keinerlei
Literatur gibt. Da der Schwerpunkt die Vorgehensweise an sich ohne ein tieferes Eingehen auf
12
die Technologien ist bzw. zu den Technologien selbst ausreichende Literatur vorhanden ist, kann
die Suche erweitert werden. So werden nun Bücher von Interesse, in denen auch nur ansatzweise
eine Anleitung zum Portieren gegeben werden könnte. Diese Suche ergab folgende Bücher.
1.4.1 Vorhandene Literatur

Martin C. Brown, (1998). BeOS: Porting UNIX Applications. San Francisco, Californien:
Morgan Kaufmann Publishers, Inc.

SunSoft Developer Engineering,.(1995). Solaris™ Porting Guide. 2.Auflage. SunSoft Press

Jens Ehme, (1997). Portierung einer in Standard C geschriebenen Windows 3.1x Anwendung
in eine objektorientierte C++ Anwendung unter Verwendung der Borland C++ OWL.
Diplomarbeit. Fachhochschule Stralsund

Andrew Lowe, (1997). Porting UNIX Applications to Windows NT. Indianapolis, Indiana:
Macmillan Technical Publishing

Steven Pemberton, (1992). The Ergonomics of Software Porting. Amsterdamm: Institut für
Informatik

Thomas Lauer, (1993). Die 32-Bit-Expedition: Win32™, Windows™ 4.0 und Windows NT™
– Leitfaden und Referenz zur Portierung von Windows 3.x Programmen. Springer-Verlag

Nancy Nicolaisen, (2002). Making Win32® Applications Mobile – Porting to Windows® CE.
Wiley Publishing, Inc.
1.4.2 Nutzbare Literatur
Die Bücher stellen größtenteils nur Hinweise bei der letztendlichen Portierung selbst dar, d.h. sie
bilden die verschiedensten Entsprechungen von vorher zu nacher ab. Lediglich die Bücher
Thomas Lauers und Andrew Lowe’s, gehen auch auf vorangestellte Themen wie Aufwand und
Vorgehensweisen bei der Portierung ein (s. 3.1).
13
2 Betrachtete Technologien
Diese Arbeit vertieft insbesondere die Portierung von einer Microsoft auf eine R/3® Plattform,
deswegen wird sich vor allem auf die dabei vorkommenden Technologien bezogen, so dass
Beispiele immer anhand dieser dargestellt werden. Es wird eine theoretisch sinnvolle Abfolge
von Arbeitsschritten entwickelt, die über die Analyse des Ist-Zustandes zur Synthese des SollZustandes führt. Die mit Microsoft Produkten umgesetzte Ausgangsanwendung stellt also den
Ist-Zustand dar, während die Zielanwendung in R/3® der Soll-Zustand nach der Portierung ist.
Als Vorbereitung auf dieses im nächsten Kapitel entstehende Verfahren wird in diesem Kapitel
zunächst eine Einführung in die betrachteten Technologien gegeben.
2.1 Ausgangsplattform
Die Plattform der Ausgangsanwendung setzt vollkommen auf Microsoft® Produkte. So wird als
Webserver der Internet Information Server und als Datenbank der SQL Server 2000 genutzt.
Beide laufen auf einem Windows® Betriebssystem. Die Webanwendungen sind mit ASP
umgesetzt.
2.1.1 Microsoft SQL Server
ODBC! ODBC anlegen
2.1.2 Microsoft Internet Information Server
2.1.3 Active Server Pages
2.2 Zielplattform
Zusammenhang: Auseinandersetzen und Vorstellen der Zieltechnologien; für den weiteren
Verlauf der Arbeit wichtiges technisches Wissen an den Leser vermitteln
Webserver und Datenbank bilden gemeinsam mit dem Webbrowser eine dreischichtige
Architektur (vgl. Abbildung 2.1), da sie jeweils auf verschiedenen Rechnern laufen. In dieser
dreischichtigen Architektur werden Anfragen des Benutzers über den Webbrowser an den
Webserver weitergeleitet. Der Webserver verarbeitet diese Anfragen, besorgt oder bearbeitet falls
14
nötig Daten des Datenbankservers und gibt das Ergebnis als Webseite wieder an den Webbrowser
des Benutzers zurück.
Inhalt: R/3!!!
2.2.1 MaxDB
Mit MaxDB hat die SAP AG ein eigenes Datenbanksystem entwickelt, dass seit dem Jahr 2000
auch quelloffen ist. Aktuell läuft es in der Version 7.4. MaxDB bietet für unterschiedliche
Anforderungen verschiedene Datenbankinstanztypen. Der grundlegende Instanztyp heißt MaxDB
OLTP (Online Transaction Processing) und ist für die schnelle Bearbeitung einzelner
Transaktionen mit einer hohen Anzahl von Benutzern und großen Datenbanken optimiert. Für
große Datenmengen, die ständig erreichbar und änderbar sind steht der Instanztyp SAP liveCache
zur Verfügung, der objektorientiert arbeitet und ausschließlich im Hauptspeicher des
Datenbanksystems operiert. Zur Verarbeitung möglichst vieler unstrukturierter Daten wie Videos,
XML-Dateien u.v.a. außerhalb der OLTP-Datenbank existiert die Datenbankinstanz MaxDB
Document Server, diese ist besonders performant. Um große Mengen betriebswirtschaftlich
historischer und operativer Daten schnell auf zu bereiten, wurde MaxDB OLAP entwickelt.
Speziell für Internet Kataloge wurde MaxDB OLTP um die TREX-Suchmaschine4 erweitert und
MaxDB E-Catalog entstand. So können Produktbeschreibungen (Langtexte) indiziert und
anschließend effizient
durchsucht
werden
(exakte Suche,
Phrasensuche,
Fuzzysuche,
linguistische Suche).
Datenbankbearbeitung
Neuer Eintrag
Vorhandenen Eintrag updaten
Eintrag löschen
4
TREX-Suchmaschine: SAP eigene Entwicklung einer Suchmaschine
15
2.2.2 SAP® Web Application Server
„Web Application Server dienen als Plattform für die Veröffentlichung und das Management von
Unternehmensanwendungen
im
Internet
und
gelten
als
Schlüsseltechnologie
der
Informationsverarbeitung im E-Business-Zeitalter.“ (SAP® Web Application Server, SAP® Press
2003, S.16)
Die Web Application Server (im Folgenden Web AS genannt) sind Software, die das Entwickeln
und Betreiben von Webanwendungen insbesondere für Business Server Pages (BSPs)
ermöglichen. Mit diesen Entwicklungen sollte den heutigen Anforderungen an geschäftskritische
Webanwendungen im Bezug auf Aktualität, Interaktivität, Individualität, Schnelligkeit und
Hochverfügbarkeit gerecht werden.
SAP® hat mit seinem SAP® Web Application Server einen eigenen Web AS entwickelt. Auch
IBM ist mit seinem WebSphere und BEA mit WebLogic auf dem Markt vertreten.
Mit den SAP® Web AS hat sich die SAP für die 3-Schichten-Architektur entschieden.
Konnektivitätsschicht
Webserver
Internet Communication Manager (HTTP/HTTPS/SMTP/SOAP/WebDAV)
Präsentationsschicht



1.Schicht
Webbrowser
(•
•
Integrationsschicht
Präsentationslogik
Navigation
Interaktion mit Client
Integrationstools
JSP/Servlets/JSP Tag-Bibliotheken
BSP/BSP Extensions
)
2.Schicht
Webserver
Business-Schicht
Applikationsserver



3.Schicht
Datenbankserver
(
Business-Logik
Statusverwaltung
Interaktion mit Datenbank und
externen Ressourcen
J2EE/ABAP
( • Java Connector
• .NET Connector
• XML/XSLT
• SOAP
• WSDL-Proxies
• BAPI/RFC
• IDoc
•…
)
)
Persistenzschicht
Datenbankschnittstelle
(
JDBC/Open SQL
)
SAP® Web Application Server
16
Abbildung 2.1 – Einordnung des Web AS in die 3-Schichten-Architektur, Architektur und mögliche
Technologien (kursiv geschrieben) des SAP® Web AS selbst
Diese Architektur verfolgt den Grundsatz, Anwendungsoberfläche (vgl. Abbildung 2.1:
1.Schicht), Anwendungslogik (vgl. Abbildung 2.1: 2.Schicht) und Anwendungsdaten (vgl.
Abbildung 2.1: 3.Schicht) klar voneinander zu trennen, was eine ihr entsprechende Anwendung
abstrakter, skalierbarer, zuverlässiger und einfacher erweiterbar macht. Die 1.Schicht wird
Client-Schicht genannt, die 2. Applikationsschicht und die 3. Datenbankschicht. Nach dem
Client-Server-Prinzip, nutzen diese drei Schichten Dienste der jeweils darunter liegenden Schicht
und bieten der darüber liegenden Dienste an.
Die Client-Schicht ist die grafische Benutzerschnittstelle, im Webumfeld der Webbrowser. In der
Datenbankschicht liegen auf dem Datenbankserver alle notwendigen Daten.
Der SAP® Web AS stellt in der 3-Schichten-Architektur die Applikationsschicht dar.
Mit dem Internet Communication Manager (ICM) als Konnektivitätsschicht wird auf TCP/IP5
Basis mit Hilfe der unterstützten Protokolle HTTP6, SMTP7 u.a. die Kommunikation mit der
Außenwelt gewährleistet. In der Präsentationsschicht wird mit HTML Seiten die Schnittstelle
zum Benutzer erzeugt. Hier bekommt der Benutzer Informationen angezeigt (Texte, Grafiken,
Datenbankinhalte usw.) und kann Daten (Eingabe-/ Auswahlfelder) zurück geben. Gesteuert
werden dynamische Daten wie Datenbankinhalte von der Business-Schicht, welche z.B. vom
Benutzer eingegebene Daten verarbeitet und die Ergebnisse, wenn nötig, wieder an die
Präsentationsschicht zurück gibt, wo dann mit ihnen neue HTML Seiten generiert werden.
„Die Integrationsschicht gewährleistet die Kommunikation mit einer Vielzahl unterschiedlicher
Systeme und Anwendungen. Der SAP Web AS bietet alle notwendigen Mechanismen, um die
SAP-Welt (z.B. RFC8, BAPI9, IDoc10) und auch die Non-SAP-Welt über eine Vielzahl von
5
TCP/IP: Transmission Control Protocol/Internet Protocol: Softwareprotokoll, das die Kommunikation zwischen
Rechnern definiert
6
HTTP: HyperText Transfer Protocol: Protokoll zwischen Webserver und Webclient
7
SMTP: Simple Mail Transfer Protocol: Protokoll zum Senden und Empfangen von Mails
8
RFC: Remote Function Call: zum Aufruf vordefinierter Funktionen auf entferntem oder gleichem System
17
Konnektoren (z.B. Java- und .NET-Konnektoren) zu verbinden. Der SAP Web AS unterstützt die
Webservice-Technologie (durch ein eigenes SOAP11-Framework) und unterstützt eine Vielzahl
von Dokumentenstandards (insbesondere XML12).“(SAP® Web Application Server, SAP® Press
2003, S.30f)
Die Persistenzschicht sorgt für die Anbindung an verschiedene Datenbanksysteme. Mit der Open
SQL Schnittstelle können verschiedene von der SAP lizenzierte Datenbanken angebunden
werden und mit JDBC andere.
2.2.3 Business Server Pages
Die Benutzeroberfläche (vgl. Abbildung 2.1 Präsentationsschicht) wird mit Business Server
Pages (BSP) realisiert. BSP-Seiten sind ähnlich wie ASP-Seiten Seiten, die zur Darstellung ihrer
Inhalte HTML verwenden und durch eine Skriptsprache befähigt werden, Datenbankzugriffe
vorzunehmen. Im Fall der BSPs kann man neben J2EE13 die SAP eigenen Programmiersprache
ABAP14 als serverseitige Skriptsprache benutzen. Und um bei der Entwicklung von
Anwendungen einheitliche Funktionalitäten und einheitliches Design zu gewährleisten, soll sich
gemäß der Entwicklungsrichtlinien15 sog. BSP-Extensions bedient werden, welche eine
Abstraktionstechnik zur Vereinfachung der Syntax und Semantik von HTML-Codeblöcken
darstellen. Mit Hilfe von BSP-Extensions können also z.B. alle möglichen HTML Elemente in
Farbe, Form und Funktionalität vor eingestellt werden (Bsp.: checkbox) oder besondere Elemente
(Bsp.: tray) geschaffen werden. Der SAP WebAS wird beispielsweise mit der vordefinierten
Extension HTML Business (HTMLB) ausgeliefert. Beim Verwenden solcher Extensions macht
man im HTML Dokument den Namen der Extension zunächst mit <%@extension name="htmlb"
9
BAPI: Business Application Programming Interface: Schnittstelle für den Zugriff auf betriebswirtschaftliche
Objekte eines SAP-Systems
10
IDoc: Intermediate Document: SAP-Standardformat zum elektronischen Datenaustausch zwischen Systemen.
Verschiedene Nachrichtentypen (z.B. Lieferschein oder Bestellung) entsprechen in der Regel verschiedenen
speziellen Formaten, den sogenannten IDOC-Typen.
11 SOAP: Simple Object Access Protocol: zum Aufrufen von Webservices in verteilten Landschaften mit Hilfe des
Transportprotokolls HTTP
12
XML: eXtensible Markup Language: Auszeichnungssprache zur Definition von Dokumentstrukturen
13
J2EE: Java 2 Platform, Enterprise Edition
14
ABAP: Advanced Business Application Programming: objektorientierte Hochsprache
15
Richtlinien für BSP Anwendungen: 1) nur HTMLB Erweiterungen verwenden 2) das von BSP angebotene ModelView-Controller Programmiermodell verwenden 3) Ablauf(=business?)- und Präsentationslogik klar voneinander
trennen
18
prefix="htmlb" %>
bekannt, und leitet dann jedes zur Extension gehörende Element nach dem
Prinzip <htmlb:Elementname> ein.
Eine BSP Datei ist genau wie der WebAS selbst in einer 3 Schichten Architektur gehalten. Es
gibt Präsentations-, Ablauf- und Anwendungslogik. Während diese Architektur lange Zeit mit
sog. Eventhandler16-Methoden innerhalb einer Seite mit Ablauflogik umgesetzt wurde,
empfehlen neuste Richtlinien15 die Verwendung des MVC (Model-View-Controller) Design
Patterns. Dabei wird die Präsentation der BSP Anwendung streng getrennt vom Rest in Views
definiert. Die Ablaufsteuerung wird von sog. Controllern vorgenommen. Dabei sind Controller
Klassen, welche die Verbindung zwischen View und Model realisieren, indem sie Eingabedaten
des Benutzers über den View entgegen nehmen, an das Model weiterleiten und somit dort durch
Methodenaufrufe Änderungen an den Daten auslösen. Die Anwendungslogik wird folglich vom
Model übernommen, dieses stellt die der Anwendung zugrunde liegenden Daten dar und bietet
Methoden zu Datenbeschaffung und -verarbeitung. Das Model kennt seine Views und Controller
nicht.
2.2.4 Entwicklungsumgebung
Transaktionen bezeichnen in einem SAP® R/3® System abgeschlossene Vorgänge, die aus
betriebswirtschaftlich, funktional und logisch zusammenhängenden Arbeitsschritten bestehen.
Aus Anwendersicht könnte solch eine Transaktion z.B. das Ändern von Kundendaten sein. Für
Anwendungsentwickler gibt es die Transaktion „Object Navigator“, welche entweder über die
Navigation im SAP Easy Access, der Einstiegsoberfläche alle SAP Systeme, angesteuert werden
kann
16
19
Abbildung 2.2 – SAP Easy Access, gesamte Oberfläche
oder durch direkte Eingabe ihres zugehörigen Transaktionscodes 17 in der Kommandoeingabe der
Symbolfunktionsleiste.
Abbildung 2.3 – SAP Easy Access, Symbolfunktionsleiste
Bei der direkten Eingabe muss dem Transaktionscode (hier: SE80) selbst /n oder /o vorangestellt
werden. Dabei bewirkt /n, dass die im verwendeten Fenster aktuell laufende Transaktion
abgebrochen und die neu angegebene gestartet wird. Im Gegensatz dazu wird bei /o die neue
Transaktion in einem neu öffnenden Fenster gestartet.
Der
Object
Navigator
(SE80)
ist
für
R/3®
Softwareentwickler
das
umfassende
Verwaltungswerkzeug. Seine grafische Oberfläche besteht aus fünf Bereichen (vgl. Abbildung
2.4).
17
Transaktionscode: eindeutiges Kürzel für eine R/3 Transaktion, das aus vier alphanumerischen Zeichen besteht
20
1.1
1.2
1.3
1.4
2
4
3
5
Abbildung 2.4 – Object Navigator
Die Bereiche 1.1 bis 1.4 stellen die Funktionsleisten dar, welche in ähnlicher Weise in jeder SAP
R/3 Oberfläche vorkommen, sich jedoch vorwiegend auf Funktionen des Aktuellen Werkzeugs
im Werkzeugbereich (vgl. Abbildung 2.4 Punkt 4) beziehen. Die Menüleiste (vgl. Abbildung 2.4
Punkt 1.1) zeigt von der jeweiligen Anwendung abhängige Menüs (z.B. Bearbeiten, Hilfsmittel,
System) und bietet deren Unterpunkte an. Die Symbolfunktionsleiste (vgl. Abbildung 2.4 Punkt
1.2) ist bei jeder Anwendung identisch und beinhaltet die bereits erwähnte Kommandozeile zur
Eingabe von Transaktionscodes (s. oben) sowie Symbole (vgl. Abbildung 2.3 von links nach
rechts) zum Ausführen, Speichern, zurück Springen, Verlassen, Abbrechen, Drucken, Suchen,
Finden, Finden des nächsten Gleichen, zum Blättern auf die erste Seite, auf die vorherige Seite,
auf die folgende Seite und auf die letzte Seite, zum Öffnen einer neuen Session 18, zum Erzeugen
18
Session: hier: weiteres Fenster mit gleicher Anwendung
21
eines Shortcuts19 auf dem Desktop20, zur Hilfe und schließlich zum individuellen Anpassen der
Oberfläche. Die Titelleiste (vgl. Abbildung 2.4 Punkt 1.3) benennt lediglich die Anwendung/das
Werkzeug bzw. die Funktion, die momentan im Werkzeugbereich (vgl. Abbildung 2.4 Punkt 3)
zur Verfügung steht. Die Anwendungsfunktionsleiste (vgl. Abbildung 2.4 Punkt 1.4) bietet
Funktionen der aktuellen Anwendung an.
Der Browserbereich (vgl. Abbildung 2.4 Punkt 2) vereinigt verschiedene Browser, mit denen
MIME-Objekte (Bilder, Symbole, Sounds, Stylesheets, u.v.a.) und Entwicklungsobjekte
(Repository-Objekte wie z.B. ein entwickeltes Paket mit allen Klassen, Webseiten und
Datenbanktabellen) verwaltet und durchsucht werden können. Außerdem bietet der Repository
Information System Browser die Möglichkeit, in alle Arten von Entwicklungsobjekten nach
bestimmten Objekten z.B. über ihren Namen, ihre Beschreibung oder ihr Paket zu suchen. Der
Tag Browser gibt dem Entwickler eine Übersicht und Informationen zu allen verfügbaren Tags
für Webanwendungen. Schließlich gibt es noch den Transport Organizer bei den Browsern, in
ihm kann man auf die eigenen Transportaufträge zugreifen.
In der Objektliste (vgl. Abbildung 2.4 Punkt 3) kann dann schließlich in Form einer Baumanzeige
auf Objekte der gewählten Kategorie zugegriffen werden.
Wählt der Entwickler in der Objektliste ein Objekt aus, erscheint es automatisch mit dem
entsprechenden Werkzeug zur Bearbeitung im Werkzeugbereich (vgl. Abbildung 2.4 Punkt 4). In
diesem
Automatismus
zeigt
sich,
warum
der
Object
Navigator
die
umfassende
Entwicklungsanwendung ist. Der Entwickler muss nämlich nicht explizit zu den einzelnen
Werkzeugen springen. Der Wechsel des Werkzeugs zeigt sich also nur im Werkzeugbereich, in
den Unterpunkten der Menüleiste, in der Symbolfunktionsleiste in der Titelleiste und in der
Anwendungsfunktionsleiste, wobei diese Wechsel beiläufig vom Benutzer fast unbemerkt
ablaufen.
Abgeschlossen wird das Fenster unten durch die Statusleiste, welche links Hinweise, Warnungen
und Fehler ausgibt und rechts aktuelle Informationen zum System liefert, wobei hier die Art der
19
20
Shortcut: hier: direkter Einstieg zu dieser Anwendung
Desktop: Hintergrund des Bildschirms
22
Systeminformation ausgewählt werden kann, z.B. Systemname, Transaktionscode, Antwortzeit,
u.v.a..
Da v.a. in einem R/3 System mit ständiger Entwicklung sehr viele Änderungen vorgenommen
werden, empfiehlt es sich, das System nicht nur als Einzelinstanz zu betreiben, sondern
Integrations-, Konsolidierungs- und Belieferungssystem (vereinfacht Entwicklungs-, Test- und
Produktivsystem genannt) voneinander zu trennen. Dies hat die Vorteile, dass:

Änderungen an Entwicklungsobjekten sich nicht auf das Belieferungssystem auswirken.
Würde nämlich ein Entwickler eine Anwendung ändern, stünde diese den Anwendern
währenddessen nicht zur Verfügung. Ginge bei der Änderung etwas schief, so dass die
Anwendung nicht mehr korrekt arbeitet, könnte sie erst wieder nach der Fehlerbehebung
benutzt
werden.
Dialog-Workprozess? (r/3 systemadministration s.101 punkt 3)

Entwickler, die auf jeden Fall Zugriff auf alle Daten in den Datenbanktabellen brauchen,
keine produktiven und somit wichtigen Daten zerstören können.
So kann also einzig und alleine im Integrationssystem entwickelt werden, bis eine Anwendung
fehlerfrei läuft. Rein theoretisch könnte die funktionierende Anwendung nun auf das
Belieferungssystem übertragen werden, was durch sog. Transporte geschieht. Da jedoch die
transportierte Anwendung noch einmal getestet werden sollte oder vielleicht nur der
Zwischenstand einer Anwendung getestet werden soll, während an dieser längst weiter entwickelt
wird (bei größeren Projekten mit mehreren Entwicklern), wird ein weiteres System zwischen den
beiden benötigt, das Konsolidierungssystem, das der Qualitätssicherung dient (vgl. Abbildung
2.5).
Entwicklung
Integrations-system
Konsolidierungs-
Qualitäts-
Belieferungs-
weg
sicherung
weg
Produktion
Konsolidierungs-
Belieferungs-
system
system
Abbildung 2.5 – R/3 Systemlandschaft mit 3 Instanzen
23
Das hinter dieser Landschaft stehende Transportsystem tangiert den Entwickler insofern, dass
jedes Entwicklungsobjekt im Integrationssystem einen Transportauftrag erhalten muss oder
einem bereits existierenden hinzugefügt wird. Sobald ein Objekt das erste Mal gesichert wird
oder implizit gesichert werden muss (z.B. beim Wechsel zu einem anderen Objekt oder bei der
Kompilierung), kommt die Abfrage nach dem Transportauftrag (vgl. Abbildung 2.6).
Abbildung 2.6 – Abfrage nach Transportauftrag
Hier können über den „Eigene Aufträge“ Knopf oder das
Symbol alle zum eigenen Benutzer
gehörenden Transportaufträge aufgelistet werden, so dass das neue Objekt einem dieser
hinzugefügt werden kann. Sollte das neue Objekt jedoch zu keinem bestehenden Transportauftrag
passen oder noch gar keiner existieren, wird über das
Symbol ein neuer angelegt (vgl.
Abbildung 2.7).
Abbildung 2.7 – Erstellung eines Transportauftrags
An dieser Stelle ist zur erwähnen, dass es keine allgemeine Vorschrift gibt, wie die Organisation
von Transportaufträgen zu handhaben ist. Es ist auf jeden Fall davon abzuraten, alle Objekte in
den gleichen zu packen, da es bei der Parallelentwicklung verschiedener Bausteine zu
24
Behinderungen kommen kann, wenn nicht kompilierbare Teile im Transportauftrag enthalten
sind und somit der gesamte Transport nicht statt finden kann. Andererseits ist es unnötig, jedem
Objekt einen eigenen Transportauftrag zuzuweisen. Zum einen wird es für den Entwickler sehr
arbeitsaufwendig, wenn er dann jeden Transportauftrag einzeln aus dem Integrationssystem
exportieren und in Konsolidierungs- und Belieferungssystem importieren muss und zum anderen
leidet die Performance der beteiligten Systeme unter den vielen kleinen Transporten.
Es ist daher sinnvoll, logisch zueinander gehörende Objekte, d.h. Objekte, die ohne einander
nicht funktionieren (z.B. Views mit ihren Controllern und Models) in einem Transportauftrag
zusammen zu fassen.
Sind alle Objekte eines Transportauftrags
im Integrationssystem fertig entwickelt und
somit soweit, exportiert zu werden, ist dies
auf mehrere Arten möglich. Im Transport
Organizer des Objekt Navigators (vgl.
Abbildung
2.4
Transportauftrag
Transport
frei
Punkt
per
2),
kann
Rechtsklick
gegeben
werden
ein
zum
(vgl.
Abbildung 2.8).
Abbildung 2.8 – SE80 Freigabe eines Transportauftrags
Etwas umständlicher aber auch möglich ist der direkte Aufruf des Transport Organizers als
Transaktion SE09 oder sogar als SE01 mit erweiterter Sicht.
25
Abbildung 2.9 – STMS Liste aller Transportaufträge zum Import
Für einen Entwickler reicht jedoch die Version innerhalb des Object Navigators vollkommen aus.
Auf jeden Fall ist es beim Freigeben eines Transportauftrags so, dass unter dem eigentlich vom
Entwickler selbst angelegten noch automatisch untergeordnete Transportaufträge angelegt
wurden. So entsteht im Transport Organizer ein Baum mit dem ursprünglich händisch angelegten
Auftrag als Hauptknoten in der ersten Hierarchieebene. Bevor dieser freigegeben werden kann,
müssen alle Aufträge unter ihm freigeben werden, sein gesamter Teilbaum zur Freigabe also von
unten her abgearbeitet werden. Mit diesem Export liegt der Transportauftrag dann in einem
Exportverzeichnis, auf das sowohl Konsolidierungs- als auch Belieferungssystem zugreifen
können. Zunächst wird der Transportauftrag jedoch nur zur Qualitätssicherung ins
Konsolidierungssystem importiert. Dazu muss man sich natürlich zunächst in diesem anmelden.
Leider steht dann im Transport Organizer keine Funktionalität zum Import zur Verfügung. Zum
Importieren gibt es einzig und alleine die Transaktion STMS, das Transport Management System.
Dort gelangt man auf der Einstiegsseite über das
Symbol in der Anwendungsfunktionsleiste
(vgl. Abbildung 2.4 Punkt 1.4) zur Anzeige aller zum Import bereit stehenden Transportaufträge
(vgl. Abbildung 2.9).
Es kann zwar eine Verzögerung auftreten, bis ein bereits exportierter Auftrag hier aufgeführt
wird, aber wenn er dann zum Import bereit steht, wird er in der Statusspalte (vgl. Abbildung 2.9
Spalte „St“) mit dem
Symbol angezeigt. In diesem Zustand kann der Auftrag importiert
werden, indem man ihn markiert und auf das Symbol
für Einzelimporte klickt (vgl. Abbildung
2.9). Da in der Importliste die Aufträge aller Entwickler der Systemlandschaft aufgelistet sind,
sollte auf keinen Fall der Import aller Transportaufträge mittels
Symbol vorgenommen
werden!
Beim Vornehmen des Einzelimports erscheint als nächstes das wie in Abbildung 2.10 gezeigte
Fenster. Hier sollte nur unter Optionen der standardmäßig gesetzte Haken der ersten Option
entfernt werden, damit der Import sofort ausgeführt wird. Während des Imports wird der Status
des Auftrags in der Liste aller Importe mit
angezeigt.
26
angezeigt und bei erfolgreicher Beendigung mit
Abbildung 2.10 – STMS Import eines Transportauftrags
Die transportierten Objekte stehen nun im Konsolidierungssystem zur Verfügung. Dort können
sie getestet werden. Treten bei den Tests Probleme oder Fehler auf, müssen diese wieder im
Integrationssystem behoben werden. Da der bisherige Transportauftrag durch seinen Export dort
nicht mehr existiert, muss ein neuer angelegt werden. Erst wenn alle Tests positiv verlaufen und
die Anwendung komplett ist, so dass sie in den produktiven Betrieb genommen zu werden, wird
der Exportauftrag, der bisher nur ins Konsolidierungssystem importiert wurde, auch ins
Belieferungssystem importiert.
Was geschieht mit den aufträgen im exportverzeichnis? Stehen im belieferungssystem dann alle
exporte zum import zur verfügung, die es bis zum erfolgreichen testen gab?
27
3 Portierungsverfahren
3.1 Allgemeines zu Portierung
Inhalt: Definition Portierung:
Software porting is the engineering process of transforming an existing application so that the
resulting software will execute properly on a new platform. The process involves the careful
analysis, build, debug and test of the existing software to make sure that it will run reliably on the
target. (http://www.rtr.com/Ready-to-Run_Software/software_porting_primer.htm)
Software porting is the engineering process that transforms software so that it will
operate
within
a
new
target
environment.
(http://www.reed-
electronics.com/ednmag/article/CA236414?pubdate=8%2F8%2F2002)
Wann kann Portierung notwendig werden, wann ist sie zu empfehlen?
3.1.1 Aufwand
Der Aufwand, der hinter einer Portierung steckt, läßt sich leider nicht genau voraussagen.
Während Thomas Lauer die Aufwandsschätzung sehr wage festlegt, liefert Andrew Lowe jedoch
eine umfangreiche Rechnung. Lowe’s Rechnung bezieht sich allerdings auf die Portierung von
UNIX® zu Windows NT®. Außerdem würde es den zeitlichen Rahmen dieser Arbeit sprengen zu
prüfen, ob sich die Rechnung auf die hier bevorstehende Portierung übertragen oder zumindest
abwandeln ließe. Gleicher Meinung sind beide Autoren in dem Punkt, dass oberflächenintensive
Programme aufwendiger als rechenintensive oder algorithmisch komplexe Programme seien, da
eine einfache und intuitive Bedienung in der Oberfläche meist eine komplexe Weiterverarbeitung
der eingegebenen Daten nach sich zöge.
Nach Lauer beeinflussten Faktoren wie Zeitdruck, Design Änderungen, Faulheit, Schlampigkeit,
mangelnde Informationen, Desinteresse u.v.a. den existierenden Quellcode in seiner
Strukturierung oft negativ. Die Erfahrung zeige, dass Dauer und Aufwand einer Portierung
mindestens logarithmisch, in schweren Fällen auch quadratisch vom Chaos-Koeffizienten der
Quelltexte abhingen.
Folgende Regeln und Hinweise ließen den zu erwartenden Aufwand wenigstens relativ
abschätzen:
28
Stark modularisierte Quelltexte ließen sich besser schrittweise übertragen, da sie durch die
größere Übersichtlichkeit auch verständlicher seien und Fehler besser gefunden werden könnten.
Ausführlich kommentierte Quelltexte seien i.d.R. schneller und besser zu verstehen, könnten also
schneller portiert werden.
Während die oberen beiden Punkte Regeln zum besseren Verstehen beinhalten, ist mit diesem
das Verstehen generell gemeint. Je besser das Programm verstanden würde, desto schneller ginge
die Portierung vonstatten. Der Weg zum kompletten Verstehen wiederum kann natürlich eine
gewisse Zeit in Anspruch nehmen.
3.1.2 Vorgehensweisen
In der Art, wie man eine Anwendung mit all ihren Funktionalitäten portiert, unterscheidet man
hauptsächlich zwei grundlegend gegensätzliche Methoden, Bottom Up und Top Down.
3.1.2.1 Top Down
Abbildung 3.1 – Top Down
Start
Top Down bedeutet (laut Thomas Lauer), dass zuerst
ein funktionierendes Minimalprogramm umgesetzt
wird. Nach und nach werden dann die Funktionalitäten
hinzugefügt.
Der
entscheidende
Vorteil
dieser
Vorgehensweise liegt darin, dass mit dem Testen nach
jeder hinzugekommen Funktionalität auftretende Fehler
sehr gut aufgespürt werden können, die Anpassung
findet kontrolliert statt, zukünftig auftretende Fehler
können kaum auf bereits erfolgreich getestete Teile
Ziel
zurückgeführt werden. Der Programmierer kann sich
mit dieser schritt weisen, dem menschlichen Denken
entsprechenden, Taktik immer auf einen einzigen
Programmteil
konzentrieren,
was
die
Ziel
Fehlerrate
verringert. Des weiteren hat Top Down einen
psychologischen Vorteil - der Programmierer hat von
Anfang an ein sichtbares Resultat. Jede neu eingebaute
29
Start
Funktionalität, jeder erfolgreiche Test motiviert zum Weitermachen. Bei umfangreichen
Projekten kann ein Team von Entwicklern nach Portierung des Hauptprogramms mit all seinen
Schnittstellen relativ unabhängig voneinander portieren und testen. Top Down läßt sich mit
zunehmender Modularisierung des Quelltextes besser durchführen und fördert unabhängig davon
die Modularisierung der Zielanwendung.
3.1.2.2 Bottom Up
Abbildung 3.2 – Bottom Up
Bei Bottom Up werden zunächst einzelne kleinste Funktionalitäten bis zur fehlerfreien Arbeit
portiert. Danach werden diese kleinen Teile zur nächst höheren Einheit mit deren eventuellen
Zusätzen zusammengefasst, welche wiederum bis zum Erfolg getestet werden. So geht es immer
weiter, bis am Ende die komplette Anwendung funktionstüchtig portiert ist.
Bei dieser Methode liegen die Vorteile darin, dass mit den betroffenen Technologien erfahrene
Entwickler wiederkehrende Code-Muster in den Quelltexten besser als mit Top Down erkennen.
Bei größeren Projekten kann der „mechanische“ Teil der Portierungsarbeit, das sture Ändern von
immer wieder ähnlichen Code-Sequenzen, unter der Regie von erfahreneren Entwicklern durch
relativ unerfahrene Programmierer vorgenommen werden. Das Testen übernehmen dann wieder
die Entwickler, die den Code entworfen und implementiert haben.
30
3.2 Portierungsschrit 1/6: Kennen lernen der Ausgangsanwendung
Am Anfang der Portierung muss als erstes die Ausgangsanwendung genaustens kennen gelernt
werden. Dabei scheint es sinnvoll, sich vom Groben ins Detail ein zu arbeiten. Die bloße
Betrachtung der Anwendung als normaler Benutzer bringt einem zunächst den Überblick über die
Funktionalitäten der Anwendung, man sieht, aus welchen Elementen die Oberfläche besteht und
kann einigermaßen einsehen, welche Verarbeitungsschritte ablaufen. Außerdem gewinnt man
einen Einblick in den Seitenumfang und das Seitenzusammenspiel der Anwendung. Da jedoch
bei dieser oberflächlichen Betrachtung kleine Feinheiten leicht übersehen werden können, ist eine
noch genauere Betrachtung ratsam. Das Lesen des hinter der Anwendung stehenden Codes ist
sogar unausweichlich, da nur so jede noch so unscheinbare Funktionalität, die beim Betrachten
gar nicht wahr genommen wird, aufgespürt werden kann.
Ein weiterer Vorteil des genauen kennen Lernens der Ausgangsanwendung durch Lesen des
Codes
besteht
darin,
dass
so
zumindest
die
verwendeten
Funktionalitäten
der
Ausgangstechnologien bekannt und somit die gesamte Anwendung besser verständlich werden.
Erfahrungsgemäß kann eine 100%ige Kenntnis der Ausgangstechnologien nämlich nicht
vorausgesetzt werden.
31
3.3 Portierungsschrit 2/6: Machbarkeitsprüfung
Nachdem man sich mit der Ausgangsanwendung in soweit bekannt gemacht hat, dass man alle
verwendeten Komponenten kennen gelernt hat, ist es notwendig, zu überprüfen, ob sie
problemlos zur gewünschten Zielplattform portiert werden kann, welchen Anforderungen diese
also werden muss. Dieser Schritt ist hier am besten angesiedelt, da vorher noch nicht bekannt
war, was überhaupt nötig ist und da jeder weitere Schritt umsonst sein könnte, solange die
Machbarkeit nicht sichergestellt ist. Die Machbarkeit der Portierung soll hier also festgestellt
werden, um ein Scheitern so frühzeitig wie möglich zu erkennen und durch Verwerfen der
Portierung zu vermeiden.
3.3.1 Datentypen der Programmiersprache
Zunächst müssen die Datentypen der beiden Plattformen verglichen werden, um heraus zu
finden, ob die Portierung auf Ebene der notwendigen Datentypen problemlos oder wenigstens mit
etwas Umstand möglich ist.
Im Falle von JavaScript und ABAP sieht die Gegenüberstellung der Datentypen folgendermaßen
aus.
JavaScript
ABAP
elementare Datentypen fester Länge
32
Typ
Standard-/
Größe
[Byte]
Initialwert
Erläuterung
i
4/ 4
0
Integer, ganze Zahl
p
8/ 1-16
0
Packed, gepackte Zahl
f
8/ 8
0
Float, Gleitpunktzahl
c
1/ 165535
``
Character,
alphanumerischer
Text, Ersatz für
booleschen Datentyp
n
1/ 165535
`0...0`
Numerischer Text
d
8/ 8
`00000000`
Date, Datumsangabe
t
6/ 6
`000000`
Time, Zeitangabe
x
1/ 165535
`00...00`
Hexadezimal
elementare Datentypen variabler Länge
string
String, zeichenartiger
Typ
xstring
Xstring, byteartiger
Typ
Ein Datenobjekt wird in ABAP mit der Anweisung
DATA
Datenobjektname[(Länge)]
TYPE
Datentyp
[DECIMALS
Anzahl]
[VALUE
Initialwert].
erzeugt, wobei Datenobjektname die Bezeichnung des erzeugten Datenobjekts darstellt und
Datentyp durch einen der ABAP Datentypen aus obiger Tabelle gefüllt werden muss. Optional
gibt man bei den Datentypen p, c, n und x noch die benötigte Länge an, ansonsten werden die
jeweiligen Standardlängen verwendet. Für den Datentyp p sollte hinter DECIMALS die Anzahl
der Nachkommastellen festgelegt werden, welche standardmäßig 0 ist und so das deklarierte
Datenobjekt wie einen normalen Integer behandeln lassen würde. Außerdem kann für alle
Datentypen optional noch ein Initialwert mitgegeben werden.
Aus den zehn in ABAP eingebauten Datentypen lassen sich programmlokal auch eigenständige
Datentypen definieren, dies geschieht mit der Anweisung
TYPES Datentypname[(Länge)] TYPE Datentyp [DECIMALS Anzahl].
Nach dieser Datentypdefinition können mit der DATA Anweisung Datenobjekte des selbst
definierten Datentyps erzeugt werden.
Anstatt des TYPE Zusatzes in der Datenobjektdeklaration und der Datentypdefinition kann auch
ein LIKE verwendet werden, hinter dem der Name eines bereits deklarierten Datenobjektes
angegeben wird. Das so erzeugte Datenobjekt oder der Datentyp erhalten dann die Eigenschaften
des Datenobjektes, auf das sich LIKE bezieht.
33
Aus den bisher angesprochenen elementaren Datentypen lassen sich auch komplexe Datentypen
konstruieren. Dabei gibt es zum einen die strukturierten Typen, welche sich aus einer Folge
anderer Datentypen zusammensetzen und dementsprechend auch Struktur genannt werden. Sie
werden nach folgender Anweisungsvorschrift erzeugt:
TYPES|DATA: BEGIN OF Strukturname,
Komponente1name
{TYPE
Datentyp1name|
LIKE
Datenobjekt1name}
[VALUE
{TYPE
DatentypNname|
LIKE
DatenobjektNname}
[VALUE
Initialwert1],
…
KomponenteNname
InitialwertN],
END OF Strukturname.
Eine Komponente kann also ein elementarer, ein selbst definierter Datentyp, eine
Datenbanktabelle oder eine andere Struktur sein. Eine Datenbanktabelle wird einer Struktur
folgendermaßen zugewiesen:
TYPES|DATA Strukturname TYPE Datenbanktabellenname.
Soll eine Struktur andere Strukturen enthalten, kann dies durch Verschachtelung definiert
werden:
TYPES|DATA: BEGIN OF Struktur1name,
Komponente1name {TYPE Datentyp1name| LIKE Datenobjekt1name} …,
Komponente2name {TYPE Datentyp2name| LIKE Datenobjekt2name} …,
BEGIN OF Struktur2name,
Komponente3name {TYPE Datentyp3name| LIKE Datenobjekt3name} …,
Komponente4name {TYPE Datentyp4name| LIKE Datenobjekt4name} …,
END OF Struktur2name,
END OF Struktur1name.
34
Angesprochen werden die Strukturkomponenten, indem der Hierarchie entsprechend Strukturund Komponentenname(n) mit Bindestrich verkettet werden:
Struktur1name- Komponente1name
Struktur1name- Struktur2name- Komponente4name
Sollen die Komponenten einer in einer anderen Struktur enthaltenen Struktur nicht eine
Hierarchiestufe niedriger sein, kann sie per INCLUDE
TYPES|DATA: BEGIN OF Struktur3name,
Komponente5name {TYPE Datentyp5name| LIKE Datenobjekt5name} ….
INCLUDE TYPE|STRUCTURE Struktur1name AS Struktur1alias [RENAMING WITH
SUFFIX Nachsilbe].
…
DATA END OF Struktur3name.
ein gebunden werden. Dabei bezieht sich TYPE auf eine als Datentyp definierte Struktur und
STRUCTURE auf eine als Datenobjekt deklarierte Struktur. STRUCTURE entspricht also dem
LIKE bei nicht strukturierten Datentypen. Durch diese Aufnahme anderer Strukturen können
natürlich Namenskonflikte auftreten, da die Komponenten der anderen Strukturen durchaus
gleiche Namen haben könnten. Sollte ein Namenskonflikt vorkommen muss zwingend eine
eindeutige Nachsilbe angegeben werden. Die Komponenten können sowohl in der verketteten
Schreibweise
Struktur3name- Struktur1alias- Struktur1Komponente1name
als auch in der Kurzschreibweise
Struktur3name- Struktur1Komponente1name+Nachsilbe
angesprochen werden.
35
Die zweite Art komplexer Datentypen sind nach den statischen Strukturen die dynamischen sog.
internen Tabellen. Diese ersetzen auch den nicht vorhandenen Datentyp Array. Sie sind durch
eine Tabellenart, einen Zeilentyp und einen Tabellenschlüssel gekennzeichnet und werden mit
folgender Anweisung angelegt:
TYPES|DATA interneTabellenname {TYPE|LIKE} Tabellenartname
OF {Zeilentypname|Zeilenobjektname}
[WITH Tabellenschlüsselname]
[INITIAL SIZE n].
Dabei gibt die Tabellenart an, wie auf die interne Tabelle zugegriffen wird und es kann zwischen
den drei Arten [STANDARD] TABLE, SORTED TABLE und HASHED TABLE gewählt
werden. Bei [STANDARD] TABLE und SORTED TABLE werden die einzelnen Zeilen durch
einen logischen Index verwaltet, bei SORTED TABLE sind sie jedoch nach dem
Tabellenschlüssel aufsteigend sortiert. Bei beiden Arten kann sowohl über den Index als auch
über den Schlüssel auf die Zeilen zugegriffen werden.
Im Gegensatz dazu steht jedoch die HASHED TABLE, bei der die Einträge durch einen HashAlgorithmus verwaltet und mit der direkt über eine Hash Funktion aus dem Schlüssel berechnete
Position angesprochen werden.
Der Zeilentyp ist meistens eine Struktur oder gar eine Datenbanktabelle bzw. deren Struktur. Er
kann aber auch durch elementare Datentypen, Referenzvariablen oder interne Tabellen
beinhalten.
Je nach Zeilentyp können verschiedene Tabellenschlüssel angegeben werden. Nicht strukturierte
können nur die Pseudokomponente table_line als Schlüssel verwenden, welche den gesamten
Zeileninhalt beinhaltet: [UNIQUE|NON-UNIQUE] KEY table_line.. Dieser Schlüssel kann
auch bei strukturierten Tabellen angegeben werden.
Sinnvoller ist es jedoch bei strukturierten Tabellen die einzelnen Komponenten zu verwenden,
wobei jede Komponente, die keine Tabelle ist oder eine solche enthält, direkt im Schlüssel
angegeben werden kann:
[UNIQUE|NON-UNIQUE] KEY Komponente1name … KomponenteNname.
36
Die Abfolge der Komponenten ist bei der Schlüsselauswertung von Belang.
Bei einer strukturierten Tabelle kann mit [UNIQUE|NON-UNIQUE] DEFAULT KEY. auch
der Standardschlüssel angeben werden. Dieser besteht dann aus allen nicht numerischen
Komponenten (alle außer i, f, p) und denen, die auch keine Tabelle sind. Bei einer Tabelle mit
elementarem Zeilentyp, also nur einer einzigen und auch elementaren Komponente, entspricht
der Standardschlüssel dem oben erwähnten table_line.
Die Angaben UNIQUE und NON-UNIQUE schreiben vor, ob der Schlüssel eindeutig sein muss
oder nicht, ob er nicht mehrfach vorkommen darf oder doch. Der Schlüssel der Standardtabellen
ist immer nicht eindeutig und der der Hash-Tabellen immer eindeutig, der der sortierten Tabellen
kann jedoch beides sein, deswegen sollte die Angabe bei diesen gemacht werden.
Alle Datentypdefinitionen können natürlich auch global vorgenommen werden. Dies geschieht in
der SAP Entwicklungsumgebung des Object Navigators durch Anlegen eines neuen Data
Dictionary Objektes (vgl. Abbildung 3.3).
Abbildung 3.3 – Anlegen eines Data Dictionary Objektes
Das Data Dictionary, auch ABAP Dictionary genannt, ist eine Programm übergreifende Ablage,
auf die alle Entwicklungsobjekte (Repository-Objekte) zugreifen können.
3.3.2 Datentypen der Datenbank
Angebotene datentypen in MS SQL Server: bigint, binary, bit, char, datetime, decimal, float,
image, int, money, nchar, ntext, numeric, nvarchar, real, smalldatetime, smallint, smallmoney,
sql_variant, text, timestamp, tinyint, uniqueindentifier, varbinary, varchar
37
Exact Numerics
Integers
bigint
Integer (whole number) data from -2^63 (-9223372036854775808) through 2^63-1
(9223372036854775807).
int
Integer (whole number) data from -2^31 (-2,147,483,648) through 2^31 - 1 (2,147,483,647).
smallint
Integer data from 2^15 (-32,768) through 2^15 - 1 (32,767).
tinyint
Integer data from 0 through 255.
bit
bit
Integer data with either a 1 or 0 value.
decimal and numeric
decimal
Fixed precision and scale numeric data from -10^38 +1 through 10^38 –1.
numeric
Functionally equivalent to decimal.
money and smallmoney
money
Monetary data
values
from
-2^63
(-922,337,203,685,477.5808)
through
2^63
-
1
(+922,337,203,685,477.5807), with accuracy to a ten-thousandth of a monetary unit.
smallmoney
Monetary data values from -214,748.3648 through +214,748.3647, with accuracy to a tenthousandth of a monetary unit.
Approximate Numerics
float
Floating precision number data from -1.79E + 308 through 1.79E + 308.
real
Floating precision number data from -3.40E + 38 through 3.40E + 38.
38
datetime and smalldatetime
datetime
Date and time data from January 1, 1753, through December 31, 9999, with an accuracy of threehundredths of a second, or 3.33 milliseconds.
smalldatetime
Date and time data from January 1, 1900, through June 6, 2079, with an accuracy of one minute.
Character Strings
char
Fixed-length non-Unicode character data with a maximum length of 8,000 characters.
varchar
Variable-length non-Unicode data with a maximum of 8,000 characters.
text
Variable-length non-Unicode data with a maximum length of 2^31 - 1 (2,147,483,647)
characters.
Unicode Character Strings
nchar
Fixed-length Unicode data with a maximum length of 4,000 characters.
nvarchar
Variable-length Unicode data with a maximum length of 4,000 characters. sysname is a systemsupplied user-defined data type that is functionally equivalent to nvarchar(128) and is used to
reference database object names.
ntext
Variable-length Unicode data with a maximum length of 2^30 - 1 (1,073,741,823) characters.
Binary Strings
binary
Fixed-length binary data with a maximum length of 8,000 bytes.
varbinary
Variable-length binary data with a maximum length of 8,000 bytes.
image
Variable-length binary data with a maximum length of 2^31 - 1 (2,147,483,647) bytes.
Other Data Types
39
cursor
A reference to a cursor.
sql_variant
A data type that stores values of various SQL Server-supported data types, except text, ntext,
timestamp, and sql_variant.
table
A special data type used to store a result set for later processing .
timestamp
A database-wide unique number that gets updated every time a row gets updated.
uniqueidentifier
A globally unique identifier (GUID).
MaxDB: Data Type (data_type)
As well as specifying the column name when you define columns, you can also specify data types.
Syntax
<data_type> ::=
CHAR[ACTER] [(<unsigned_integer>)] [ASCII | BYTE | EBCDIC | UNICODE]
|VARCHAR [(<unsigned_integer>)] [ASCII | BYTE | EBCDIC | UNICODE]
| LONG [VARCHAR] [ASCII | BYTE | EBCDIC | UNICODE]
| BOOLEAN
| FIXED (<unsigned_integer> [,<unsigned_integer>])
| FLOAT (<unsigned_integer>)
| INT[EGER] | SMALLINT
| DATE | TIME | TIMESTAMP
unsigned_integer
CHAR[ACTER], VARCHAR, LONG[VARCHAR], BOOLEAN, FIXED, FLOAT, INT[EGER], SMALLINT,
DATE, TIME, TIMESTAMP
Explanation
40
For the following character strings, a code attribute can be entered as part of a column definition
(column_definition), if required: CHAR[ACTER], VARCHAR, LONG[VARCHAR]
In addition to the data types defined above, the following data types are permitted in a column definition
and are mapped as follows to the data types below:
Data Type
Is Mapped To
BINARY(p)
FIXED(p)
DEC[IMAL](p,s)
FIXED(p,s)
DEC[IMAL](p)
FIXED(p)
DEC[IMAL]
FIXED(5)
DOUBLE PRECISION
FLOAT(38)
FLOAT
FLOAT(16)
FLOAT(39..64)
FLOAT(38)
LONG VARCHAR
LONG
NUMERIC(p,s)
FIXED(p,s)
NUMERIC(p)
FIXED(p)
NUMERIC
FIXED(5)
REAL(p)
FLOAT(p)
REAL
FLOAT(16)
SERIAL
FIXED(10) DEFAULT SERIAL
SERIAL(p)
FIXED(10) DEFAULT SERIAL(p)
Microsoft SQL Server
MaxDB
41
Datentypen fester Länge
Typ
Standard-/
Größe
[Byte]
Initialwert
Erläuterung
i
4/ 4
0
Integer, ganze Zahl
p
8/ 1-16
0
Packed, gepackte Zahl
f
8/ 8
0
Float, Gleitpunktzahl
c
1/ 165535
``
Character,
alphanumerischer
Text
n
1/ 165535
`0...0`
Numerischer Text
d
8/ 8
`00000000`
Date, Datumsangabe
t
6/ 6
`000000`
Time, Zeitangabe
x
1/ 165535
`00...00`
Hexadezimal
Datentypen variabler Länge
string
String, zeichenartiger
Typ
xstring
Xstring, byteartiger
Typ
Tabelle 3.1 – Datentypen
3.3.3 HTMLB
Das Verwenden der bereits in 2.2.3 erwähnten BSP-Extension HTMLB ist dem von
ursprünglichen HTML sehr ähnlich. Eine Seite wird mit den entsprechenden HTMLB Elementen
aufgebaut. Dazu muss jedoch die Extension mit ihrem Namen im HTML Dokument mit
<%@extension name="htmlb" prefix="htmlb" %>
bekannt gemacht werden, und dann jedes
Element nach dem Prinzip <htmlb:Elementname> verwandt werden. Die folgende Tabelle bietet
eine Gegenüberstellung von HTMLB und HTML.
HTMLB Elemente
Elemente zur Seitenaufteilung
Elementname
Beschreibung
entsprechendes HTML Tag
content
Content
-
42
document
documentBody
documentHead
headInclude
form
gridLayout
gridLayoutCell
Dokument
Dokumenten-Body
Dokumenten-Head
Include Bereich des Headers
Formular
Gitter-Layout
Gitter-Layout-Zelle
page
Seite
<html>
<body>
<head> nur für Seitentitel
<head> für styles und scriptings
<form>
unsichtbare <table>
Mischung aus unsichtbaren <tr>
und <td>
-
Elementname
Beschreibung
entsprechendes HTML Tag
breadCrumb
Navigation über Pfadhistorie
-
 breadCrumbItem
Eintrag in der Pfadhistorie
-
button
Drucktaste
<input type="button">
chart
Diagramm
-
checkbox
Ankreuzfeld
<input type="checkbox">
 checkboxGroup
Gruppierung von Ankreuzfeldern
gleicher „name“ mehrerer
Ankreuzfelder
dataContainer
Data Container für dropdownListBox ?
dateNavigator
Kalendersicht
-
days
Tage
-
dropdownListBox
Dropdown-Listbox
<select size=“1“>
fileUpload
Datei hochladen
<input type="file">
group
Gruppe als Designelement
 groupBody
Gruppen-Body
mit <fieldset> vergleichbar
ansonsten mit <table> leicht
nachbaubar
 groupHeader
Gruppen-Header
s.o. entspricht jedoch der
<legend> von <fieldset>
image
Bild
<img>
inputField
Eingabefeld
<input>
itemList
Listeneintrag
label
Beschriftung
<label>
link
Hyperlink
<a href>
listBox
Listbox
<select size=“>1“>
sichtbare Elemente
43
 listBoxItem
Listbox-Eintrag
listItem
Listeneintrag
month
Monat
radioButton
Auswahlknopf
input type="radio"
radioButtonGroup
Auswahlknopfgruppe
gleicher „name“ mehrerer
Auswahlknöpfe
tabStrip
Tabstrip
-
tabStripItem
Tabstrip-Eintrag
-
tabStripItemBody
Body eines Tabstrip-Eintrags
-
tabStripItemHeader
Header eines Tabstrip-Eintrags
-
tableView
TableView
sichtbare <table>
 tableViewColumn TableView-Spalte
 tableViewColumns TableView-Spalten
<option>
Mischung aus sichtbaren <tr> und
<td>
textEdit
TextEdit
<textarea>
textView
TextView zur Textdarstellung
<p>
tray
Tray
-
trayBody
Body des Trays
-
tree
Baum
-
 treeNode
Baum-Knoten
-
week
Woche
?
Tabelle 3.2 – Übersicht über HTMLB Elemente mit HTML Entsprechungen
Jedes dieser HTMLB Elemente lässt sich über Attribute genauer definieren und meistens über das
obligatorische id-Attribut ansprechen. Wie in HTML gibt es dabei zum Beispiel häufig ein
Attribut für die Breite, Höhe, Länge u.v.a.. Oft verfügen die HTMLB Elemente jedoch nicht über
einen funktionellen Mehrwert gegenüber ihrer HTML Entsprechungen. Sie ermöglichen es
vielmehr, aufwandsarm eine SAP Design konforme Anwendung zu entwickeln. Einige Elemente
weisen jedoch auch einen funktionellen Mehrwert auf. So lassen sich beispielsweise breadCrumb,
dataContainer, dropdownListBox und tableView über die Angabe einer internen Tabelle
automatisch befüllen. Desweiteren gibt es Elemente, die es in ihrer Form in HTML vorgefertigt
überhaupt nicht gibt, bzw. die nur komplizierter mithilfe von JavaSkript zu erzeugen wären wie
zum Beispiel das tree Element.
44
Einen auch visuellen
Überblick zu vielen der HTMLB Elemente gibt
es
unter
http://mysap.wdf.sap.corp:2080/resources/htmlb_guidance/.
3.3.4 MVC Design Pattern in BSPs
Wie bereits in 2.2.3 angerissen, werden in BSPs Präsentations-, Ablauf- und Anwendungslogik
streng als Views, Controller und Models voneinander getrennt. Die Views sollten hauptsächlich
mit HTMLB umgesetzt werden. Ähnlich wie bei JavaScript können durch sogenannte
Eventhandler Funktionen ausgelöst werden, mit denen auf Ereignisse in der Präsentationslogik
reagiert wird. Dabei stehen für die HTMLB Elemente allerdings viel weniger Eventhandler zur
Verfügung als in JavaScript. Folgende Tabelle zeigt auf, welche HTMLB Elemente, welche
Eventhandler zur Verfügung stellen. Eventhandler, die „Client“ enthalten, stoßen clientseitige
JavaScript Methoden an, während alle anderen serverseitig die entsprechenden EventhandlerMethoden aufrufen.
HTMLB Element
unterstütze Eventhandler
breadCrumb
onClick
button
onClick, onClientClick
checkbox
onClick, onClientClick
dateNavigator
onDayClick, onMonthClick, onNavigate, onWeekClick
dropdownListBox
onCientSelect, onSelect
image
onClick, onClientClick
inputField
onValueHelp (Client-seitig)
link
onClick, onClientClick
page
onLoad
radioButton
onClick, onClientClick
 tabStripItem
onSelect
tableView
onClientRowSelection, onFilter, onHeaderClick, onNavigate,
onRowSelection
45
HTMLB Element
unterstütze Eventhandler
 tableViewColumn
onCellClick, onItemClick
tray
onCollapse, onEdit, onExpand, onRemove
tree
onTreeClick
 treeNode
onNodeClick
Elemente ohne Eventhandler
breadCrumbItem, chart, checkboxGroup, dataContainer, days, fileUpload, group, groupBody,
groupHeader, itemList, label,. listBox, listBoxItem, listItem, month, radioButtonGroup,.
tableViewColumns, tabStrip, tabStripItemBody, tabStripItemHeader, textEdit, textView,
trayBody, week
Tabelle 3.3 – HTMLB Elemente und ihre Eventhandler
Die verschiedenen Eventhandler lösen bei ihren Namen entsprechenden Ereignissen die
Methoden des Controllers, der Ablauflogik, aus. Das Auslösen der Controllermethoden muss
durch explizites Verwenden dieser geschehen, indem man diesen bei den Attributen des HTMLB
Elements einen Wert zuweist.
<htmlb:breadcrumb
id
= "BreadCrumb1"
tooltip
= "Behaviour Default"
onClick
= "BreadClick1">
<htmlb:breadCrumbItem key="k1" value="text1" />
<htmlb:breadCrumbItem key="k2" value="text2" />
</htmlb:breadCrumb>
Ohne diesen expliziten Aufruf durch das Attribut, wird nicht zum Controller gesprungen, was
u.U. sinnvoll sein kann. So macht es zum Beispiel keinen Sinn, bei jeder Aktion in einem
Formular (z.B. das Anwählen eines Auswahlknopfes) eine Ereignisverarbeitung anzustoßen, da
viele Informationen erst beim endgültigen Absenden der Formulardaten zur Weiterverarbeitung
benötigt werden.
Sollte man mit den vorgestellten Eventhandlern der HTMLB Elemente nicht auskommen, kann
man im Notfall auch ursprüngliches (natives) HTML mit seinen Eventhandlern nutzen und
serverseitige JavaScripts per
<htmlb:headInclude/>
<script language="JavaScript" type="text/javascript">
46
…
</script>
in den View einbinden. Diese Vorgehensweise verstößt allerdings gegen zwei Richtlinien der
aktuellen BSP Entwicklung, welche u.a. Scripting als auch HTML untersagen.
In HTML gibt es folgende Eventhandler:
onAbort (bei Abbruch), onBlur (bei Verlassen), onChange (bei erfolgter Änderung), onClick
(beim Anklicken), onDblClick (bei doppeltem Anklicken), onError (im Fehlerfall), onFocus
(beim Aktivieren), onKeydown (bei gedrückter Taste), onKeypress (bei gedrückt gehaltener
Taste), onKeyup (bei losgelassener Taste), onLoad (beim Laden einer Datei), onMousedown
(bei gedrückter Maustaste), onMousemove (bei weiterbewegter Maus), onMouseout (beim
Verlassen des Elements mit der Maus), onMouseover (beim Überfahren des Elements mit der
Maus), onMouseUp (bei losgelassener Maustaste), onReset (beim Zurücksetzen des Formulars),
onSelect (beim Selektieren von Text), onSubmit (beim Absenden des Formulars), onUnload
(beim Verlassen der Datei)
Bei welchen HTML Elementen die jeweiligen Eventhandler zur Verfügung stehen, ist unter
http://de.selfhtml.org/javascript/sprache/eventhandler.htm einzusehen.
Auch wenn die Entwicklungsumgebung Debugging zulässt, sollte man die Anwendung Schritt
für Schritt wieder aufbauen und nicht gleich alles auf einmal, bevor man das erste Mal testet.
3.3.5 Funktionlitäten
Zusammenhang: Aufzeigen der Probleme durch fehlende funktionelle Möglichkeiten der
Zielplattform bzw. Zeigen, wie solche Grenzen gefunden werden können
Noch umfangreicher als die Datentypen verschiedener Sprachen sind ihre Funktionalitäten,
weswegen das Betrachten verwendeter Funktionalitäten noch wichtiger ist. Hierzu sollten
insbesondere vom normalen Umfang einer Programmiersprache abweichende Funktionalitäten
auf ihre Portierbarkeit geprüft werden. Aber auch Standardfunktionen wie Datenbankoperationen
sollten geprüft werden, um mögliche Probleme ausfindig zu machen.
47
3.4 Portierungsschrit 3/6: Analyse der Ausgangsanwendung
Sollte die Machbarkeitsprüfung für die Anwendung positiv ausgefallen sein, so dass es bei der
bevorstehenden Portierung keine unlösbaren Probleme geben sollte, lohnt es sich, die
Ausgangsanwendung nach dem bisherigen „Kennen Lernen“ nochmals genauer zu analysieren.
Dabei stehen jetzt nicht mehr die verwendeten Funktionalitäten im Vordergrund wie beim
Kennen Lernen sondern die Ablauflogik. In Vorbereitung auf die kommende Optimierung der
Anwendung und Implementierung der Zielanwendung empfiehlt sich dabei, die gesamte
Ablauflogik in Form von Nassi-Schneidermann-Diagrammen ab zu bilden. Zum Darstellen der
Ablauflogik bietet sich die Form eines Nassi-Schneidermann-Diagramms an, weil dieses die
Ablauflogik sehr gut verständlich und anschaulich zeigt. Zusammenhänge zwischen Methoden
und ihren Aufrufen an anderen Stellen werden übersichtlich gezeigt, was bei der
Fließtextdarstellung des originalen Quelltextes nicht der Fall ist. Der Quelltext sollte vom
Kennen Lernen noch einigermaßen bekannt sein, so dass sich nicht erneut vollkommen neu in ihn
eingearbeitet werden muss.
48
3.5 Portierungsschrit 4/6: Optimierung
Natürlich könnte nach dem vorhergegangenen kennen Lernen der Ausgangsanwendung alleine
aufgrund der notwendigen Funktionalitäten die Zielanwendung von Grund auf neu umgesetzt
werden. Es trägt jedoch zur Güte der Zielanwendung bei, wenn eine vorhandene Ablauflogik
erneut geprüft und gegebenenfalls optimiert wird. Dadurch wird die Les- und Wartbarkeit
verbessert. Eine Anwendung wird außerdem selten von der gleichen Person, die sie ursprünglich
entwickelt hat, portiert, deswegen wirkt sich alleine die Prüfung durch eine weitere Person positiv
aus, da die mögliche Betriebsblindheit des Ursprungsentwicklers ausgeglichen werden kann.
Außerdem gewinnt auch der portierende Entwickler durch die bisherige Umsetzung der
Anwendung, weil eventuelle Feinheiten umgesetzt wurden, an die man auf Anhieb gar nicht
denken würde. Kurzum ist es auf jeden Fall besser, eine bestehende Logik zu überarbeiten und
somit zu prüfen, als eine neue zu erarbeiten, welche dann nicht noch mal in Frage gestellt wird.
3.5.1 Daten
Als erstes sollten alle verwendeten Datentypen der Variabeln überprüft werden. Hier ist von
Interesse, ob die möglichen Werte einer Variablen deren Datentyp überhaupt maximal ausfüllen
können oder ob auch ein Datentyp mit weniger Speicherplatz ausreichend wäre. Manchmal
werden Datentypen für Variablen können auch unlogisch vergeben, so dass beispielsweise
anstelle eines booleschen Datentyps ein einzelnes Zeichen (char) verwendet wird, um eine ja/nein
Möglichkeit für eine Variable abzuspeichern.
3.5.2 Ablauflogik
Ist die Ablauflogik der Ausgangsanwendung vollständig verstanden und als NassiSchneidermann-Diagramm abgebildet, kann mit der Optimierung begonnen werden. Bei der
Optimierung gilt es v.a. Logikfehler auszumerzen oder ungenutzten Code zu entfernen.
Ungenutzter Code ist Code, welcher unverwendet bleibt, weil er gar nicht aufgerufen wird oder
gar auskommentiert wurde. Auch nicht verwendete Variablen sollten gesucht und entfernt
werden, da sie den Entwickler nur verwirren. Logikfehler können sehr vielseitig aussehen.
Beispielhaft wären unlogische Abläufe zu nennen, bei denen Variablenwerte mehrfach
hintereinander geändert werden, ohne diese zwischen den Werteänderungen zu verwenden.
49
Einfach alle Abläufe, die keinerlei auf die Anwendung oder die Daten wirksame Veränderungen
bewirken, sind unlogisch, nutzlos und sollten deswegen ausgebessert werden.
Redundanzen Untermenge von Logikfehler?
Redundanzen in Form von Wiederholungen können sich auch negativ auf das Verstehen des
Codes auswirken, da mit zunehmender Menge die Übersichtlichkeit sinkt und somit der
Überblick schwindet. Wiederholungen treten zum Beispiel bei Fallunterscheidungen auf, wenn
die ähnliche Behandlung von eintretenden Fällen separat verarbeitet wird. Dort läßt sich eventuell
mit Variablen ein vorhandener kleiner Unterschied vereinheitlichen, so dass danach ein Fall für
beide ausreicht.
Generell kann jede mehrfach auftretende Abfolge von Befehlen zu einer kleinen Funktion
zusammengefasst werden, um Redundanzen zu vermeiden.
petrinetz? (also das Ding mit den Muenzen)
3.5.3 Oberfläche
Die grafische Oberfläche der Anwendung sollte auch auf ihr Optimierungspotential untersucht
werden. Dabei gilt es, sie so intuitiv bedienbar wie möglich zu machen. Dem Benutzer sollte,
ohne groß nachdenken zu müssen, klar sein, was er wo und wie zu tun hat. Ist dies nicht alleine
durch die Anordnung der Elemente und ihrer Benennung möglich, sollte nicht vor
beschreibenden Erklärungstexten zurück geschreckt werden.
3.5.4 Datenbank
Besteht die Möglichkeit, den Datenbankentwurf für die Portierung zu überdenken und ihn zu
optimieren, so sollte dies durchaus in Betracht gezogen werden. Grenzen wären solch einer
Datenbankoptimierung beispielsweise dadurch gesetzt, dass sich die Portierung der Daten dann
komplexer als durch die Skriptvorgabe (vgl. 3.5.6 Datenportierung S.57 und Programmkode 3.1
S.62) gestalten würde. Es wäre folglich eine finanzielle und zeitliche Frage, ob eine
50
Datenbankoptimierung vorgenommen werden kann. Die Datenbankoptimierung bietet mit der
Minimierung logischer Probleme, dem Vermeiden von Redundanzen21 und der daraus
entstehenden Einsparung von Speicherkapazität, dem Aufrecht erhalten der Integrität22 und der
Vereinfachung von Aktualisierungen der Datenbankeinträge viele Vorteile. Die Problematik, dass
die alten Daten auch für bisherige Anwendungen verfügbar und verwendbar sein müssten, besteht
insofern nicht, dass auch all diese Anwendungen portiert werden müssen.
Wie kann eine Datenbank nun also optimiert werden?
Analog zur Datentyoptimierung (vgl. 3.5.1) der Variablen einer Anwendung wäre ein erster
relativ unaufwendiger Schritt das Überprüfen der verwendeten Datentypen aller Attribute in der
Datenbank. Dabei stellt sich die Frage, ob die möglichen Werte eines Attributes dessen Datentyp
überhaupt maximal ausfüllen können oder ob auch ein Datentyp mit weniger Speicherplatz
genügen würde. Datentypen für Attribute können auch unlogisch vergeben worden sein, so wird
manchmal anstelle eines booleschen Datentyps ein einzelnes Zeichen (char) verwendet, um eine
ja/nein Möglichkeit für ein Attribut abzuspeichern.
Im
Gegensatz
zu
dieser
einfachen
Datentypoptimierung,
ist
die
Optimierung
des
Datenbankentwurfs selbst weitaus aufwendiger. Hier sollten zunächst alle Tabellen der
Datenbank als Functional-Dependency-Diagramm23 (FD-Diagramm) dargestellt werden, um
Abhängigkeiten
zwischen
den
Attributen
einer
Tabelle
darzustellen.
Viele
Datenbankmanagementsysteme unterstützen glücklicherweise die Funktionalität, solche ERDiagramme automatisch zu generieren, so dass dies nicht in Handarbeit getan werden muss (auch
fd-diagramm?). Anhand des FD-Diagramms kann danach der Datenbankentwurf einfacher
normalisiert werden, da es anschaulicher als ohne Darstellung ist. Bei der Normalisierung24 der
Datenbank gibt es sechs/neun Stufen, denen ein Datenbankentwurf entsprechen kann, wobei
21
Redundanz: hier Mehrfachhaltung von Daten in einer Datenbank
Datenkonsistenz, Verfügbarkeit, Vertraulichkeit
23
Die Funktionale Abhängigkeit gibt an, wie Attribute von einander abhängen, ob beispielsweise einem Wert von
Attribut A nur ein bestimmter Wert von Attribut B zugeordnet werden kann.
24
Normalisierung: ideales Strukturieren einer Datenbanktabellen zum Vermeiden von Redundanzen
22
51
i.d.R. die ersten drei ausreichend sind. Jede Normalform schließt die Bedingungen der vorherigen
Normalformen ein.
In der ersten Normalform befinden sich alle Tabellen, deren Attribute atomar sind, d.h. ihre
Wertinformationen nicht mehr in Einzelinformationen zerlegt werden können. Beispielhaft wäre
der Name einer Person in die Einzelinformationen Vorname und Familienname zerlegbar.
#25Person_ID
Name
#Person_ID
Vorname
Familienname
001
‚Ulrike Koch’
001
‚Ulrike’
‚Koch’
Abbildung 3.4 – 1. Normalisierung einer Tabelle
In der zweiten Normalform befinden sich Tabellen, die keine zusammengesetzten
Primärschlüssel sondern nur einzelne haben. Bei der Verwaltung von Musik CDs und ihren
Titeln, müssen allgemeine CD Informationen (Titel, Interpret, Preis, etc.) getrennt von den
einzelnen Liedinformationen (Liedlänge, Liedtitel, Liedposition, etc.) gespeichert werden, um der
zweiten Normalform zu entsprechen. Der CD Titel wird dann in der Liedertabelle als
Fremdschlüssel mit angegeben (trotzdem 2.NF?). Ohne diese Maßnahme, kämen bei einer
einzigen Tabelle die CD Information bei jedem CD Lied redundant vor.
#CD_ID CD_Titel
CD_Interpret
CD_Preis #Track_ID Liedtitel
4711 Not That Kind
Anastacia
15,99€
1 Not That Kind
4711 Not That Kind
Anastacia
15,99€
2 I'm Outta Love
4711 Not That Kind
Anastacia
15,99€
3 Cowboys & Kisses
4712 Wish You Were
Pink Floyd
14,59€
1 Shine On You Crazy
Here
Diamond
Tabelle 3.4 – einzelne nicht 2. Normalform entsprechende Tabelle
25
#: Symbol für ein Schlüsselattribut, von Schlüsselattributen sind andere Attribute funktional abhängig
52
Das
CD_Titel
FD-Diagramm
Ursprungstabelle
#CD_ID
!
#Track_ID
weist
der
mit
der
CD_Interpret
Abhängigkeit des Liedtitels von einem
CD_Preis
zusammengesetzten
Schlüssel
eine
Verletzung der 2. Normalform auf!
Liedtitel
Diese Verletzung der 2. Normalform
CD_Titel
wird durch das Verfrachten der
Liedtitel und ihrer #Track_ID in eine
weitere
Tabelle
behoben.
#CD_ID
CD_Interpret
Dabei
CD_Preis
kommt #CD_ID als Fremdschlüssel
(kein
zusammengesetzter
#CD_ID
schlüssel???) mit in die Tabelle.
Liedtitel
#Track_ID
Abbildung 3.5 – 2. Normalisierung einer Tabelle
#CD_I CD_Titel
CD_Interpret
CD_Preis
D
4711 Not That Kind
Anastacia
15,99€
4712 Wish You Were Here
Pink Floyd
14,59€
#CD_I
#Track_ID Liedtitel
D
4711
1 Not That Kind
4711
2 I'm Outta Love
4711
3 Cowboys & Kisses
4712
1 Shine On You Crazy Diamond
Tabelle 3.5 – zwei der 2. Normalform entsprechenden Tabellen
53
Um auch der dritten Normalform zu entsprechen, darf in der Tabelle ein Attribut nicht abhängig
von einem zweiten sein, dass nicht der Primärschlüssel ist, logischerweise selbst aber genau von
diesem abhängig ist. Werden bei den Mitarbeiterdaten einer Firma zum Beispiel auch deren
Kostenstellenabteilung samt Kostenstellennummer gespeichert, tritt erstere unnötig und vor allem
redundant auf, da die Kostenstellennummer die Kostenstellenabteilung eindeutig angibt. Die
Vermeidung dieser Redundanz wird wieder durch die Aufteilung in zwei Tabellen erreicht.
In einer zweiten Tabelle werden die Kostenstellennummern und die Kostenstellenabteilungen
gespeichert und gleichzeitig bleiben die Kostenstellennummern als Fremdschlüssel in der
Mitarbeiterdatentabelle. Da jede Kostenstellennummer nur einer Kostenstellenabteilung
zugeordnet werden kann, wird sie in der zweiten Tabelle zum Primärschlüssel.
#Person_ID Vorname
Familienname
Abteilung
#Kostenstelle
123 Reiner
Zufall
Einkauf
2004
144 Frank
Frei
Verkauf
2006
146 Susi
Sorglos
Einkauf
2004
148 Frey
Erfunden
Einkauf
2005
Tabelle 3.6 – einzelne nicht 3. Normalform entsprechende Tabelle
Das
Vorname
FD-Diagramm
tabelle
#Person_ID
weist
der
mit
Ursprungs-
der
alleinigen
Familienname
Abhängigkeit der Abteilung von einem
#Kostenstelle
nicht
dem
chenden
!
Primärschlüssel
Attribut
der
entspre-
Tabelle
eine
Verletzung der 3. Normalform auf!
Abteilung
Diese Verletzung der 3. Normalform
wird
durch
das
Verfrachten
Vorname
der
Abteilung in eine weitere Tabelle
#Person_ID
behoben. Dabei verbleibt #Kostenstelle
Familienname
#Kostenstelle
als Fremdschlüssel in der ersten
Tabelle.
54
#Kostenstelle
Abteilung
Abbildung 3.6 – 3. Normalisierung einer Tabelle
#Person_ID Vorname
Familienname
#Kostenstelle
123 Reiner
Zufall
2004
144 Frank
Frei
2006
146 Susi
Sorglos
2004
148 Frey
Erfunden
2005
#Kostenstelle Abteilung
2004 Einkauf
2005 Einkauf
2006 Verkauf
Tabelle 3.7 – zwei der 3. Normalform entsprechenden Tabellen
55
Portierungsschrit 5/6: Implementierung der BSP Anwendung
3.5.5 Vorarbeiten
Wie in 3.1.2 angesprochen gibt es hauptsächlich zwei Vorgehensweisen, um Software zu
implementieren. Aus den bereits genannten Gründen (Fehlerfindung, Motivation) wird hier die
Top Down Methode empfohlen, bei der zunächst ein
kleiner funktionierender Teil implementiert wird und
dann
nach
und
nach
um
alle
weiteren
Funktionalitäten erweitert wird.
Im Bezug auf eine Webanwendung ist der erste
kleinste Teil die Oberfläche der Einstiegsseite. Wie
diese in R/3 umgesetzt wird, soll als erstes gezeigt
werden.
Befindet
Entwicklungssystem,
man
sich
steht
in
einem
einem
R/3
mit
der
Transaktion SE80, dem Object Navigator (vgl.
2.2.4),
die
Entwicklungsumgebung
für
BSP
Anwendungen zur Verfügung.
Abbildung 3.7 – SE80 Erstellung Paket
Hier kann eine BSP-Applikation erstellt werden, welche zunächst nichts beinhaltet sondern nur
als Behälter für alle noch kommenden Komponenten dient. Zum Erstellen einer BSP-Applikation
wird zuerst ein Paket für diese benötigt. Pakete sind ihrerseits ebenfalls Behälter, Behälter für
„sachlogisch zusammenhängende Entwicklungsobjekte, die gemeinsam in ein Nachfolgesystem
transportiert werden“ (SAP® Web Application Server, S.280). Die Pakete könnten auch einfach
als Ordner zur besseren Organisation aller Komponenten gesehen werden, zumal sie im GUI
ähnlich wie in anderen Dateiverwaltungsprogrammen als solche dargestellt werden. Sollte die
Zielanwendung Teil einer insgesamt noch umfangreicheren Anwendung sein, wählt man einfach
eines derer Pakete, ansonsten muss zuvor ein neues Paket angelegt werden. Das Anlegen eines
neuen Pakets funktioniert im Objekt Navigator recht einfach. Dazu muss im Repository Browser
lediglich in der Drop Down Liste der Objekttyp Paket ausgewählt werden und im Inputfeld
darunter der Name des zukünftigen Pakets eingegeben werden. Bei der Namensgebung gilt die
56
Konvention, dass SAP-eigene Programme mit dem Buchstaben ‚S’ beginnen, einige
Kundenfirmen mit einem nur für sie reservierten Buchstaben und alle anderen Kunden mit ‚Y’
oder ‚Z’. Wird nun der Anzeigen Button
genutzt erfolgt automatisch die Abfrage zur
Erstellung des neuen Pakets (vgl. Abbildung 3.7 – SE80 Erstellung Paket), welche zur Erstellung
bejaht wird.
Erst nachdem ein Paket vorhanden ist, kann auch die BSP-Applikation, bzw. ihr Behälter, erstellt
werden. Dies ist einfach per Rechtsklick und dem dadurch angebotenen Menü möglich (vgl.
Abbildung 3.8 – SE80 Erstellung einer BSP Anwendung).
Abbildung 3.8 – SE80 Erstellung einer BSP Anwendung
3.5.6 Datenportierung
Odbc verbindung konfigurieren: Server der 3 r/3 systeme eintragen, maxdb 7.4 treiber
notwendig!
Dank der im Microsoft Betriebssystemen implementierten ODBC26 API27 läßt sich die Portierung
der Datenbank mit Hilfe eines Perl Skriptes recht einfach gestalten. Dabei müssen jedoch
26
ODBC: Open Database Connectivity
57
zunächst innerhalb der BSP Anwendung die leeren Datenbanktabellen erstellt werden. Dies
geschieht, indem man nach Rechtsklick auf das entsprechende Paket der Anwendung Anlegen
DDIC-Objekt
►
►
Datenbanktabelle (ähnlich Abbildung 3.8) auswählt. Zusätzlich zu den bisher
erwähnten Namenskonventionen (3.5.5) darf ein Datenbanktabellenname an den ersten drei
Stellen keinen Unterstrich ‚_’ beinhalten. Als Nächstes müssen unter Auslieferung und Pflege die
Auslieferungsklasse und die Tabellensicht-Pflege ausgewählt werden.
Abbildung 3.9 – Auslieferungsklassen
Als Auslieferungsklassen stehen sieben zur Verfügung, die über das
Symbol aufgelistet
werden (Abbildung 3.9), wobei A die gebräuchlichste Klasse ist. Für die Tabellensicht-Pflege
gibt es die Möglichkeiten, dass die Anzeige/Pflege

eingeschränkt erlaubt

erlaubt

nicht erlaubt
ist. In den meisten Fällen wird die Anzeige/Pflege erlaubt. Des Weiteren muss für eine neue
Datenbanktabelle über Technische Einstellungen in der Anwendungsfunktionsleiste die Datenart
(Abbildung 3.10) und die Größenkategorie (Abbildung 3.11) vor eingestellt werden.
27
API: Application Programming Interface
58
Abbildung 3.10 – Datenart
Abbildung 3.11 – Größenkategorie
Bei der Angabe der Größenkategorie ist zu beachten, dass diese dynamisch nach der reservierten
Größe für einen Datensatz berechnet wird. Nach Festlegen der einzelnen Attribute mit ihren
Feldlängen sollte also überprüft werden, ob die anfangs gewählte Größenkategorie noch
ausreicht! Vorher müssen die Attribute jedoch erst einmal gepflegt werden, was im
Werkzeugbereich unter dem Reiter „Felder“ gemacht wird.
Danach werden auf dem Microsoft SQL Server die ODBC Datenquellen angepasst bzw. erstellt,
die die Verbindung zur Datenbank der Ausgangsanwendung und zur Datenbank der
Zielanwendung darstellen und somit die Datenportierung zwischen den beiden ermöglichen
sollen.
Dies geschieht auf dem Datenbankserver (MS SQL 2000) unter Programs->Administrative
Tools->Data Sources (ODBC) (vgl. Abbildung 3.12)
Abbildung 3.12 – ODBC Datenquellen Administrator öffnen
59
Abbildung 3.13 – ODBC Datenquellen Administrator
Dort können unter System DSN28 neue Datenquellen angelegt oder bestehende konfiguriert
werden (vgl. Abbildung 3.13). Auf jeden Fall wird eine Verbindung zur Datenbank der
Ausgangsanwendung gebraucht, um die Daten per Perl Skript auszulesen. Als Treiber für diese
Datenquelle muss der SQL Server Treiber (vgl. Abbildung 3.13) verwendet werden. Im
nachfolgenden Dialog muss der Datenquelle ein eindeutiger Name vergeben werden, während
eine Beschreibung der Datenquelle optional ist. Sollte der Server der Datenquelle jedoch von
ihrem Namen abweichen, muss er noch explizit angegeben werden, da mit dem Namen als Server
natürlich keine funktionierende Verbindung hergestellt werden kann. Im nächsten Schritt des
Dialoges wird die Prüfung der Authentizität des Benutzers der Datenquelle bestimmt. Für die
Zwecke des Perl Skriptes eignet sich ein fester Benutzer, der als einziger die Berechtigung zum
Nutzen der Datenquelle hat. Er muss für die Datenbank mit den entsprechenden
Leseberechtigungen gepflegt sein und wird in der Datenquelle und später bei ihrer Nutzung samt
Passwort
angegeben.
Vor
dem
folgenden
Dialogschritt
testet
die
ODBC
Administrationsanwendung schon die Verbindung und kann folglich nur bei Erfolg alle auf dem
28
DSN: Data Source Name
60
Server vorhandenen Datenbanken als Quelle der Datenquelle anbieten. Alle weiteren
Einstellungen können standardmäßig bleiben und die Erstellung der Datenquelle abgeschlossen
werden.
Das Erstellen der Datenquelle zu einem R/3® ist weniger komplex. Hierzu muss bei der Auswahl
des Treibers der für eine MaxDB gewählt werden (vgl. Abbildung 3.14).
Abbildung 3.14 – ODBC Datenquellen Treiberauswahl
Sollte der MaxDB ODBC Treiber nicht in der Treiberliste aufgeführt sein, kann er unter
http://www.sapdb.org/7.4/sap_db_software.htm herunter geladen werden. Im Dialog nach der
Auswahl des Treibers muss lediglich wieder ein eindeutiger Name für die Datenquelle vergeben
werden, sowie der Name der R/3 Datenbank mit der sich verbunden werden soll und der
Servername des Datenbankrechners. I.d.R. ist der Datenbankname mit dem des Systemnamens
identisch.
Nachdem die Verbindungen zu den Datenbanken per Datenquellen hergestellt wurden, kann das
Perl Skript29 angepasst werden. Beim Anpassen des Perl Skriptes muss folgendes beachtet
werden:

29
grün Geschriebenes sind Kommentare
Das Skript wurde aus einem bereits durch meinen Betreuer Andreas Mazzola programmierten angepasst
61

blau Geschriebenes sind Variablennamen oder Teile davon, die zum besseren Verständnis
in aussagekräftigere Namen umgewandelt werden können, die sich direkt auf die zu
portierende Datenumgebung beziehen (Bsp.: die Ausgangsdatenbank heißt ‚DB_Einkauf’,
NameQuellDB wird also in DB_Einkauf umgewandelt)

rot Geschriebenes sind Bezeichnungen, die zum Funktionieren des Perl Skriptes unbedingt
an
die
zu
portierende
Datenumgebung
angepasst
werden
müssen!
So
muss
NameQuellDSN exakt der Name sein, mit dem vorhin die ODBC Datenquelle zur
Ausgangsdatenbank benannt wurde. Auch Tabellennamen und Attribute müssen die Namen
haben, mit denen sie angelegt wurden. Das gleiche gilt für Benutzer, ihre Passwörter und
Pfadangaben.
Programmkode 3.1 – anzupassendes Perl Skript für Datenportierung
use Win32;
use Win32::ODBC;
use Sys::Hostname;
#################################################################
# globale Variablen
#################################################################
# System DSNs für Datenbankverbindungen zu Ausgangs- und
Zieldatenbank
$SYSTEM_DSN_NameQuellDB = "NameQuellDSN";
# Ausgangsdatenbank
(lesen)
$SYSTEM_DSN_NameZielDB = "NameZielDSN"; # Zieldatenbank
(schreiben)
$Data_NameQuellDB = new
Win32::ODBC("dsn=".$SYSTEM_DSN_NameQuellDB."; UID=UsernameQuelle;
pwd=PasswortQuelle");
$Data_NameZielDB = new
Win32::ODBC("dsn=".$SYSTEM_DSN_NameZielDB."; UID=UsernameZiel;
pwd=PasswortZiel");
# Konstanten
$HOST = hostname;
# lokaler
Rechnername
$LOGOrdner = "\\\\".$HOST."\\LogOrdnerPfad"; # LogOrdner
$LOGDatei = $LOGOrdner."NameLogDatei.log";
# absoluter
Pfad
62
$LOGDateiGroesze = 1000000;
Dateigröße
# max
#################################################################
# Hauptprogramm
#################################################################
&Log($LOGDatei,"Skript gestartet");
&PortiereDaten();
Datenportierung
# Aufruf der Funktion zur
# Close Database Connections
$Data_NameQuellDB ->Close();
$Data_NameZielDB ->Close();
#################################################################
# Funktionen
#################################################################
#---------------------------------------------------------------# PortiereDaten
#---------------------------------------------------------------sub PortiereDaten
{
&Log($LOGDatei,"portiert Daten...");
print "portiert Daten…";
Fenster
# Ausgabe DOS
my %hash = ();
my $VarQuellPrimärschlüssel, $VarQuellAttribut02,
$VarQuellAttribut03, $VarQuellAttribut04, $err;
my $index=0;
# Zählvariable für Array
my @liste,$id,$fehler;
)
# eventuell vorhandene Daten in Zieltabelle löschen
if ( $Data_NameZielDB->Sql("DELETE FROM NameZielDBTabelle")
{
$fehler = Win32::ODBC::Error();
&Log($LOGDatei,$fehler);
}
# Selektion ganzer Tabelle könnte zu viele Daten für Skript
bedeuten -> Selektion wird zweigeteilt
# 1.Teil der Selektion:
# Selektieren aller Primärschlüssel
if( $Data_NameQuellDB->Sql("Select DISTINCT
NameQuellPrimärschlüssel from NameQuellDBTabelle ") )
{
$fehler = Win32::ODBC::Error();
&Log($LOGDatei,$fehler);
63
}
# schreiben der Primärschlüssel in ein Array
while($Data_NameQuellDB->FetchRow())
{
%hash = $Data_NameQuellDB->DataHash;
$liste[$index++] = $hash{'NameQuellPrimärschlüssel'};
}
$index = 0;
# 2. Teil der Selektion:
# Array der Primärschlüssel wird durchlaufen
foreach $id (@liste)
{
# Primärschlüsseldaten aus Tabelle holen
if( $Data_NameQuellDB->Sql("Select
NameQuellPrimärschlüssel,
NameQuellAttribut02,NameQuellAttribut03,NameQuellAttrib
ut04 from NameQuellDBTabelle where
NameQuellPrimärschlüssel = '".$id."' ") )
{
$err = Win32::ODBC::Error();
&Log($LOGDatei,$id." :".$fehler);
}
while($Data_NameQuellDB->FetchRow())
{
%hash = $Data_NameQuellDB->DataHash;
$VarQuellPrimärschlüssel =
$hash{'NameQuellPrimärschlüssel'}
$VarQuellAttribut02 =
$hash{'NameQuellAttribut02'};
$VarQuellAttribut03 =
$hash{'NameQuellAttribut03'};
$VarQuellAttribut04 =
$hash{'NameQuellAttribut04'};
# Primärschlüsseldaten in Zieltabelle schreiben
if ( $Data_NameZielDB->Sql("INSERT INTO
ZielDBTabelle
(NameZielPrimärschlüssel,NameZielAttribut02,NameZi
elAttribut03,NameZielAttribut04)
VALUES('$VarQuellPrimärschlüssel','$VarQuellAttrib
ut02','$VarQuellAttribut03','$VarQuellAttribut04')
"))
{
$fehler = Win32::ODBC::Error();
&Log($LOGDatei,$fehler." Primärschlüssel =
".$VarQuellPrimärschlüssel);
}
}
}
}
# Ende PortiereDaten ------------------------------------------------64
#--------------------------------------------------------------------# Log
schreibt Strings in die LogDatei
# Parameter:
1. LogDateiPfad
#
2. LogString
#--------------------------------------------------------------------sub Log
{
my $logZeit = localtime(time);
# löschen und anlegen der Logdatei bei überschrittener max.
Größe
if ((-s $_[0]) >= $LOGDateiGroesze )
{
unlink($_[0]) || die return 0;
open(WRITE,"> ".$_[0]) || die return 0;
}
# hinzufügen neuer Logdaten an bestehende/zu erstellende
Logdatei
else { open(WRITE,">> ".$_[0]) || die return 0 }
print WRITE $logZeit.": ".$_[1]."\n";
Fenster
close(WRITE);
return 1;
}
# Ausgabe DOS
# Ende Log -----------------------------------------------------------
Nun kann das Perl Skript auf dem Rechner, auf dem vorhin die ODBC Datenquellen angelegt
wurden ausgeführt werden. Sollte dort noch kein Perl installiert sein, kann man sich auf
http://www.activestate.com/Products/ActivePerl/
eine
der
gängigsten
Perl
Versionen
herunterladen und installieren.
Da die Datenbankinhalte beim Transport zwischen den R/3 Instanzen (Integrations-,
Konsolidierungs- und Belieferungssystem) nicht mit transportiert werden, ist die Portierung zu
jedem einzelnen der drei Systeme nötig. Dazu muss aber lediglich in der Datenquelle, das
Zielsystem mit seinen Zugangsdaten geändert werden, bevor das Perl Skript einfach ein weiteres
mal ausgeführt wird.
65
3.5.7 Umsetzung
Nun sind alle Vorbereitungen getroffen, um zum ersten sichtbaren Teil der Anwendung zu
kommen. Nachdem bisher nur die Theorie des MVC Design Pattern und dessen strikter Trennung
von
Präsentations-,
Ablauf-
und
Anwendungslogik erwähnt wurde, soll nun
dessen Umsetzung in der Praxis gezeigt werden.
Dazu wird als Element der Präsentationslogik
ein View angelegt. Zur Erzeugung eines Views
wählt man im durch Rechtsklick angezeigten
Menü einer BSP Anwendung das Anlegen einer
Seite (vgl. Abbildung 3.15). Beim Anlegen der
Seite
wird
dann
der
Seitentyp
vom
Abbildung 3.15 – SE80 Menü BSP Anwendung
standardmäßigen Seite mit Ablauflogik in View geändert. In den Eigenschaften dieses Views ist es
noch sehr wichtig, beim Seitentyp auch die Controllerklasse zur Ablaufsteuerung anzugeben.
Standardmäßig steht dort noch die Basisklasse
CL_BSP_CONTROLLER2,
von der alle Controller
abgeleitet werden.
Die Oberfläche der Einstiegsseite wird im dafür angelegten View mit HTMLB umgesetzt (vgl.
2.2.3).
Enthält diese ein Formular, welches Benutzerdaten weitergibt.
3.6 Portierungsschrit 6/6: Nacharbeiten
Wie zu jeder Softwareentwicklung gehört auch zur Portierung eine Dokumentation. Dabei kann
in der Funktionsbeschreibung jedoch größtenteils, wenn nicht sogar komplett, die Dokumentation
der Ausgangsanwendung übernommen werden.
66
4 Anwendung und Prüfung des Portierungsverfahrens
Nachdem nun im voran gegangenen Kapitel in der Theorie eine sinnvoll erscheinende
Vorgehensweise zur Portierung entwickelt wurde, soll diese nun auch am praktischen Beispiel
einer vorzunehmenden Portierung geprüft werden.
4.1 Kennen Lernen der Ausgangsanwendung
Die Anwendung, die zur Prüfung des im vorigen Kapitel entwickelten Portierungsverfahrens
portiert wird, stellt eine Suche über alle von der SAP Hosting betreuten Server dar. Dabei gibt es
eine für den Anwender einfache Suche („Simple“) und eine Expertensuche („Expert“), wobei
während dieser Diplomarbeit zunächst nur die umfangreichere einfache Suche portiert wird. Im
Zusammenhang dieser Suchanwendung bedeutet „einfach“, dass der Anwender kein SQL Wissen
braucht und das Suchformular dementsprechend benutzerfreundlich mit umso komplexerer
Ablauflogik im Hintergrund gestaltet ist. Die einfache Suche ist also viel aufwendiger
umzusetzen als die Expertensuche und gilt somit als oberflächenintensiver (s. 3.1.1, S. 28).
67
Abbildung 4.1 – Oberfläche des Suchformulars der Ausgangsanwendung
In der einfachen Suche kann der Benutzer bis zu vier Suchkriterien angeben (vgl. Abbildung 4.1).
Dabei stehen alle möglichen Suchkriterien als Auswahlliste zur Verfügung. Je nach gewähltem
Kriterium wird dann zwei Felder weiter Freitexteingabe, eine Auswahlliste mit „JA“ und „NEIN“
oder eine Auswahlliste mit diversen Datenbankeinträgen angeboten. Dies kommt daher, dass
manche Suchkriterien alle möglichen Werte haben (z.B. Backup Host Name, Backup IP
Address), andere nur vorhanden oder eben nicht sind (z.B. Alerting, Backup, …) und wieder
andere eine sehr begrenzte und aus der Datenbank dynamisch zu erfahrende festgelegte Menge an
Werten haben (z.B. Cost Center, Country, …). Zwischen dem Suchkriterium und dessen Wert
kann noch angewählt werden, ob das gewählte Suchkriterium den angegebenen Wert haben soll
oder alle anderen außer diesem. Insgesamt lassen sich so vier Bedingungen für eine Suche
verknüpfen, wobei dasselbe Suchkriterium mehrfach verwendet werden kann. Die einzelnen
Suchkriterien können auch mit UND verknüpft werden, während standardmäßig eine ODER
Verknüpfung vorliegt.
Des Weiteren kann der suchende Benutzer entscheiden, welche Informationen ihm in welcher
Reihenfolge zu jedem Treffer in der Ergebnisliste ausgegeben werden sollen. Da manche
Rechner mehrere IPs oder Namen haben, kann deren vollständige Ausgabe durch Anwählen der
entsprechenden Checkboxen herbeigeführt werden.
Sind alle Angaben gemacht, wird durch Drücken des Suche (Search) Knopfes, die gewünschte
Suche ausgeführt und ihr Ergebnis in Form einer Tabelle in einem weiteren Browserfenster
Abbildung 4.2 – Darstellung des Suchergebnisses der Ausgangsanwendung
angezeigt (vgl. Abbildung 4.2).
68
Dieses bietet zunächst das Erstellen einer Exceldatei für die Ergebnistabelle per Knopfdruck an.
Darunter wird die Ergebnistabelle anhand von HTML dargestellt. Dabei werden zusätzlich zu den
vom Benutzer gewünschten Ausgabeinformationen Datum und Uhrzeit der Suche, eine
Kurzdarstellung der gewählten Suchkriterien, ihrer Werte und der eventuellen Verknüpfungen
mehrerer Kriterien, sowie ein Zeilenindex mit ausgegeben.
Oberflächlich betrachtet, besteht die Anwendung also aus zwei HTML Dateien, von denen eine
das Suchformular anbietet und die andere das Suchergebnis darstellt. Ein genauerer Blick in die
Anwendung zeigt jedoch, dass noch eine weitere Datei einbezogen wird. Das dynamische
Befüllen der Auswahlliste für Suchkriterien, deren mögliche Werte aus der Datenbank geholt
werden, wird per Remote Scripting30 von einer dritten Datei übernommen.
Auf die Darstellung des absolut genauen Kennen Lernens der Anwendung möchte ich an dieser
Stelle verzichten, da dies erstens schwer möglich ist und zweitens für den Leser recht
uninteressant ist.
4.2 Machbarkeitsprüfung
Während des kennen Lernens lässt sich bereits feststellen, welche Funktionalitäten der
Ausgangsanwendung den normalen Standardumfang einer Programmiersprache überschreiten.
Im Falle der Ausgangsanwendung bewerte ich das ASP Remote Scripting als größte
Sonderfunktion. Weshalb ich zunächst prüfen werde, ob und wie diese auf die BSP Technologie
zu übertragen ist.
Eine ähnliche Funktionalität gibt es wie erwartet in ABAP oder BSPs nicht.
30
Remote Scripting: ermöglicht (trotz geschlossener HTTP Verbindung nach Seitenaufbau auf Client Seite)
Datentransfer von Client zu Server und zurück ohne neuen Seitenaufbau
69
4.3 Analyse der Ausgangsanwendung
4.4 Optimierung
4.5 Implementierung der BSP Anwendung
4.6 Nacharbeiten
70
5 Zusammenfassung und Ausblick
Zusammenhang: kritische Auseinandersetzung aufgrund der Ergebnisse aus 4 und Ausblick für
die Zukunft
http://dynasys.systemnews.com/77/1/sw/index.shtml?13372#13372
Inhalt: Verlauf und Umsetzung der Arbeit
Kritische Bewertung des Portierungskonzeptes: wahrscheinlich nicht umfassend, da nicht alle
möglichen ASP Elemente und deren Portierung dargestellt wurden.
Vorschläge für die Zukunft: automatisierte Portierung (Bsp.: Microsoft ? zu .NET)
71
A. Anhang
A.a. Glossar spezifischer Ausdrücke und Abkürzungen
Abkürzung
Langform
SAP
Systeme, Anwendungen, Produkte
72
Erläuterung
A.b. Abbildungsverzeichnis
Abbildung 1.1 – IT Administration Portal ..................................................................................... 10
Abbildung 1.2 – IAC Menü............................................................................................................ 11
Abbildung 2.1 – Einordnung des Web AS in die 3-Schichten-Architektur, Architektur und
mögliche Technologien (kursiv geschrieben) des SAP® Web AS selbst ............................... 17
Abbildung 2.2 – SAP Easy Access, gesamte Oberfläche .............................................................. 20
Abbildung 2.3 – SAP Easy Access, Symbolfunktionsleiste .......................................................... 20
Abbildung 2.4 – Object Navigator ................................................................................................. 21
Abbildung 2.5 – R/3 Systemlandschaft mit 3 Instanzen ................................................................ 23
Abbildung 2.6 – Abfrage nach Transportauftrag ........................................................................... 24
Abbildung 2.7 – Erstellung eines Transportauftrags ...................................................................... 24
Abbildung 2.8 – SE80 Freigabe eines Transportauftrags .............................................................. 25
Abbildung 2.9 – STMS Liste aller Transportaufträge zum Import ................................................ 26
Abbildung 2.10 – STMS Import eines Transportauftrags .............................................................. 27
Abbildung 3.1 – Top Down............................................................................................................ 29
Abbildung 3.2 – Bottom Up ........................................................................................................... 30
Abbildung 3.3 – Anlegen eines Data Dictionary Objektes ............................................................ 37
Abbildung 3.4 – 1. Normalisierung einer Tabelle ......................................................................... 52
Abbildung 3.5 – 2. Normalisierung einer Tabelle ......................................................................... 53
Abbildung 3.6 – 3. Normalisierung einer Tabelle ......................................................................... 55
Abbildung 3.7 – SE80 Erstellung Paket ......................................................................................... 56
Abbildung 3.8 – SE80 Erstellung einer BSP Anwendung ............................................................. 57
Abbildung 3.9 – Auslieferungsklassen........................................................................................... 58
Abbildung 3.10 – Datenart ............................................................................................................. 59
Abbildung 3.11 – Größenkategorie ................................................................................................ 59
Abbildung 3.12 – ODBC Datenquellen Administrator öffnen ...................................................... 59
Abbildung 3.13 – ODBC Datenquellen Administrator .................................................................. 60
Abbildung 3.14 – ODBC Datenquellen Treiberauswahl ............................................................... 61
Abbildung 3.15 – SE80 Menü BSP Anwendung ........................................................................... 66
Abbildung 4.1 – Oberfläche des Suchformulars der Ausgangsanwendung ................................... 68
73
Abbildung 4.2 – Darstellung des Suchergebnisses der Ausgangsanwendung ............................... 68
74
A.c. Tabellenverzeichnis
Tabelle 3.1 – Datentypen ............................................................................................................... 42
Tabelle 3.2 – JavaScript Eventhandler und BSP ControllerklassenmethodenError!
Bookmark
not defined.
Tabelle 3.3 – Übersicht über HTMLB Elemente ........................................................................... 44
A.d. Programmkodeverzeichnis
Programmkode 3.1 – anzupassendes Perl Skript für Datenportierung........................................... 62
75
5
A.e. Literaturverzeichnis
www.saphosting.de
www.selfhtml.teamone.de
www.learnasp.com
http://www.itb.uni-stuttgart.de/lectures/Programmieren/Xiaolei/Bioinfor02_O.ppt
http://mysap.wdf.sap.corp:2080/resources/htmlb_guidance/
http://sql.idv.edu/thema/normalform/doc.htm
http://de.wikipedia.org/wiki/Normalisierung
“Active Server Pages”, Jörg Krause, Addison-Wesley
“SAP® Web Application Server”, Frédéric Heinemann, SAP™ Press
“ABAP Objects® – Einführung in die SAP®-Programmierung”, Horst Keller, Sascha Krüger,
SAP™ Press
“SAP® R/3® Systemadministration – Basiswissen für das R/3®-Systemmanagement“, Liane Will,
SAP™ Press
„Arbeitsmaterial zur Vorlesung Informatik 3“ Prof. Wilhelm Walter, (Oktober 2001).
Fachhochschule Furtwangen
76