Seminar PIiii
Werbung
Seminarvortrag Datenbankauswertungsmöglichkeiten moderner ERP - Systeme am Beispiel SAP R/3 Vergleich ABAP vs. Quick View Sven Adolph Vorgelegt bei Prof. Dr. Guido Moerkotte Lehrstuhl Praktische Informatik III Vorgelegt von Diplom-Wirtschaftsinformatiker Sven Adolph Aus Reilingen Inhaltsverzeichnis: 1. Einleitung..................................................................................................................................1 1.1 Motivation ...........................................................................................................................1 1.2 Aufbau der Arbeit .................................................................................................................2 2. Die betriebliche Standardsoftware SAP R/3 .................................................................................3 2.1 Technischer Aufbau..............................................................................................................3 2.2 Datenbankzugriffe in R/3 ......................................................................................................5 3. ABAP und Quick View ..............................................................................................................7 3.1 Die Programmiersprache ABAP ............................................................................................7 3.2 SAP Quick View ..................................................................................................................8 4. Fallbeispiel................................................................................................................................9 4.1 Einleitung ............................................................................................................................9 4.2 Datenmodel..........................................................................................................................9 4.3 SQL - Anweisungen und deren Umsetzung auf ABAP Open SQL .........................................10 4.4 SQL - Anweisungen und deren Umsetzung auf Quick Views.................................................14 5. Abschließender Vergleich.........................................................................................................16 ii 1. Einleitung 1.1 Motivation Der Erfolg betriebliche r Standardanwendungssysteme in den vergangenen Jahren ist vor allem auf die zunehmende Globalisierung zurückzuführen. Durch den Anstieg länderübergreifender, betriebswirtschaftlicher Aktivitäten, beispielsweise durch den Zukauf von Unternehmen im Ausland, entstand ein Bedarf an weltweit vernetzten, integrierten Systemen. Ein zusätzlicher Wartungsdruck resultierte aus der Jahr-2000 Problematik und der Einführung des Euro. Durch die Auswahl eines mächtigen ERP - Systems (Enterprise Ressource Planning) erhoffte man eine Verbesserung der globalen Prozess- und Datenqualität zu erreichen. Die Eigenentwicklung solcher Systeme gestaltet sich im Hinblick auf die unterschiedlichen länderspezifischen Anforderungen sehr schwierig. Beim Einsatz eines Standardanwendungssystems hingegen, wird bereits ein Grossteil der lokal benötigten Funktionalität "frei Haus" mitgeliefert. Um die durch den Standard nicht abgedeckten Anforderungen erfüllen zu können, besitzen heutige ERP-Systeme unterschiedliche Schnittstellen zur Erstellung benutzerdefinierter Berichte. Der folgend e Beitrag vergleicht am Beispiel SAP R/3 die Auswertungsmöglichkeiten von ABAP (Advanced Business Application Programming) und die sogenannter Quick Views. Untersucht wurden dabei die folgenden Aspekte: • Mächtigkeit • Performance • Wartbarkeit • Benutzerfreundlichkeit 1 1.2 Aufbau der Arbeit Im Anschluss an die Einleitung wird in Kapitel zwei die Architektur der betrieblichen Standardsoftware R/3 vorgestellt. Hierbei wird sich lediglich auf die Bereiche beschränkt, die für das weitere Verständnis der Arbeit notwendig sind. Hierzu gehört der dreistufige Client-Server Aufbau, das Transportwesen und die SQL Unterstützung. Daran anschließend wird in Kapitel drei in die Programmiersprache ABAP eingeführt. Die elementare Syntax wird beschrieben, die Entwicklungsumgebung wird vorgestellt und der generelle Ablauf beim Erstellen von Reports skizziert. Im zweiten Teil dieses Kapitels werden kurz die Quick Views vorgestellt. Beide Techniken werden dann ausführlich anhand einer konkreten Implementierung in Kapitel vier beschrieben. Hierbei wird anhand des Datenmodells eines Flugplans eine vorgegebene SQL - Abfrage mit Hilfe beider Techniken generiert. Abschließend werden in Kapitel fünf die gewonnenen Ergebnisse diskutiert und die wichtigsten Unterschiede beider Welten dargelegt. 2 2. Die betriebliche Standardsoftware SAP R/3 2.1 Technischer Aufbau SAP R/3 stellt ein Client-Server System dar, welches dreistufig aufgebaut ist: Abb. 1: Schichten des R/3 Systems Präsentationsschicht Die Präsentationsschicht enthält Software-Komponenten die R/3-spezifisch SAP GUI (Graphical User Interface) genannt werden. Die Präsentationsschicht bildet die Schnittstelle zu den Benutzern. Durch ihre SAP GUI-Komponenten bietet sie eine intuitiv bedienbare grafische Oberfläche, über die Benutzer Daten eingeben oder Antworten in Form von Texten oder Grafiken erhalten. Die Präsentationsschicht sendet diese Daten an die Applikationsschicht bzw. empfängt sie von dieser. Eine SAP GUI Komponente ist während ihrer Laufzeit immer fest mit einer Benutzeranmeldung an das R/3-System verknüpft. Applikationsschicht Die Softwarekomponenten der Applikationsschicht bestehen aus einem oder mehreren Applikationsservern und ein Message Server. Jeder Applikationsserver stellt eine Reihe von Diensten zum Betrieb des R/3-Systems zur Verfügung. Im 3 Prinzip genügt ein einziger Applikationsserver, um ein R/3-System zu betreiben. In der Praxis werden die Dienste meistens auf mehrere Applikationsserver verteilt, so dass nicht jeder Applikationsserver jeden Dienst zur Verfügung stellt. Der Message Server realisiert die Kommunikation zwischen den Applikationsservern. Über den Message Server können Aufträge zwischen den Applikationsservern innerhalb eines R/3-Systems weitergeleitetet werden. Weiterhin enthält der Message Server Informationen über die Gruppierung von Applikationsservern und die aktuelle Lastverteilung innerhalb der Gruppen und kann so die Anmeldung von Benutzern entsprechend beeinflussen. Datenbankschicht Ein zentrales Datenbanksystem, das alle Daten des R/3-Systems verwaltet, bildet die Datenbankschicht. Das zentrale Datenbanksystem besteht aus den Komponenten Datenbank Management System (DBMS) und der eigentlichen Datenbank (Datenbestand). SAP stellt selbst kein eigenes Datenbanksystem zur Verfügung1 . Die Datenbank enthält nicht nur die betriebswirtschaftlichen Daten (Stammdaten und Bewegungsdaten) der Anwendungsprogramme, sondern ist die zentrale Datenablage für das gesamte R/3-System. Insbesondere enthält die Datenbank also auch Steuerungs- und Customizingdaten, die das Verhalten des R/3-Systems festlegen, sowie die Anwendungsprogramme selbst. Anwendungsprogramme bestehen aus Programmtexten, Bildschirmdefinitionen, Menüs, Funktionsbausteinen usw. Diese Komponenten werden in einem speziellen Teil der Datenbank abgespeichert, der R/3-Repository genannt wird, und heißen deshalb auch Repository-Objekte. Repository-Objekte werden mit der ABAP Workbench bearbeitet. 1 Das R/3-System unterstützt stattdessen folgende Datenbanksysteme anderer Hersteller: ADABAS D, DB2/400 (auf AS/400), DB2/Common Server, DB2/MVS,INFORMIX, Microsoft SQL Server, ORACLE und ORACLE Parallel Server. 4 2.2 Datenbankzugriffe in R/3 Um Unverträglichkeiten zwischen verschiedenen Datenbanktabellen zu vermeiden und das R/3-System unabhängig vom verwendeten Datenbanksystem zu machen, enthält jeder Workprozess auf einem Applikationsserver eine Datenbankschnittstelle. Das R/3-System kommuniziert ausschließlich über die Datenbankschnittstelle mit der Datenbank. Die Datenbankschnittstelle verwandelt alle Anforderungen des R/3Systems in herstellerspezifische Standard SQL-Anweisungen. Hierfür enthält die Datenbankschnittstelle Unterschiede eine zwischen datenbankabhängige den Komponente, Datenbanksystemen vor welche die Rest der dem Datenbankschnittstelle verbirgt. Diese Komponente wird bei der Installation des R/3Systems entsprechend der verwendeten Datenbank ausgewählt. Abb. 2: Datenbankzugriff im R/3 Die Programme des R/3-Systems haben zwei Möglichkeiten auf die Datenbankschnittstelle zuzugreifen, nämlich Open SQL und Native SQL. Open SQL Die Anweisungen von Open SQL sind eine vollständig in ABAP integrierte Untermenge von Standard SQL. Sie erlauben dem ABAP-Programmen einen einheitlichen Zugriff auf Daten, unabhängig vom installierten Datenbanksystem. 5 Open SQL umfasst den DML-Anteil (Data Manipulation Language) des Standards, erlaubt es also Daten zu lesen (SELECT) und zu verändern (INSERT, UPDATE, DELETE). Open SQL geht aber auch über den Standard hinaus, indem es einige Anweisungen anbietet, die im Zusammenhang mit den übrigen ABAP-Elementen, bestimmte Zugriffe vereinfachen oder beschleunigen können. Zusätzlich bietet Open SQL die Möglichkeit, bestimmte Tabellen auf dem Applikationsserver zu puffern und dadurch Datenbankzugriffe einzusparen. Dabei übernimmt die Datenbankschnittstelle die Kontrolle über die Abgleichung der Puffer mit der Datenbank. Die Puffer sind teilweise im Arbeitsspeicher des aktuellen Workprozesses und teilweise im gemeinsamen Speicher aller Workprozesse eines Anwendungsservers abgelegt. Bei R/3-Systemen, die auf mehrere Anwendungsserver verteilt sind, werden die Daten in den verschiedenen Puffern durch das PufferManagement in festgelegten Zeitabschnitten synchronisiert. Bei der Datenbankpufferung muss man also in Kauf nehmen, dass die Daten in den Puffern nicht immer aktuell sind. Deshalb wendet man Datenbankpufferung eher bei wenig veränderlichen Daten an. Ob eine Tabelle gepuffert wird, wird im ABAP Dictionary bei ihrer Definition festgelegt Native SQL Native SQL ist nur sehr lose in ABAP eingebunden und erlaubt Zugriff auf den gesamten Umfang der Funktionalität, der von der Programmierschnittstelle des Datenbanksystems zur Verfügung gestellt wird. Native SQL Anweisungen werden im Gegensatz zu Open SQL nicht geprüft und übersetzt, sondern direkt an das Datenbanksystem gereicht. Im Falle vo n Native SQL ist die Funktionalität der datenbankabhängigen Schicht nur minimal. Ein Programm, das Native SQL verwendet, ist abhängig vom installierten Datenbanksystem. Bei der Entwicklung von allgemeingültigen R/3-Anwendungen sollte auf den Einsatz von Native SQL weitestgehend verzichtet werden. In einigen Basis-Komponenten des R/3-Systems wird Native SQL verwendet, z.B.: im ABAP Dictionary zum Anlegen oder Ändern von Tabellen. 6 3. ABAP und Quick View Wie bereits erwähnt, erfolgen die Zugriffe auf die Datenbank ausschließlich über ABAP Programme. Direkte SQL - Statements können innerhalb R/3 nicht ausgeführt werden. Hierdurch entstünde die Möglichkeit, das interne Berechtigungskonzept zu umgehen. Für das Erstellen solcher Abfragen (REPORTS) steht die Programmiersprache ABAP (Advanced Business Application Programming) zur Verfügung. Bedingt durch die dreistufige Client-Server Architektur werden zudem die Daten nie direkt von der Datenbank and das GUI übermittelt. Vielmehr werden die Anfrageergebnisse auf dem Applikationsserver in internen Tabellen zwischengespeichert. Um dies zu ermöglichen, müssen diese interne Tabellen im Programm definiert werden. Je nach Einstellungen des User Interface werden die gespeicherten Daten dann auf einmal oder in Schüben zu dem Anwender übertragen. Quick Views setzen auf dieser Struktur auf. In Verbindung mit einer grafische n Benutzeroberfläche können per Drag & Drop einfache Berichte erzeugt werden. Auf beide Techniken wird im Folgenden genauer eingegangen. 3.1 Die Programmiersprache ABAP Ein einfaches ABAP Programm zur Datenbankabfrage 2 besitzt folgende Struktur: • Datendefinition • Datenbankabfrage • Ausgaberoutine In der Datendefinition werden die interne n Tabellen definiert, die die Daten, die über eine SQL Anweisung von der Datenbank geholt werden, zwischenspeichern. Diese Daten befinden sich dann im Speicher des Applikationsservers. Die Datendefinition 2 ABAP Programme gehen weit über reine Datenbankabfragen hinaus. Es ist möglich komplette Applikationen (incl. Masken, Berechtigungen, komplexe Berechnungen) zu implementieren, die keine einzige Datenbankabfrage besitzen. 7 sorgt auch dafür, dass genügend Arbeitsspeicher für die zu empfangenden Daten reserviert wird. Im zweiten Teil des ABAP Programms erfolgt der Zugriff auf die Datenbank. Hierzu steht sowohl die Open SQL, als auch die native SQL Syntax zur Verfügung. Nachdem die Daten auf dem Applikationsserver nun zur Verfügung stehen, können sie an den Benutzer übermittelt werden. Der dritte Teil des ABAP Programms definiert die Art und Weise, wie die Daten auf dem Bildschirm dargestellt werden. Neben der Darstellung kann auch eine komplette Programmlogik definiert werden, die Daten basierend auf weiteren Benutzereingaben verändert. Um den laufenden Betrieb einer SAP R/3 Anwendung im produktiven System durch fehlerhafte Programme nicht zu beeinträchtigen, werden in der Regel mehrere Instanzen eines R/3 Systems implementiert. Ein System zum Erstellen der Programme (Entwicklungssystem), ein Integrationssystem (zum Testen) und das eigentliche Produktionssystem. Die im Entwicklungssystem erstellten Programme werden über ein sogenanntes Transportsystem zunächst in das Testsystem und nach erfolgreichem Test in das Produktionssystem eingecheckt. 3.2 SAP Quick View Im Unterschied zu der Programmiersprache ABAP wird bei den Quick Views nicht ein Programm mittels Zeileneditors sondern mit Hilfe einer grafischen Benutzeroberfläche erstellt. Über Auswahlboxen können per Drag & Drop einfache Berichte erzeugt werden. Die aufgezeichneten Benutzeraktionen werden dann vom System in ABAP - Code umgewandelt. Dieser Code ist zwar innerhalb der Entwicklungsumgebung von R/3 zugänglich, sollte aber nicht manuell editiert werden, da sonst die Administration und Pflege des Quick Views nicht mehr möglich ist. Quick Views sind primär für einmalige ad hoc Abfragen gedacht. Sie werden meist direkt im Produktionssystem vom Endanwender generiert. Das folgende Kapitel vergleicht beide Techniken exemplarisch anhand eines konkreten Beispiels. 8 4. Fallbeispiel 4.1 Einleitung Um die Reportingmöglichkeiten von ABAP REPORTS und SAP Quick Views anschaulich vergleichen zu können, soll das Vorgehen beider Werkzeuge an einer Beispielimplementierung erläutert werden. Benutzt wird dazu das Datenmodel eines Flugplans. Annhand der verwendeten Tabellen werden dann Reports mit Hilfe von ABAP und SAP Quick Views erstellt. Abschließend erfolgt eine Gegenüberstellung beider Werkzeuge. 4.2 Datenmodel Das Flugdatenmodel besteht aus drei Tabellen: • Flugplan (SPFLI), indem die möglichen Verbindungen eingetragen sind • Flüge (SFLIGHT), indem die tatsächlich stattfindenden Füge ausgeprägt sind • und die Tabelle Flugbuchung (SBOOK) in der die Passagierinformationen für die auf SFLIGHT referenzierenden Flüge stehen Abb. 3: Flugdatenmodell 9 4.3 SQL - Anweisungen und deren Umsetzung auf ABAP Open SQL Anhand des oben vorgestellten Datenmodells soll nun die folgende SQL Abfrage und deren Umsetzung in Open SQL betrachtet werden: SELECT FLDATE, CITYFROM,CITYTO FROM SPFLI, SFLIGHT WHERE SPFLI.CARRID = SFLIGHT.CARRID AND SFLI.CONNID = SFLIGHT.CONNID AND SPFLI.CITYFROM = 'FRANKFURT" Die obige SQL Anweisung liefert alle stattfindenden Flüge vom Airport Frankfurt zurück. Um diese Informationen im SAP R/3 zu extrahieren, muss hierzu zunächst ein ABAP Programm angelegt werden: Abb.4: Fallbeispiel: ABAP Report 10 Zu Beginn eines jeden Programms sollte der Programmierer mit Hilfe von Kommentaren einige Angaben zur Aufgabe des Programms machen. Danach wird mit Hilfe des Schlüsselworts REPORT der nachfolgende Text als Pogrammcode bekannt gemacht. Daran anschließend werden globale Daten deklariert 3 . Für unsere Abfrage benötigen wir eine interne Tabelle, die aus 3 Spalten der Datenbanktabelle SPFLI und einer Spalte der Datenbanktabelle SFLIGHT besteht. Durch das Schlüsselwort LIKE kann die Datenstruktur von bestehenden Feldern übernommen werden. Der dem Datenteil folgende Programmteil enthält die SAP R/3 Open SQL Anfrage. Der in SQL übliche Punkt, der Attribute mit Hilfe der zugehörigen Tabelle vollständig qualifiziert, wird in ABAP durch eine Tilde realisiert. Die durch den SQL Ausdruck von der Datenbank zurückgelieferten Ergebnisse werden auf dem Applikationsserver im Hauptspeicher gehalten. Für die Übermittlung an das GUI stehen Standardausgaben zur Verfügung. In unserem Beispiel sorgt die LOOP Schleife für das seque ntielle Lesen der internen Tabelle und die Übermittlung der Daten an den Benutzer. Wird das Programm ausgeführt erhält man folgende Ausgabe: Abb. 5: Standardlistenausgabe 3 ABAP bietet die Möglichkeit innerhalb von Programmblöcken lokale Daten mit verkürzter Lebensdauer zu definieren. Auf diese Technik wird im folgenden nicht näher eingegangen. 11 In der Praxis ist ein solcher Bericht recht unflexibel, da die Selektionsbedingungen (Auswahl des Abflughafens) hart im Programm codiert sind. Der Benutzer möchte oftmals die relevanten Kriterien selbst bestimmen. Eine Abänderung des Programms ist mit Hilfe der von SAP bereitgestellten Entwicklungsumgebung möglich. Zusätzlich wird bei Programmänderungen eine Versionsverwaltung genutzt. Somit lassen sich Änderungen leicht zurücksetzen, ohne mit unterschiedlichen Programmnamen arbeiten zu müssen. Im folgenden wird das Programm so abgeändert, dass der Abflughafe n und der Maximalpreis vom Endbenutzer selbst definiert werden kann. Zusätzlich soll über ein Icon die Platzverfügbarkeit grafisch angezeigt werden. Die Einbindung solcher Symbole erfolgt über eine Grafikbibliothek, die mittels eines INCLUDE geladen wird. Die notwendige Anzeigelogik wird im Ausgabeteil implementiert. Um Selektionskriterien zur Laufzeit des Programms eingeben zu können müssen lediglich Variablen vom Typ PARAMETER definiert werden. Die Laufzeitumgebung stellt dann Standardeingabemasken zur Verfügung, die auf den jeweils gültigen Wertevorrat der Daten gegenprüfen. Hierdurch können nur Werte ausgewählt werden die sich tatsächlich in der Datenbasis befinden. Abb. 6 zeigt die von SAP zur Verfügung gestellte Entwicklungsumgebung und den geänderten Programmcode: Abb. 6: ABAP Entwicklungsumgebung und Quellcode 12 Nach Programmstart wird zunächst ein Standardeingabefenster generiert, um die Selektionsparameter eingeben zu können: Abb. 7: Standardeingabefenster Das Ergebnis der Abfrage erscheint entsprechend der Programmänderungen: Abb. 8: Modifizierte Standardausgabe Um die Kosten der SQL Abfrage abzuschätzen stellt die R/3 Entwicklungsumgebung die Möglichkeit eines Datenbanktrace zur Verfügung. Hierzu wird vor Programmstart der Trace aktiviert, das Programm wird ausgeführt und der Trace wird ausgelesen: Abb. 9: SQL Trace 13 Der Trace misst den Aufwand der Abfrage auf der Datenbank . Somit können bei langen Laufzeiten Informationen über die Ursachen angezeigt werden. Diese können dann eventuell durch Umformulierung der SQL - Abfrage oder durch einen zusätzlich angelegten Index beseitigt werden. 4.4 SQL - Anweisungen und deren Umsetzung auf Quick Views Die bereits in 4.3 SQL - Abfrage soll nun analog mit Hilfe eines Quick Views realisiert werden: SELECT FLDATE, CITYFROM,CITYTO FROM SPFLI, SFLIGHT WHERE SPFLI.CARRID = SFLIGHT.CARRID AND SFLI.CONNID = SFLIGHT.CONNID AND SPFLI.CITYFROM = 'FRANKFURT' Mit Hilfe der grafischen Benutzeroberfläche der Entwicklungsumgebung ist dies sehr intuitiv möglich. Zunächst werden die Tabellen aus dem ABAP eingefügt. R/3 erkennt automatisch die Schlüsselbeziehungen und zeigt diese an: Abb. 10: Quick View Entwicklungsumgebung / Join 14 Über die Eigenschaften des Joins werden dann sowohl die Selektionsfelder als auch die Ausgabefelder ausgewählt: Abb. 11: Quick View Entwicklungsumgebung / Feldauswahl Nachdem alle Felder grafisch ausgewählt wurden, kann der Quick View abgespeichert werden. Nachträglich kann der Quick View um weitere Felder erweitert werden. Eine Versionierung ist nicht möglich. Hierzu muss man mit unterschiedlichen Quick View Namen arbeiten. Die Implementierung einer speziellen Applikationslogik, wie in Abb. 7 dargestellt, ist mit Quick Views nicht möglich. Im Gegensatz zu ABAP können mit Hilfe von Quick Views auch nur inner Joins implementiert werden. 15 5. Abschließender Vergleich Die vorliegende Arbeit untersuchte anhand eines Fallbeispiels die Möglichkeit mit Hilfe der betriebswirtschaftlichen Anwendungssoftware SAP R/3 eigene SQL Abfragen zu implementieren. Betrachtet wurden die Programmiersprache ABAP und die Quick Views. Mit der Programmiersprache ABAP und den Quick Views stellt die SAP R/3 Umgebung Werkzeuge zur Erstellung benutzerdefinierter Berichte zur Verfügung. Beide Möglichkeiten wurden für unterschiedliche Anforderungen implementiert. Die Programmiersprache ABAP stellt die Bausteine zur Verfügung aus denen 95% des R/3 Systems bestehen. Dementsprechend vielfältig sind die Anwendungsmöglichkeiten. Die Entwicklungsumgebung von ABAP erlaubt Versionierung, Performance Trace und stellt zahlreiche Bibliotheken zur Verfügung. Programmiert werden kann allerdings erst effizient nach einem längeren ABAP Kurs. ABAP Berichte sind demnach ausgelegt auf die Erstellung zentraler Auswertungen die im Standardsystem nicht Verfügbar sind. Diese Berichte werden von mehreren Personen benutzt und müssen demnach vom Programmierer optimiert werden. Im Unterschied dazu werden die Quick Views intuitiv über eine grafische Benutzeroberfläche per drag and drop erstellt. Quick Views erlauben nur einfache Join Bedingungen. Es ist bei den Quick Views nicht möglich eine erweiterte Anwendungslogik wie etwa bei ABAP hinzuzufügen. Allerdings sind mit Hilfe von Quick Views sehr schnell Abfragen zu implementieren. Problematisch bei den Quick Views ist vor allem die mangelnde Optimiermöglichkeit. Für den Endbenutzer, der den Quick View erstellt, sind die Kosten seiner Abfrage nicht transparent. Quick Views sollten deshalb nur in Ausnahmenfällen oder nur zu einmalig benötigten "ad hoc" Abfragen benutzt werden. 16
