Diplomarbeit - Publication Server of Ostfalia University of Applied

Fachhochschule Braunschweig/ Wolfenbüttel
- University of Applied Sciences –
Fachbereich: Informatik
Fachrichtung: Medieninformatik
Diplomarbeit
vorgelegt von:
Sylvia Brink
Matr.-Nr.: 9968198
vorgelegt am:
14.12.2004
Entwicklung einer Plattform zur abteilungsübergreifenden
Pflege von BW-Objekten für das SAP Business Information
Warehouse einer Automobilbank
Angefertigt bei der Volkswagen Financial Services AG, Braunschweig
Abteilung I-SEB (Systementwicklung Business Warehouse)
1. Prüfer: Prof. Dr. rer. nat. habil. R. Rüdiger (FH BS/WF)
2. Prüfer: Dipl.-Phys. Frank Semrau (VWFSAG)
Betreuer: Dipl-Inform. Uwe Arnold (VWFSAG)
Inhaltsverzeichnis
1.
Einleitung............................................................................................. 1
1.1.
1.2.
1.3.
2.
Aufbau der Arbeit ................................................................................................................1
Motivation ...........................................................................................................................3
Volkswagen Financial Services ...........................................................................................4
Die Firma SAP und das SAP BW ........................................................ 6
2.1.
2.2.
2.3.
2.4.
2.4.1.
2.4.2.
2.4.3.
3.
Ist- und Sollzustand ........................................................................... 25
3.1.
3.2.
4.
IST-Zustand .......................................................................................................................25
SOLL-Zustand ...................................................................................................................28
Einsatz von Software-Techniken ....................................................... 31
4.1.
4.1.1.
4.1.2.
4.1.3.
4.1.4.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
4.8.
4.9.
5.
Die Firma SAP und ihre Produkte ......................................................................................6
Die MySAP-Technologie ....................................................................................................7
Das Data Warehouse............................................................................................................9
SAP BW ............................................................................................................................11
Aufbau/ Architektur ......................................................................................................11
Datenfluss .....................................................................................................................14
InfoObject .....................................................................................................................20
XML ..................................................................................................................................31
Grundlagen XML..........................................................................................................32
Die Stylesheets CSS/ XSL ............................................................................................35
Weitere XML-Begriffe .................................................................................................37
Gründe für die Entscheidung für XML .........................................................................38
Oracle-Datenbank ..............................................................................................................40
.NET Technologie..............................................................................................................43
Visual Basic.net .................................................................................................................44
ADO.net.............................................................................................................................45
ASP.net / Webserver..........................................................................................................45
Anbindung an das SAP BW: Der SAP .NET-Connector..................................................46
Die TREX-Suchmaschine..................................................................................................47
Aufbau der Dokumentationsverwaltung ............................................................................48
Anzeigen und Speichern von Daten .................................................. 50
5.1.
SAP .NET Connector.........................................................................................................50
5.1.1.
Erstellung einer Proxy-Klasse.......................................................................................50
5.1.2.
Kommunikation von .NET per SAP-Funktionsbaustein RFC_READ_TABLE..........52
5.1.3.
Verwendung eines Proxys mit VB................................................................................55
5.1.4.
Verwendung von Funktionsbausteinen und Tabellen ...................................................57
5.2.
Oracle – Datenbank vwfsdw1e ..........................................................................................58
5.2.1.
Logischer Datenbankentwurf........................................................................................58
5.2.2.
Physischer Datenbankentwurf.......................................................................................59
6.
Prozess der Erstellung eines InfoObjects und seiner Dokumentation
im SAP BW-System ..................................................................................... 66
6.1.
6.2.
6.3.
6.3.1.
6.3.2.
6.3.3.
6.3.4.
6.4.
6.4.1.
6.4.2.
7.
Erläuterung des Geschäftsprozesses ..................................................................................66
Überblick/ Hauptseite ........................................................................................................68
Erstellung von HTML-Dokumentationen aus relationalen Daten .....................................69
Anlage einer XML-Dokumentation in der Datenbank..................................................70
Transformation mittels XSL in das HTML-Format ......................................................72
Anzeige der Dokumentationen......................................................................................72
Anlage der Dokumentationen im SAP BW-System......................................................73
Anlegen eines InfoObjects im SAP BW-System ...............................................................73
Vollständigkeitsprüfung................................................................................................74
Anlage des InfoObjects per Funktionsbaustein im SAP BW........................................74
Ausblick ............................................................................................. 76
7.1.
Rollen.................................................................................................................................76
7.1.1.
Realisierung der Rollen.................................................................................................77
7.1.2.
Geschäftsprozess...........................................................................................................78
7.1.3.
Anwendungsfälle ..........................................................................................................81
7.2.
7.3.
7.4.
7.5.
7.6.
7.7.
7.7.1.
7.7.2.
7.8.
7.9.
8.
Versionisierung, Historisierung .........................................................................................85
Benutzereinstellungen........................................................................................................86
Migration vorhandener Daten in die Oracle-Datenbank....................................................87
Erweiterung um zusätzliche BW-Objekte..........................................................................88
Einführung einer weiteren Sprache....................................................................................89
Seitenaufbau/ Treeview .....................................................................................................89
Einführung und Installation ..........................................................................................89
Erklärung der Datenbank-Tabellen ...............................................................................91
Anzeige einer Online-Dokumentation ...............................................................................93
TREX/ SAP Enterprise Portal............................................................................................94
Schlusswort ....................................................................................... 96
8.1.
8.2.
8.3.
Fazit ...................................................................................................................................96
Danksagung .......................................................................................................................98
Selbständigkeitserklärung..................................................................................................98
I. Anhang................................................................................................... 99
II.
Abkürzungsverzeichnis.................................................................... 119
III.
Literaturverzeichnis ......................................................................... 120
IV.
Abbildungsverzeichnis..................................................................... 126
V.
Begriffserklärungen erstellter Programmteile .................................. 127
1. Einleitung
Diese Diplomarbeit beschäftigt sich mit der Entwicklung einer Plattform für
die abteilungsübergreifende Pflege von BW-Objekten für das SAP Business
Information Warehouse der Volkswagen Financial Services AG.
1.1. Aufbau der Arbeit
Die ersten vier Kapitel geben einen Überblick über die nötigen Grundlagen
für die Erstellung dieser Plattform. In Kapitel 1 - Einleitung ist die Motivation
für diese Arbeit dargestellt. Die Firma SAP und vor allem ihr Data-Warehouse Produkt, das SAP Business Information Warehouse (SAP BW), werden in Kapitel 2 – Die Firma SAP und das SAP BW erläutert. Dabei gewinnt
der Leser einen tieferen Einblick in den Aufbau und die Struktur des SAP
BW. Kapitel 3 - Ist- und Sollzustand schildert den Ist-Zustand und auf Basis
dieser bildet sich der konkrete Soll-Zustand mit all seinen Anforderungen
heraus. Auf Grundlage der daraus resultierenden Erfordernisse an das Softwareprogramm werden in Kapitel 4 die geeigneten Softwaretools und Techniken knapp erläutert. Das Unterkapitel XML ist aufgrund der hohen Relevanz der XML-Technik ausführlicher.
Der zweite Teil der Diplomarbeit beschäftigt sich mit der Praxis der Erstellung
einer Plattform für die Pflege von BW-Objekten. Die Vorraussetzung für eine
solche Dokumentationsverwaltung ist die Möglichkeit der Verwendung von
bereits vorhandenen Daten des SAP-Systems und die Aussicht auf Archivierung neuer und Zwischenspeicherung temporärer Daten. Daher werden in
Kapitel 5 - Datenverwaltung die Techniken des Erhalts von Daten aus dem
SAP-System mit Hilfe des SAP .NET-Connectors und der Datenbankentwurf
der neuen Oracle-Datenbank erläutert.
Die Vorgehensweise der Erschaffung einer InfoObject-Dokumentation und
der Anlage des InfoObjects im SAP BW Entwicklungssystem (FBE) wird in
Kapitel 6 - Prozess der Erstellung eines InfoObjects und seiner Dokumentation im BW beschrieben, Weiterhin werden die Implementierungstechniken
Seite 1
mit Schwerpunkt auf die in Oracle programmierten Funktionen und Prozeduren und auf den mit VB umgesetzten Code erläutert. In Kapitel 7 - Ausblick
werden zusätzliche Möglichkeiten und Methoden für den Programmausbau
angesprochen. Zum Ende der Arbeit werden in einem Schlusswort (Kapitel 8)
über die Probleme und Chancen dieser Arbeit berichtet.
Im Anhang sind die wichtigsten erstellten Programme und Dokumente zu
finden.
Seite 2
1.2. Motivation
Anlass der Diplomarbeit ist eine zunehmende Unübersichtlichkeit über die
Zusammenhänge der BW-Objekte des SAP Business Information Warehouse-Systems (kurz: SAP BW).
Die Unübersichtlichkeit ergibt sich aus dem verteilten Zugriff auf das SAP
BW System der VW FS AG. Dabei greifen verschiedene Entwicklungsabteilungen, unter anderem auch im Ausland, auf das System zu und entwickeln
Lösungen auf dieser Basis. Zudem sind diverse Quellsysteme an das SAP
BW angebunden, so dass es Bedarf gibt, vorhandene bzw. noch zu
schaffende Schnittstellen zu identifizieren. Sonst gäbe es die Gefahr, dass
gleiche Inhalte mehrfach in BW-Objekte importiert und verarbeitet werden.
BW-Objekte sind die Objekte, aus denen das SAP Business Information
Warehouse besteht. Sie erfüllen diverse technische und betriebswirtschaftliche Funktionen. Da die Anzahl von BW-Objekten durch die große Zahl von
Entwicklungen sehr stark ansteigt, verlieren die Anwender des SAP BW
immer mehr die Übersicht über Herkunft und Verwendung dieser Objekte
und verwenden so sehr viel Zeit für die Beschaffung von Informationen, die
sie an verschiedenen Orten suchen müssen.
Die Motivation dieser Diplomarbeit ist es, alle relevanten Informationen zusammenzutragen, auf Basis dieser ein Konzept zu erstellen und dieses ansatzweise zu realisieren.
Dabei sollen folgende Hauptanforderungen erfüllt sein:
Es soll eine Suchfunktion für die Recherche und das Finden von
Dokumentationen geben und ein einheitlicher Prozess zur Erstellung
und Verwaltung von Dokumentationen mit dem Ziel der Qualitätssicherung geschaffen werden. Von Vorteil ist zudem eine einheitliche Speicherung und permanente Ablage aller den BW-Objekten betreffenden
Daten in einer Datenbank. Soll ein BW-Objekt neu angelegt werden,
werden alle Parameter des BW-Objekts vorerst in der Datenbank
gespeichert um schließlich für die Anlage des BW-Objektes und seiner
Dokumentation verwendet werden zu können.
Seite 3
Für diese Hauptanforderungen wird ein Konzept erarbeitet, in dem die notwendigen Leistungsmerkmale, die die Dokumentenverwaltung haben soll,
herausgestellt, aufbereitet und in Zusammenhang gebracht werden. Basierend auf dieser theoretischen Grundlage wird ein Teil der Anforderungen
implementiert.
1.3. Volkswagen Financial Services
Die Tochtergesellschaft der VW AG ist die Volkswagen Financial Services
(VWFSAG), mit Hauptsitz in Braunschweig. Sie hat circa 4500 Mitarbeiter
weltweit und ist der größte automobile Finanzdienstleister in Europa und
bietet hauptsächlich Dienstleistungen wie die Kundenfinanzierung und das
Leasinggeschäft für Kraftfahrzeuge der Eigenmarke an.
Die VWFSAG besteht aus einer hierarchischen Organisationsstruktur.
Auf oberster Ebene befinden sich die beiden Bereiche Market-/Sales Care
Center und Service-/Support Center. Die Market Center sind für den Kundenservice der Firmen-, Privat- und Großkunden da, während die
Sales
Care Center für die Händlergeschäfte zuständig sind. Die Tätigkeiten der
Support Center dienen der gesamten Koordination der Bank (z.B. PersonalSteuerung).
Die Service Center sind Auftragnehmer der Market Center, die in diesem
Falle als Auftraggeber bzw. Kunde auftreten. Die Kosten werden intern verrechnet. Neben dem Service Center Interne Services und Customer Services
existiert das Service Center Informatik, in dem SAP Systeme und andere
Informationssysteme für die Eigennutzung entwickelt und gewartet werden.
Dieses ist unterteilt in die Bereiche Zentralfunktion, Systembetrieb und Systementwicklung 1-4. Die Systementwicklung 4, in der sich auch die Abteilung
I-SEB befindet, entwickelt und wartet die Systeme der Unternehmenssteuerung. I-SEB beschäftigt sich mit dem SAP Business Information Warehouse,
ein Data Warehouse-System, das Daten aus verschiedenen Systemen zentral zur Auswertung bereitstellt. Die Abteilung besteht aus etwa 15 internen
und 20 externen Mitarbeitern. Ihr Aufgabenbereich ist es, im Auftrag der
Seite 4
Fachbereiche Systeme und Programme für das BW zu entwickeln und die
Funktionalität und Korrektheit bestehender BW-basierter Systeme zu gewährleisten.
Weiterhin ist die Systementwicklung 1 für die Finanzierungs- und Leasingprodukte, für den ZGP (Zentraler Geschäftspartner) und für das SAP-Portal,
die Systementwicklung 2 unter anderem für den Bereich der Versicherungen
und die Systementwicklung 3 für die SAP-Systeme FI, BCA und CRM
zuständig. 1
TP
PT
Abbildung 1-1: Organisationsstruktur Informatik VWFS
TP
1
PT
[VWint2-04]
Seite 5
2. Die Firma SAP und das SAP BW
Der folgende Abschnitt gibt einen allgemeinen Überblick über die Geschichte
und aktuellen Geschehnisse der SAP und geht im Besonderen auf die Bedeutung und die Architektur des SAP Business Information Warehouse ein.
2.1. Die Firma SAP und ihre Produkte
Die Firma SAP AG, mit Sitz in Walldorf, existiert seit 1972 und stellt erfolgreich betriebswirtschaftliche Standard-Anwendersoftware her. SAP bedeutet
ursprünglich „Systeme, Anwendungen und Produkte“.
Bei dem ersten Produkt der SAP AG handelte es sich um eine Finanzbuchhaltungssoftware mit dem Namen RF. Die Software, die in Assembler programmiert wurde und unter DOS lief, ist auch unter dem Namen R/1 (Realtime-System, Version 1) bekannt. Für den Nachfolger R/2 wurde zur besseren Programmierung ABAP (Advanced Business Application Programming),
die gültige SAP-Entwicklungssprache, erfunden. Anfangs wurde ABAP nur
für die Erstellung von Reports benutzt, später wurde sie zu einer Interpretersprache.
Das heutige System R/3 wurde 1987 konzipiert und umfasst grundlegende
Neuerungen im Bereich der Client/Server-Architektur. Dieses System ist
nicht mehr nur zweiteilig, sondern besteht aus drei Schichten: der Präsentationsschicht, der Applikationsschicht und der Datenbankschicht. Weiterhin
gibt es eine Webserver-Schicht, so dass SAP-Anwendungen aus dem Webbrowser aufgerufen werden können.
Verwendet wurden in dem R/3 System auch erstmals relationale Datenbanken, einheitliche grafische Oberflächen und plattformunabhängige Anwendungen.
Zu Anfang lief R/3 nur auf UNIX-Plattformen, doch im Jahre 1993 wurde die
Portierung auf Windows vollzogen. Weitere Plattformen folgten in den Jahren
darauf. Innerhalb weniger Jahre wurde R/3 um weitere Funktionalitäten wie
die Umgestaltung zu einem objektorientierten System mit der Einführung von
Seite 6
Business Objekten und der objektorientierten Weiterentwicklung von ABAP
mit ABAP Objects ergänzt. Das Laufzeitsystem des R/3 selbst ist in den Programmiersprachen C, C++ und Java geschrieben, während die zentralen R/3
Anwenderprogramme in ABAP/4 und ABAP Objects programmiert werden.
Das R/3 System wurde in Module aufgeteilt und bietet so eine einheitliche
Sicht auf alle Daten und Geschäftsprozesse. Es werden betriebswirtschaftliche Anwendungsbereiche wie Controlling, Anlagenwirtschaft, Materialwirtschaft, Vertriebslogistik, Qualitätsmanagement und einige mehr abgedeckt.
Die bekanntesten SAP-Module sind die Module für die Bereiche Kundenverwaltung (SAP CRM, Customer Relationship Management), Finanzbuchhaltung (SAP FI, Financial Accounting), Data Warehouse (SAP BW) und Bankkunden (BCA, Bank Customer Accounts).
Diese Standardanwendungen sind an die Bedürfnisse des Betriebes
anpassbar. Eine solche Produktanpassung an Kundenwünsche nennt man
Customizing.
Die Strategie von SAP AG hat einen großen wirtschaftlichen Erfolg. Nach der
Studie „Client / Server Enterprise Applications: Leading Vendors and Market
Performance“ der IDC (International Data Corporation) vom Mai 1997 ist die
SAP AG mit dem System R/3 der weltweit erfolgreichste Anbieter unternehmensweiter betriebswirtschaftlicher Client/ Server-Anwendungen.2 In dem
TP
PT
Jahr 1995 gab es weltweit 4000 Systeme und schon im Jahr 1997 erhöhte
sich die Anzahl um das Dreifache auf 13.000 Systeme weltweit.
2.2. Die MySAP-Technologie
Mit MySAP.com bezeichnet man die Entwicklung der SAP- Standardsoftware
zu einer webbasierten E-Business-Applikation3. Diese ist im Begriff, das SysTP
PT
tem R/3 abzulösen. Es ist ein Gesamtpaket, bestehend aus unternehmensübergreifenden Prozessen und Services, Verbindungen von Endnutzern
untereinander, Geschäftsprozessen und Daten. Komponenten der MySAP-
2
TP
PT
TP
3
PT
[Buc98]
[MySAP01]
Seite 7
Technologie sind der WebApplication-Server, Portale, SAP-Module und
Anwendungen.
Der webbasierte Austausch von Daten ist möglich durch den Einsatz eines
Web Application Servers. Auf Basis dieser Technik können Webanwendungen entweder mit ABAP oder aber auch mit Java programmiert werden, da
der Web Application Server seit Version 6.2 J2EE- konform ist. Laut dem
SAP-Vorstand H. Plattner können „künftig [...] Anwendungskomponenten
gleichberechtigt entweder über ABAP-, Java Beans- oder Java-Anwendungen erstellt werden4“. Die Computerwoche schrieb weiter, dass die „Die
TP
PT
SAP AG […] auf ihrer Hausmesse Sapphire in New Orleans einen weiteren
Ausbau ihrer langjährigen Partnerschaft mit Microsoft angekündigt [hat]. Im
Mittelpunkt stehen dabei Web-Services und die Integration der SAP-Infrastruktursoftware Netweaver mit Microsofts .NET.“5.
TP
PT
Eine weitere wichtige Komponente ist das SAP Enterprise Portal. Hierbei
handelt es sich um eine einheitliche Web-Benutzeroberfläche, in der alle
SAP-Anwendungen und Non-SAP-Anwendungen vereint sind. Durch einmaliges Einloggen (single-sign-on) kann ein SAP-Anwender auf alle Anwendungen, für die er eine Berechtigung besitzt, zugreifen. Weiterhin werden der
Wissensaustausch in virtuellen Projectrooms sowie der Zugriff von außerhalb
über WebServices von diversen internetfähigen Endgeräten (PDA, PC’s)
möglich sein. Auch das SAP BW der VWFSAG wird zurzeit in das SAP
Enterprise Portal 6.0 gehoben.
4
TP
PT
TP
5
PT
[CoWo01]
[CoWo04]
Seite 8
2.3. Das Data Warehouse
„Ein Data Warehouse (deutsch: Datenlager) ermöglicht eine globale Sicht auf
heterogene und verteilte Datenbestände, indem die für die globale Sicht relevanten Daten aus den Datenquellen zu einem gemeinsamen konsistenten
Datenbestand zusammengeführt werden.“6
TP
PT
Das Konzept des Data-Warehouse-Systems wurde 1992 von Immon eingeführt. Er definierte auch als Erster den Begriff Data- Warehouse:
„A data warehouse is a subject-oriented, integrated, non-volatile, time-variant
collection of data in support of management’s decisions.”7 8
TP
PT
TP
PT
Subject-oriented bedeutet, dass der Informationsbedarf von Entscheidungsträgern durch die Unterstützung übergreifender Auswertungsmöglichkeiten
aus verschiedenen Perspektiven gedeckt werden soll. Subjekte sind hierbei
z.B. Produkt und Kunde.
Mit integrated ist eine integrierte Datenbasis gemeint, in welcher Daten aus
diversen Datenquellen zusammengefasst sind. Da diese Daten langfristig
(time-variant) gespeichert werden, ist es möglich, auf dem Faktor Zeit basierende Analysen durchzuführen. Eine stabile und persistente (nonvolatile)
Datenbasis garantiert, dass Informationen nicht mehr entfernt und geändert
werden können.
Dieses besagt, dass Daten aus verschiedenen Quellsystemen einheitlich im
Data Warehouse existieren, wo sie zur weiteren Verwendung bereitliegen.
So ist das Data Warehouse oftmals Ausgangsbasis für das Data-Mining.
Data-Mining heißt, dass bestimmte Daten aus den großen Datenmengen des
Data Warehouse extrahiert und schließlich ausgewertet werden. Bei der
Auswertung werden die Daten auf Muster und bestimmte Strukturen hin
6
[NetLex]
[Reu04]
8
[VWint1-03]
TP
PT
7
TP
PT
TP
PT
Seite 9
untersucht. Ein Unternehmen erhält so Erkenntnisse über aktuelle Zustände,
die bei der Entscheidungsfindung bedeutsam sind.
Auf diese Weise kann ein Unternehmen schnell auf Veränderungen reagieren. Ohne ein Data Warehouse- System würde man Zusammenhänge
verschiedener Daten oftmals nicht oder sehr spät erkennen und es könnten
Maßnahmen zu wirtschaftlichen Verbesserungen nicht in genügender Weise
getroffen werden.
Es folgt ein einfaches Beispiel für den Nutzen eines Data Warehouse-Systems:
Ein Unternehmen bemerkt einen Engpass bei der Lieferung eines Produktes
„Produkt 1“. Die Auswertung ergibt Folgendes:
Es wird die Dimension Produkt mit der Dimension Zeit (Monat) ausgewertet.
Das Ergebnis dieser Auswertung ist die Produktmenge. Nach Vereinigung
dieser beiden Dimensionen erhält man z.B. die Erkenntnis, dass in den
Monaten Mai-August mehr von Produkt 1 als in den übrigen Monaten verkauft wurde.
Das Unternehmen kann jetzt auf diese Erkenntnis reagieren, indem es in den
Sommermonaten mehr Produkte herstellt und zum Verkauf bereitstellt als in
den Wintermonaten. Hinzugefügt wird jetzt noch eine weitere Dimension
Region. Schaut man jetzt noch einmal auf die Sommermonate, kann daraus
die Tatsache erfolgen, dass in den südlichen Regionen überproportional viele
Produkte verkauft werden. Doch in den nördlichen Regionen werden fast
genau so viele Produkte wie in den Wintermonaten verkauft.
Für das Unternehmen ändert sich jetzt die Sachlage insofern, als dass der
Transport der Produkte nicht gleichverteilt in alle Regionen geschehen darf,
sondern der größte Teil in den Süden geliefert werden muss.
Es handelt sich hierbei um eine 3-dimensionale Abfrage (Zeit, Region, Produkt). Aus dieser Abfrage resultiert die Anzahl der verkauften Produkte (Produktmenge), aufgeteilt nach Region und Zeit.
Seite 10
Wird dieser Zusammenhang grafisch dargestellt, wie in Abbildung 2-1,
spricht man auch von einem Hypercube. In einem SAP BW- System wird
dieser als InfoCube bezeichnet.
Abbildung 2-1- Produktanalyse
2.4. SAP BW
Im Folgenden wird die Architektur des Data Warehouse-Systems SAP BW,
welches 1998 von SAP eingeführt wurde, näher erläutert. Weiterhin folgt eine
Darstellung der wichtigsten Bestandteile des BW. Abschließend werden der
Datenfluss, die Zusammenhänge und die Funktionen der einzelnen BW-Objekte beschrieben.
2.4.1.
Aufbau/ Architektur
Die Client / Server- Architektur des SAP BW teilt sich in folgende drei
Schichten auf: Datenbankschicht, Applikationsschicht und Präsentationsschicht (Abbildung 2-2).
In der Datenbankschicht sind sowohl Anwendungsdaten aus verschiedenen
Quellsystemen als auch Verwaltungsdaten, Customizing-Einstellungen,
ABAP-Quelltexte und anderes abgelegt. Als Datenbanken werden relationale
Datenbanken wie Oracle-Datenbanken - die auch bei der VWFSAG im Einsatz sind - MS-SQL-Server und DB2 eingesetzt. Diese Daten können im
Seite 11
ABAP-Dictionary eingesehen werden. Das ABAP-Dictionary ist das Metadata-Repository9 für die Datenstrukturen des SAP BW.10 Im ABAP-Dictionary
TP
PT
TP
PT
können diverse Tabellen angezeigt werden. Zum Beispiel befinden sich in
der Tabelle rsdiobj Informationen über alle InfoObjects des Systems. Eine
Tabelle besteht aus mehreren Zeilen, welche wiederum aus einzelnen Feldern bestehen. Die technischen Eigenschaften eines Feldes werden dabei
als Domäne und die semantischen als Datenelement bezeichnet. Zum Beispiel könnte zu dem Feld Alter, welches das Alter von Personen beschreibt,
ein weiteres Feld SystemAlter betrachtet werden, das ebenfalls ein Alter
beschreibt, also dieselben technischen Eigenschaften und somit die gleiche
Domäne besitzt. Beide Felder haben aber eine unterschiedliche Semantik,
gehören also unterschiedlichen Datenelementen an.
Beziehungen von
Tabellen untereinander bestehen nach dem relationalen Datenbankmodell
durch Fremdschlüssel. Tabellen werden später für die Anzeige von Daten in
der Dokumentationsverwaltung relevant sein.
Die Applikationsschicht bildet das eigentliche BW-Basissystem. Hier werden
Anwendungsprozesse - zumeist ABAP-Programme – ausgeführt, die technisch auf einem oder mehreren Applikationsservern laufen.
Die
Präsentationsschicht
ist
die
Bezeichnung
für
die
SAP-
Benutzeroberfläche (SAP GUI), welche auf den Client-PC’s installiert ist. Von
dieser aus macht der Anwender Ein- und Ausgaben, die an die Applikationsschicht zur Verarbeitung weitergeleitet werden.
TP
9
PT
TP
Repository (engl.) = Behälter, Aufbewahrungsort
[Meh03], S.16
10
PT
Seite 12
Abbildung 2-2: Architektur des SAP BW
Jeder Anwender muss sich zu Anfang einer SAP-Sitzung mit Username und
Passwort anmelden. Um eine Anwendung zu öffnen ist die Angabe eines
Transaktionscodes notwendig. Jede Transaktion wird durch ein eigenes Bildschirmbild repräsentiert. Die graphische Darstellung des Bildschirms
zusammen mit den zugehörigen Abläufen wird als Dynpro (Dynamisches
Programm) bezeichnet. Beispiele für Transaktionen sind rsa1 für die Administrator Workbench und rrmx für den Business Explorer Analyzer.
In der Administrator Workbench als zentrales Verwaltungswerkzeug werden
z.B. verschiedene Daten des SAP BW gepflegt, der gesamte Datenbereitstellungsprozess gesteuert, Datenladevorgänge eingeplant und angestoßen
und Metadaten und Dokumentationen modifiziert.
Mit dem Business Explorer Analyzer werden Reports zur Datenanalyse
erstellt. Mithilfe von Daten, die einen unterschiedlichen Detaillierungsgrad
(z.B. Jahr, Monat) aufweisen, kann nach unterschiedlichen Sichten ausgewertet werden. Eine Möglichkeit der Sicht ist z.B. die Anzahl der verkauften
Produkte eines bestimmten
Monats, eine weitere mögliche Sicht ist der
Seite 13
Monat mit den am meisten verkauften Produkten eines Jahres. Das Reporting erfolgt mittels Queries11 auf Stamm- und Bewegungsdaten.
TP
PT
Im SAP BW gibt es die drei Daten: Stammdaten, Bewegungsdaten sowie die
aufzubereitenden Metadaten. Stammdaten sind die Daten eines Unternehmens, die sich im Laufe der Zeit kaum oder nicht verändern. Dieses können
z.B. Informationen über Kunden oder Produkte (z.B. Produktname, Produktnummer) sein.
Bewegungsdaten sind Daten, die meist durch Daten-Transaktionen zustande
kommen. So ist der Vorgang eines Verkaufs den Bewegungsdaten (wie z.B.
Umsatzzahlen) zuzuordnen. Ein Vorgang bezieht sich immer auf Stammdaten wie z.B. einen Kunden oder ein Produkt und auf einen Zeitpunkt oder raum.
Mithilfe von Metadaten können Daten näher beschrieben werden. Ein BWObjekt besteht aus technischen und fachlichen Metadaten. Die technischen
Metadaten sind z.B. das Datenformat (INT, CHAR …) bzw. die Ablagestruktur und die Anzahl der Zeichen einer Beschreibung. Technische Metadaten
sind unbedingt notwendig, da ohne Speicherstruktur kein Objekt existieren
kann.
Fachliche Metadaten sind Informationen über die BW-Objekte selbst, wie den
Ersteller und Verantwortlichen eines BW-Objektes, die letzte Aktualisierung,
eine betriebswirtschaftliche Beschreibung des BW-Objektes usw.
Zu den Metadaten gehören auch die BW-Objekt-Dokumentationen, die
Gegenstand dieser Diplomarbeit sind. Diese Dokumentationen befinden sich
in der R/3 Datenbank.
2.4.2.
Datenfluss
Um Daten auswerten zu können, werden diese aus Quellsystemen extrahiert
und im BW-System zur Datenanalyse modifiziert und aufbereitet. Dieser Pro-
TP
11
PT
Query (engl.) = Abfrage; basierend auf der SQL-Syntax
Seite 14
zess wird als Staging bezeichnet. In dem Staging-Prozess durchlaufen die
Daten vier logische Ebenen12:
TP
•
Extraction Layer13
•
Inflow Layer
•
Transformation Layer
•
Integration Layer
TP
PT
PT
Die einzelnen Layer sind die Schnittstellen zwischen den oben genannten
Schichten (s. Abbildung 2-2). Der Extraction Layer ist die Schnittstelle zwischen den Quellsystemen und der Datenbankschicht, wo
Daten aus
verschiedenen Quellsystemen extrahiert und in so genannten DataSources
der Datenbankschicht gespeichert werden. Der Inflow Layer stellt Funktionen
für das Einrichten und Definieren der Quellsysteme und deren Metadaten zur
Verfügung. Im Transformation Layer, der Schnittstelle zwischen der Datenbankschicht und der Applikationsschicht, werden die Daten homogenisiert
und in InfoSources abgelegt. Im Integration Layer werden die Daten für das
Reporting vorbereitet. Sie bildet somit die Verbindung zur Präsentationsschicht.
Zur Verdeutlichung des Prozesses der Datenaufbereitung erfolgt eine detaillierte Beschreibung.
Extraction Layer
In dem Extraction Layer werden Daten aus verschiedenen Quellsystemen
extrahiert und in
DataSources gespeichert. Diese Quellsysteme können
SAP Systeme, einfache Dateien (Flat Files), operative Datenbanksysteme
und auch andere BW-Systeme sein, die wiederum als Datenquelle an das
BW angeschlossen werden. Eine DataSource ist eine flache Speicherstruktur
mit Datenfeldern ähnlich einer relationalen Tabelle und kann nur Daten aus
einem Quellsystem aufnehmen. Eine DataSource ist aufgrund der quellsys-
12
TP
PT
TP
13
PT
[Meh03]
Layer (engl.) = Schicht, Ebene
Seite 15
temspezifischen Struktur der Daten quellsystemabhängig bzw. –orientiert.
Der Extraktor wird für jede DataSource spezifisch erstellt. Ein Quellsystem
kann dagegen seine Daten in mehrere DataSources einfügen.
Um eine Extraktion in die DataSources durchführen zu können, müssen
Metadaten der Daten vorhanden sein. Diese Metadaten enthalten unter
anderem Informationen über die Strukturierung der zu extrahierenden Daten.
Für Quellsysteme, wie z.B. Flat Files, die keine Metadaten enthalten, müssen
diese definiert werden (s. Abschnitt „Inflow Layer“).
Wurden Daten aus einem Quellsystem in eine DataSource extrahiert, so ist
es möglich, die DataSource um zusätzliche Felder zu erweitern. Diese Felder
müssen mit Daten versorgt werden. Ändern und Löschen der Daten ist aber
nicht möglich.
Abbildung 2-3 zeigt – unter Vorwegnahme der höheren Schichten – den
Datenfluss des SAP BW mit dem Datenziel InfoCube.
Abbildung 2-3: Datenfluss
Seite 16
Inflow Layer
Der Inflow Layer bildet die Schnittstelle zwischen der DataSource und der
PSA-Tabelle (Persistant Staging Area). Weiterhin erfolgt hier die Einrichtung
der Quellsysteme an das SAP BW und die Definition der Metadaten14.
TP
PT
Die Möglichkeit, die Daten der DataSource in der PSA, einer flachen Tabelle,
zwischenzuspeichern ist optional. Mithilfe von PSA-Tabellen sind die Prüfung
auf Datenqualität und Wartungen möglich.
Transformation Layer
Die aus dem Extraction Layer extrahierten Daten liegen noch in quellsystemspezifischer Form vor. Dies bedeutet, dass die Daten von unterschiedlicher
Semantik und Struktur sind. Semantik heißt z.B., dass die Materialnummer
eines Produktes in mehreren Quellsystemen vorkommt, die Nummer des
Produktes dort aber unterschiedlich ist. Struktur besagt dagegen, dass in
einem Quellsystem das Datum z.B. die Struktur yyyymmdd und in einem
anderen die Struktur ddmmyy haben kann. Die Daten müssen deshalb für
die Weiterverarbeitung homogenisiert, d.h. vereinheitlicht werden.
Die Transformation in ein semantisch und strukturell einheitliches Format
geschieht durch das Definieren von Übertragungsregeln. Mithilfe der Übertragungsregeln gelangen die quellsystemspezifischen Daten der DataSource
in die InfoSources. Sie werden technisch mit Mapping, Zuweisung von Konstanten, ABAP-Routinen oder Formeln erstellt. Sehr viele Möglichkeiten der
Definition einer Übertragungsregel bieten dagegen ABAP-Routinen.
Die Daten einer InfoSource können aus mehreren Quellsystemen bzw.
DataSources stammen und sind aufgrund ihrer Homogenisierung einheitlich
und somit qualitativ hochwertig. Eine InfoSource ist somit im Gegensatz zu
einer DataSource quellsystemunabhängig. Eine DataSource kann aber nur
an eine InfoSource angebunden werden.
Die Definition der Zielstruktur der Homogenisierung wird als Kommunikationsstruktur bezeichnet.
TP
14
PT
[Meh03], S.18
Seite 17
Integration Layer
Die transformierten Bewegungsdaten werden in InfoProvider fortgeschrieben.
InfoProvider sind alle BW-Objekte, die für das Reporting genutzt werden.
Diese sind betriebswirtschaftliche abgeschlossene Bereiche. Zu diesen
gehören InfoCubes, ODS-Objekte und InfoObjects. Diese werden auch als
Datenziele bezeichnet, da sie die letzte Stufe des Staging-Prozesses sind.
Ferner sind InfoSets und Multiprovider InfoProvider, jedoch ohne eigene
physische Datenhaltung.
Für die Fortschreibung von Daten der InfoSources in die Datenziele, müssen
Fortschreibungsregeln definiert werden. Fortschreibungsregeln sind Datenziel-spezifisch, d.h. es wird für jedes Datenfeld eines Datenzieles die Fortschreibungsart festgelegt. Jede InfoSource kann dabei Daten in mehrere
Datenziele fortschreiben. Mögliche Fortschreibungsarten sind: keine Fortschreibung, Überschreiben und Minimum, Maximum, Addition (Abbildung
2-4).
Abbildung 2-4. einfaches Bsp. einer additiven Fortschreibung
Der wichtigste InfoProvider ist der multidimensionale InfoCube (s. Abbildung
2-1), der die Grundlage der Datenanalyse darstellt und extra für diese konzi-
Seite 18
piert und optimiert wurde. Ein InfoCube deckt einen betriebswirtschaftlichen
Bereich ab (z.B. Vertrieb ) und ist prädestiniert für das Reporting aus hochverdichteten, unveränderlichen Daten.
Weiterhin gibt es ODS-Objekte, die den Vorteil der sofortigen Verfügbarkeit
haben (transaktionale ODS-Objekte), aber auch den Nachteil der schlechteren Performance und Qualitätssicherung bei größeren Datenmengen aufweisen. ODS-Objekte dienen der Speicherung von Daten, die sich schnell
verändern. Das ODS-Objekt hat den Vorteil des Delta-Mechanismus, weswegen Daten bei der Volkswagen Bank oftmals erst in ein ODS und dann in
die InfoCubes gelangen. Mit dem Delta-Verfahren kann ermittelt werden,
welche Datensätze sich zwischen zwei Monatstabellen geändert haben bzw.
neu hinzugekommen sind.
InfoCubes sind nach einem Star-Schema aufgebaut Die zentrale Faktentabelle ist mit den Dimensionstabellen über eine eindeutige Dimensions-ID
(Dim-ID) verknüpft (s. Abbildung 2-5). Eine Dimensionstabelle enthält
Datenfelder und mindestens ein Schlüsselfeld.
Abbildung 2-5: Star-Schema
Wenn von einem Datenfeld (z.B. Produktnummer) gesprochen wird, dann ist
damit technisch gesehen ein InfoObject gemeint. InfoObjects sind die
kleinste Einheit im SAP BW. Jedes BW-Objekt besteht aus einer Menge von
Seite 19
InfoObjects und ist ohne sie nicht existent. Stamm- und Bewegungsdaten
sind in InfoObjects gespeichert. Eine detaillierte Erläuterung der InfoObjects
folgt in Kapitel 2.4.3.
Weitere BW-Objekte
Für eine DataSource werden ein oder mehrere InfoPackages definiert. In
einem InfoPackage werden Steuerparameter für Ladeprozesse festgelegt
(Transferstruktur).
Oftmals ist eine Datenanalyse auf mehreren Datenzielen notwendig, denn
InfoCubes decken ja nur einen betriebswirtschaftlichen Bereich ab. Besitzen
die Datenziele eine gemeinsame Schnittmenge, dann kann man mit Hilfe von
Multiprovidern die heterogenen Daten der InfoProvider in einem gemeinsamen Kontext darstellen.
Eine weitere Möglichkeit der Analyse und des Reporting ist das Anlegen
eines InfoSets. Im BW-System der Volkswagen Bank werden zumeist InfoSets verwendet, da dort auf ODS-Objekten selber nicht analysiert wird. InfoSets haben wie Multiprovider keine eigene physische Datenhaltung, sondern
erhalten temporär zum Zeitpunkt der Analyse die nötigen Daten aus den
angegebenen (ODS-) Objekten.
2.4.3.
InfoObject
Diese Diplomarbeit beschäftigt sich primär mit dem BW-Objekt InfoObject,
weswegen dieses nun ausführlich beschrieben wird.
Ein InfoObject - als kleinste Einheit im BW - ist ein betriebswirtschaftlicher
Basis-Informationsträger. Es ist zwingender Bestandteil für die Existenz
eines BW-Objekts. Ein InfoCube kann höchstens 16 Dimensionen haben und
besteht immer aus mehreren InfoObjects. Höchstens 253 InfoObjects sind
eine Dimension dieses InfoCubes.
Ein InfoObject kann von dem Typ Kennzahl (engl.: keyfigure), Merkmal
(engl.: characteristic), Zeitmerkmal oder Einheit sein. Kennzahlen gehören zu
den Bewegungsdaten und sind Werte und Mengen wie z.B. Umsatz und
Seite 20
Lagerbestände. Umsatz ist eine Flussgröße, das heißt, dass der Umsatz sich
auf einen Zeitraum bezieht. Dagegen ist Lagerbestand eine Bestandsgröße,
die sich auf einen Zeitpunkt bezieht.
Merkmale dienen der Auswertung von Kennzahlen. So sind z.B. Region und
Produkt Merkmale, die zusammen mit der Kennzahl Umsatz eine Basis zur
Auswertung ergeben (Kapitel 2.3).
Da der Umsatz zeitraumbezogen ist, muss eine weitere Dimension hinzugefügt werden. Diese Dimension ist das Zeitmerkmal. Die Dimension Zeitmerkmal ist ein fester Bestandteil eines InfoCubes, da ohne die Dimension
Zeit nichts existieren kann. So gibt es im Business Content unter anderem
die bereits bestehenden Zeitmerkmale Kalendertag (0calday) und -monat
(0calmonth). Mit Business Content werden unter anderem alle bei der Auslieferung bereits konfigurierten InfoObjects bezeichnet. Man kann ausschließlich Zeitmerkmale des Business Content benutzen, das Anlegen eigener Zeitmerkmale ist nicht möglich.
Eine Einheit ist eine zusätzliche Information eines Betrages oder einer
Menge, z.B. Gramm, Stück, EUR. Dabei handelt es sich immer um eine
Mengeneinheit oder um eine Währung.
Beziehungen von BW-Objekten untereinander
Ein InfoObject ist Teil eines jeden BW-Objekt-Typs. Wie oben erwähnt, kann
ein InfoObject Bestandteil mehrerer InfoCubes sein. Genauso enthält ein
InfoCube mehrere InfoObjects. Die Beziehung von InfoObjects zu InfoCubes
ist also eine m:n- Beziehung. In der Welt der relationalen Datenbanken sind
m:n- Beziehungen problematisch bzw. nicht darstellbar. Für die Nutzer des
BW-Systems führt dieser Sachverhalt analog zur Unübersichtlichkeit
(Abbildung 2-6).
Seite 21
Abbildung 2-6: m:n-Beziehung InfoCube-InfoObject
Da alle BW-Objekte miteinander entweder in einer n:m oder 1:n- Beziehung
stehen, wird die Komplexität der Zusammenhänge noch sehr viel größer.
Diese Komplexität soll in der Dokumentationsverwaltung übersichtlich dargestellt werden.
Begriffserklärungen
Im Folgenden werden einige Begriffe15 erklärt, welche in Zusammenhang mit
TP
PT
InfoObjects stehen und wichtige Metadaten-Parameter für die Anlage von
InfoObjects sind:
Attribute
Attribute sind Merkmale, die von anderen Merkmalen abhängig sind. Diese
sind zusätzliche Informationen für das Hauptmerkmal. Das Merkmal „Auftraggeber“ hat zum Beispiel die Attribute „Auftraggeberland“ und „Aktiengesellschaft“. Ein Merkmal kann sowohl Attribut für ein anderes Merkmal als
auch ein eigenständiges Attribut sein.
Navigationsattribute
Ist ein InfoObject ein Navigationsattribut, dann kann beim Reporting ein Filter
gesetzt werden (z.B. ist AG, ist nicht AG).
TP
15
PT
[Kle04]
Seite 22
Hierarchien (alle InfoObject-Typen)
Durch Hierarchien können in Queries Stammdatenbeziehungen in einer
Baumstruktur dargestellt werden. Das Beispiel eines referenzierten Knotens
wird näher erläutert. Die Konzernhierarchie (Abbildung 2-7) ist zum Infoobjekt
Kunde angelegt. Alle Konzernmütter und -töchter haben jeweils eine eigene
Kunden-Nr. In den Hierarchieknoten sind dann diese Konzern-Kunden-Nr
eingetragen. Die Knotentexte werden dynamisch aus den Kundenstammtexten gefüllt.
Abbildung 2-7: Beispiel einer Hierarchie
Klammerung (Merkmal)
Mehrere Merkmale können miteinander zu einem neuen Merkmal geklammert werden. Das Merkmal Werk und das Merkmal Material können z.B. zu
einem neuen Merkmal zusammengefasst (geklammert) werden. Bei der
Klammerung von Merkmalen werden lediglich die Schlüssel der beteiligten
Merkmale zu einem neuen Schlüssel hintereinander gestellt. Die Stammdaten dieses so definierten Merkmals sind völlig unabhängig von den Stammdaten der beteiligten Merkmale.
Referenzmerkmal (Merkmal)
Merkmale, welche auf andere Merkmale referenziert werden, haben im
Gegensatz zu den geklammerten Merkmalen keine eigenen Stammdaten
sondern 'erben' die Stammdaten des Basis- Merkmals. Das Infoobjekt Kunde
zum Beispiel hat eigene Stammdaten. Da ein Zwischenhändler auch ein
Seite 23
Kunde ist, d. h. auch er hat eine Kunden-Nr, ist er ein eigenes Infoobjekt mit
Referenz auf das Infoobjekt Kunde. Dieses referenzierte InfoObject hat somit
physisch keine Stammdaten sondern benutzt die Stammdaten des InfoObjects Kunde.
Aggregation (Kennzahl)
Die Aggregation wird für die Verdichtung von Daten benötigt. Zumeist werden Werte aufsummiert. Zum Beispiel verdichtet das Produktaggregat die
Kennzahlen pro Produkt-Nr und Zeit.
Seite 24
3. Ist- und Sollzustand
3.1. IST-Zustand
In diesem Unterkapitel wird der IST-Zustand der Dokumentationsverwaltung
des SAP BW beschrieben. Zur Beschaffung unterschiedlicher Informationen
über ein BW-Objekt, muss derzeit an unterschiedlichen Orten im BW System
gesucht werden.
Anzeige und Verwaltung von BW-Objekt-Dokumentationen
Wird beispielsweise die betriebswirtschaftliche Beschreibung gesucht, so
muss im Administrator Workbench unter der Sicht Dokumente nachgesehen
werden (Abbildung 3-1). Dort sind alle vorhandenen Dokumentationen zu
einigen BW-Objekten abgelegt. Eine Dokumentation, die vorher per Word,
HTML, XML etc. angefertigt wurde, kann dort einzeln hochgeladen werden.
Danach wird sie dem BW-Objekt, dem sie angehört, zugewiesen und im
System gespeichert (Abbildung 3-1).
Abbildung 3-1: Dokumentationen im BW
Seite 25
Um nicht jede Dokumentation manuell anlegen zu müssen, gibt es bisher
eine von Mitarbeitern selbst erstellte Access-Datenbank. Diese wird allerdings innerhalb eines bestimmten Projekts verwendet. In einer Tabelle der
Datenbank werden alle Daten für die Dokumentation gespeichert. Mithilfe
eines Visual Basic-Programms werden dann HTML-Dokumentationen mit
vorgegebener Struktur generiert, gespeichert und mit einer Routine allesamt
in das BW hochgeladen. Dort können die Dokumentationen einzeln modifiziert werden. Dieses Vorgehen ist ein erster Ansatz zur gleichzeitigen
Erstellung von mehreren Dokumentationen.
Mängel:
•
es existiert nicht zu jedem BW-Objekt eine Dokumentation
•
vorhandene Dokumentationen haben verschiedene Formate (HTML,
DOC, VISIO)
•
Dokumentationen sind oftmals unvollständig, teilweise steht in Dokumentationen nur ein Satz
•
es gibt keine Zuständigkeiten für das Anlegen und Pflegen von Dokumentationen
•
Änderungen bezüglich eines BW-Objektes werden oftmals nicht
aktualisiert.
•
Änderungen sind umständlich, da entweder der Quellcode direkt oder
mit Hilfe eines externen Editor-Programms angepasst werden muss
•
aktuelle Anmerkungen wie z.B. eine E-Mail oder ein Kommentar sind
schon längst veraltet
•
die Suche nach einem BW-Objekt erschwert sich, wenn man den
technischen Namen nicht kennt
•
der Prozess des manuellen Erstellens oder Füllens der vorhandenen
Access-Datenbank bis hin zu dem Hochladen der Dokumentation ist
recht umständlich.
•
Informationen zu BW-Objekten sind an diversen Stellen verteilt: Die
Dokumentationen der einzelnen Projekte sind in Excel-Tabellen und
Seite 26
Word-Dokumenten auf den Netzlaufwerken zu finden. Informationen
über und die Meta-Daten sowie die Dokumentationen der BW-Objekte
befinden sich an verschiedenen Orten des SAP BW
•
ersetzt man die alte durch eine neue Dokumentationsversion, geht die
alte Version verloren, fehlende Historie
Positive Eigenschaften:
•
das HTML-Format ist ein Schritt in die richtige Richtung; HTML ist
eine softwareunabhängige Metasprache und aufgrund der Designmöglichkeiten gut für die Anzeige einer Dokumentation geeignet
•
es existiert eine Art Vorab-Standard für InfoObjects, der nur ein wenig
ergänzt und angepasst werden muss
Online-Anzeige des Datenflusses
Weitere Informationen, die angefordert werden können, sind Metadaten-Informationen zu dem Datenfluss, zur Herkunft und Verwendung eines BWObjektes. Beispielsweise stellt sich die Frage, in welchen ODS-Objekten und
InfoCubes ein InfoObject enthalten ist.
Dazu gibt es die Möglichkeit, sich pro BW-Objekt eine Online-Dokumentation anzeigen zu lassen. Über den Browser kann sich der Benutzer per Web
Application Server auf dem BW-Produktivsystem anmelden und dort zu den
gewünschten Informationen navigieren. Der Bezug der BW-Objekte zueinander ist hierarchisch verlinkt. Diese Online-Dokumentation soll später in die
Dokumentation eingebaut werden.
Die Struktur der Online-Dokumentation ist in drei Teile eingeteilt16:
TP
•
allgemeine Angaben (Erstellungsdatum, technischer Name, System,
Beschreibung (kurz), Beschreibung (lang) )
TP
16
PT
PT
•
BW-Objekt- Dokumentation (s.o.)
•
Links zu Online-Dokumentationen abhängiger BW-Objekte
[SAPHlp]
Seite 27
Mängel:
•
unübersichtlich, da die Seite bei BW-Objekten mit „viel Datenfluss“
sehr lang wird und der Überblick über die gesamte Seite verloren
geht.
•
nur Lesezugriff, d.h. das Modifizieren einer BW-Objekt-Dokumentation
ist von dort aus nicht möglich
Positive Eigenschaften
•
mit dem Web Application Server ist eine einfache Darstellung des
Datenflusses über den Browser möglich
•
die Links der abhängigen BW-Objekte werden dynamisch erzeugt und
sind so immer auf dem neuesten Stand
3.2. SOLL-Zustand
Aus den aufgezählten Mängeln des Ist-Zustands und aus Mitarbeiterbefragungen entstehen die Anforderungen an die neue Dokumentationsverwaltung.
Da zu Beginn dieser Arbeit kaum Informationen über das Arbeitsgebiet vorlagen, wurden die internen Mitarbeiter teils per Interview, teils per Fragebogen (Anhang A, S.99) befragt. Aufgrund der großen Anzahl, erfolgte die
T
T
Befragung der externen Mitarbeiter ausschließlich per Fragebogen17. So
TP
PT
konnten diverse Kritikpunkte des Ist-Zustands, Wünsche zu deren Verbesserung und Informationen über die Mitarbeiter (Bedarf an Dokumentenverwaltung, Kenntnisse über das SAP BW) ermittelt werden.
Die Mitarbeiter machten diverse Vorschläge
•
zu dem Prozess der Dokumentationserstellung
•
zu Zuständigkeiten und Qualitätssicherung
Seite 28
•
zu der Einführung eines Change Request-Verfahrens bei Anmerkungen und Änderungswünschen
•
zu der Informationsbeschaffung: automatische Benachrichtigung per
Email oder Holpflicht
•
zu den Suchmöglichkeiten (Schlagwortsuche)
•
zu dem Umfang der Druckfunktionen
Aus den Auswertungen der Fragebögen und der Mitarbeiterbefragungen folgen die groben Anforderungen des SOLL-Zustands. Es soll eine plattformunabhängige Anwendung erstellt werden, auf die jeder Anwender, der Zugang
zu dem SAP BW hat -- auch von außerhalb -- zugreifen kann:
•
die Sprache soll von Deutsch auf Englisch umschaltbar sein, da auch
ausländische Mitarbeiter auf diese Dokumentationen zugreifen werden. Auch wird der Inhalt der Dokumentationen mehrsprachig erstellt
(Deutsch, Englisch und Französisch)
•
persönliche Einstellungen sollen möglich sein: Möglichkeit der
Anzeige von relevanten Informationen
•
Einführung
T
von
Zuständigkeiten
bzw.
Rollen:
T
Fachbereichsverantwortlicher bzw. Auftraggeber(Customer), zuständiger Entwickler (Developer), Supervisor (Kontrolle der Dokumentationen) und normaler Anwender ohne Sonderstatus
•
Einführung von Berechtigungen (Lesen, Schreiben, Ändern, Freigeben) analog zu den Zuständigkeiten
•
Anzeige aktueller Informationen und Anmerkungen zu einem BW-Objekt
•
komfortable
Navigation
zwischen
den
in
Bezug
stehenden
Dokumentationen und Meta-Daten der BW-Objekte
•
Für die Beschaffung von Informationen besteht Holpflicht; eine EmailBenachrichtigung erfolgt nur, wenn ein Mitarbeiter im Rahmen des
Erstellprozesses für eine Dokumentation zuständig ist
•
Einrichtung eines Versionsmanagements erwünscht
Seite 29
•
Die Darstellung des Datenflusses per Web Applikation Server, bzw.
die Einbindung der bestehenden Seiten
•
Im Falle der Dokumentationserstellung ist die Erstellung einer webbasierten Anwendung nötig, damit sich im Außendienst befindliche Mitarbeiter die Anwendung von jedem internetfähigen Endgerät nutzen
können
•
Einführung eines Prozesses zur Erstellung eines BW-Objektes, welcher die Qualität der Dokumentationen sicherstellt: der Entwickler
erstellt als Vorbedingung für das Anlegen eines InfoObjects im SAP
BW eine Dokumentation. Der Auftraggeber vom Fachbereich ergänzt
sie um die betriebswirtschaftlichen Informationen und der Supervisor
kontrolliert und gibt die Dokumentation frei. Die Teilimplementierung
dieses Meilensteins wird in Kapitel 6 ausführlich beschrieben.
Weiterhin ist die Auswahl geeigneter Programmiertechniken und Tools notwendig. Diese müssen diverse Kriterien wie z.B. die Plattformunabhängigkeit, die Schnittstelle zu einer Datenbank, den Austausch der Dokumentationen mit der SAP-Datenbank und die grafische Darstellung der Dokumentationen erfüllen.
In Kapitel 4 werden diese Techniken und Tools näher beschrieben.
Seite 30
4. Einsatz von Software-Techniken
Bei der Wahl der geeigneten Techniken, Sprachen und Systeme spielt
sowohl ihre Präsenz in der Volkswagen Bank als auch ihre Qualität und ihr
Funktions- und Leistungsumfang eine Rolle.
Die gewählten Sprachen und Techniken müssen miteinander kommunizieren
können und diversen Anforderungen gerecht werden:
•
Plattformunabhängigkeit (bei späterer Migration)
•
geeignete Schnittstellen für die Anbindung an die anderen Systeme
und den Datenaustausch
•
Möglichkeit der Darstellung und Speicherung von Dokumentationen
und Daten
•
Webbasiertes GUI
•
Suchmöglichkeiten
In den folgenden Unterkapiteln werden die in Frage kommenden Techniken
vorgestellt. Dafür werden Leistungs- und Funktionsumfang erarbeitet und
erste Entscheidungen über die Auswahl getroffen. Am Ende dieses Kapitels
ist der komplette Aufbau der Anwendung in Form einer Grafik zu sehen.
4.1. XML
XML wird an dieser Stelle ausführlich erläutert, da die XML-Technik der
Erstellung, Darstellung und Speicherung von Dokumentationen grundlegender und wichtigster Bestandteil der Dokumentationsverwaltung ist.
Seite 31
4.1.1.
Grundlagen XML
XML (Extensible Markup Language) ist seit 1998 ein Standard des W3C18.
TP
PT
Seinen Ursprung hat XML in SGML (Standard Generalized Markup Language).
SGML ist der erste Markup-Formalismus und entstand aus dem Bedarf nach
system- und softwareunabhängiger Datenspeicherung. Da SGML jedoch als
zu kompliziert empfunden wurde, ist nun XML, das ursprünglich ein Teil von
SGML war, der würdige vereinfachte Nachfolger mit ähnlich hohem Leistungsumfang wie seine Vorgängersprache SGML.
Aufbau und Struktur
Ein XML-Dokument besteht aus miteinander vermengten Zeichendaten und
Markup. Markup bezeichnet unter anderem
•
Start-Tags:
<…>
•
End-Tags:
</…>
•
Entity-Referenzen: „<“ muss im Text als &gt; geschrieben werden
•
Kommentare:

Sämtlicher Text, der kein Markup ist, bildet die Zeichendaten des Dokuments.
XML-Dokumente beginnen mit einer XML-Deklaration (Prolog):
<? xml version="1.0" encoding="ISO-8859-15"?>
T
In dieser stehen die verwendete XML-Version und ggf. die Kodierungs- deklaration des ISO-Standards 8859 (u.a. Deutscher Zeichensatz).
Weiterhin muss ein XML-Dokument aus mindestens einem Element, dem
Wurzelelement bestehen (s. Abbildung 4-1).
TP
18
PT
W3C: World Wide Web Consortium
Seite 32
Zwischen diesen Tags befinden sich die Kindelemente, die wiederum Kindelemente enthalten können. Jedes Element bis auf das Wurzelelement hat
umgekehrt auch Eltern (übergeordnete Elemente).Weiterhin gibt es die
Bezeichnung Geschwister für gleichrangige Elemente, Vorfahren für alle
untergeordneten Elemente und Nachfahren für alle übergeordneten Elemente. Durch diese Verschachtelung entsteht eine baumähnliche Struktur.
Analog zur der Bezeichnung Wurzelelement werden kinderlose Elemente
auch als Blätter bezeichnet.
Abbildung 4-1: Baumdarstellung eines XML-Dokuments
Beispiele zur Verwandtschaft der Knoten
Das Element Teilnehmer ist
•
Kind von Seminar
•
Vater und Nachfahre von Anzahl
•
Geschwisterteil von Name und Treffen
In Beispiel 4-1 wird der Baum als XML-Dokument dargestellt:
<?xml version="1.0! encoding="ISO 8559-15"?>
<Seminar>
<Name>
</Name>
T
<Teilnehmer>
<Anzahl></Anzahl>
Seite 33
</Teilnehmer>
<Treffen>
</Treffen>
</Seminar>
Beispiel 4-1: XML-Dokument
Wohlgeformtheit
Ein XML-Dokument muss wohlgeformt sein, d.h. es muss sich an die syntaktischen Regeln der XML-Spezifikationen halten. Die wichtigsten Kriterien,
die erfüllt sein müssen, damit ein Dokument wohlgeformt ist, sind:
•
in der ersten Zeile steht die XML-Deklaration mit Version und Kodierungsdeklaration
•
es existiert genau ein Stamm-Element
•
jedes Start-Tag muss auch ein End-Tag haben
•
die Elemente müssen ordnungsgemäß ineinander verschachtelt sein
Beispiel 4-1 ist wohlgeformt und wird aufgrund dessen im Browser dargestellt. Ist ein Dokument nicht wohlgeformt, wird im Browser statt des Baumes
eine Fehlermeldung angezeigt.
Elemente und Attribute
Dem XML-Dokument aus Beispiel 4-1 fehlen natürlich noch die Inhalte.
Zwischen dem Start- und dem End-Tag der Element kann man Daten als
Inhalt einfügen. Dateninhalt haben nur kinderlose Elemente. In Beispiel 2
wurden in die Blattelemente Inhalte eingefügt:
<?xml version="1.0! encoding="ISO 8559-15"?>
<Seminar>
<Name>
XML Workshop
</Name>
<Teilnehmer>
<Anzahl>10</Anzahl>
</Teilnehmer>
Seite 34
<Treffen Ort="Raum10" Zeit=“Donnerstag“>
</Treffen>
</Seminar>
Beispiel 4-2: XML-Dokument mit Inhalt
Neben Elementen können optional Attribute angegeben werden.
Attribute werden in den Start-Tag des Elements geschrieben und geben die
Eigenschaften eines Elementes wieder.
4.1.2.
Die Stylesheets CSS/ XSL
XML ist sehr gut für den plattformunabhängigen Austausch von Daten geeignet. Weiterhin können XML-Dokumente auch zur Ansicht bereitgestellt werden. Ein XML-Dokument für den Austausch von Daten hat zumeist eine
simplere Struktur als ein für die Ansicht definiertes Dokument. Denn um ein
Dokument in einem Browser anzeigen zu können, bedarf es eines Stylesheets. Ohne Stylesheet erfolgt die Anzeige eines Dokumentes im Browser
wie in Beispiel 4-2. Um den XML-Inhalt in einem Browser anzuzeigen ist eine
Möglichkeit, das XML-Dokument in HTML umzuwandeln.
Am bekanntesten sind dafür die standardisierten Darstellungssprachen CSS
(Cascading Stylesheets) und XSL (XML Stylesheet Language).
Für die Darstellung von HTML wird CSS, welches schon seit 1996 besteht,
standardmäßig genutzt um eine individuelle Formatierung zu erreichen. CSS
kann aber auch für die Darstellung eines XML-Dokuments verwendet werden. CSS ist die ältere der beiden Methoden und wird durch die neue XSL
Technik abgelöst.
XSL
Mit XSL gibt es eine weitere Variante, einen Style zu definieren. XSL ist mit
der Transformationssprache XSLT (XSL-Transformations) eng verknüpft.
Per XSLT kann ein XML-Dokument in diverse andere Formate (z.B. PDF und
HTML) transformiert, d.h. umgewandelt werden. Ein XML- Prozessor, der
z.B. auch Bestandteil des Internet Explorers ist, nimmt diese Transformation
Seite 35
vor. Die Regeln, wie ein Dokument transformiert wird, werden mit Templates
aufgestellt, die mit XPath definiert werden. XPath selektiert Teile eines XMLDokuments mittels Pfadangaben. Das Beispiel unten zeigt ein simples XSLStylesheet. Alle Elemente, denen keine XSL- Anweisung vorangeht, wie zum
Beispiel der HTML-Code, werden einfach in den Ausgabebaum kopiert.
<?xml version="1.0" encoding="ISO-8859-15"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="/">
<html> 
<head>
<title>Seminar</title>
</head>
<h1>Seminar</h1>
<table border="1">
<tr>
<th>Name</th>
<th>Zeit</th>
</tr>

<xsl:apply-templates select="Seminar"/>
</table>
</html>
</xsl:template>

<xsl:template match="Seminar">
<tr>
<td>
<xsl:value-of select="Name"/>
</td>
<td>
<xsl:value-of select="Treffen"/>
</td>
</tr>
</xsl:template>
</xsl:stylesheet>
Beispiel 4-3: XSL-Dokument
Ergebnis dieser XSL-Vorlage, verknüpft mit unserer XML-Datei, ist eine
HTML-basierte Darstellung in Tabellenform:
Seite 36
Abbildung 4-2: XML-Dokument-Anzeige per XSLT
Vor- und Nachteile CSS/ XSL
Das CSS-Stylesheet ist einfacher zu erlernen, hat aber begrenzte Möglichkeiten. XSL ist vor allen Dingen für Transformationen von XML in andere
Formate unabdinglich und hat den Vorteil, dass es in XML beschrieben ist
und somit selbst als XML-Dokument behandelt und verarbeitet werden kann.
Es gibt sehr viele Möglichkeiten mit XSL, XML- Dokumente darzustellen, z.B.
kann man Elemente sortiert aufzeigen (xsl:sort) und sie an Bedingungen
knüpfen (xsl:if). XSL besitzt zahlreiche weitere Möglichkeiten der Darstellung
und Transformation von XML- Dokumenten.
4.1.3.
Weitere XML-Begriffe
Validierung: DTD und XSD
Validierung bedeutet, dass ein Dokument mittels eines Parsers auf Gültigkeit
hin überprüft wird. Gültigkeitsregeln kann man selber aufstellen. Es ist
manchmal notwendig zu definieren, dass ein Element unbedingt Inhalt haben
muss. So kann man definieren, dass z.B. die Anzahl der Teilnehmer eines
Seminars eingetragen sein muss. Diese darf aber nur genau einmal angegeben werden, da sich sonst Inkonsistenzen ergeben. Wird nun versucht, in
einem XML-Dokument einen Eintrag zu machen, der nicht den aufgestellten
Regeln entspricht, gibt der Parser eine Fehlermeldung aus.
Die zwei bekanntesten Möglichkeiten, die Struktur eines XML-Dokumentes
festzulegen ist die DTD (Document Type Definition) und XSD (XML Schema
Definition).
Seite 37
Die DTD Spezifikationen wurden vom W3C Konsortium vorgeschlagen, während die XML Schemas auf einen Vorschlag von Microsoft basieren aber
kürzlich vom W3C Konsortium vereinheitlicht und standardisiert wurden.
DOM (Document Object Model):
T
T
DOM gibt ein Dokument in Form eines Baumes wieder. Die meisten XMLParser implementieren einen von zwei API’s: entweder DOM oder SAX
(Simple API for XML).
XPath (XML Path Language):
T
T
DOM nimmt sich XPath zur Hilfe, um einzelne Knoten eines Dokumentes
ansprechen
zu
können.
Dieses
geschieht
per
Pfadangabe
(z.B.
/Seminar/Teilnehmer). Der Standard XPath 2.0 existiert seit Ende 200319 und
TP
PT
enthält einige Neuerungen.
Datenorientiertes und Dokumentenorientiertes XML
Datenorientierte Dokumente sind im Gegensatz zu dokumentenorientierten
XML-Dokumenten eher für den Datenaustausch als für die Ansicht gedacht
und weisen eine einfachere Struktur auf. Die Dokumentationen der Dokumentationsverwaltung tendieren zu dem dokumentenorientierten XML, da sie
letztendlich zur Ansicht genutzt werden und von unterschiedlicher Struktur
sind.
4.1.4.
Gründe für die Entscheidung für XML
Für die Aufstellung eins Konzeptes für die Dokumentationsverwaltung ist es
wichtig, frühzeitig zu definieren, in welchem Format die Dokumentationen
vorliegen sollen. Dieses Format wird das XML-Format sein. XML ist derzeit
der einzige Standard, der eine so breite Palette an Möglichkeiten für die
Bearbeitung und Kategorisierung der Daten, dem Datenaustausch zwischen
Systemen und Anwendungen sowie der Datenanzeige, unterstützt.
Gerade Dokumentationen enthalten sehr viele Daten, deren Darstellung,
Speicherung und Verarbeitung eine Herausforderung darstellt. Der XML-
TP
19
PT
[W3C]
Seite 38
Standard mit seiner hohen Flexibilität und Erweiterbarkeit hat eine Fülle von
Möglichkeiten für diese Herausforderung geschaffen.
XML ist dafür bekannt, dass es einen großen Overhead hat. Dieses stellt bei
den geringen Kosten für Speicherplatz und immer schneller werdenden
Rechnersystemen aber immer weniger ein Problem dar.
HTML alleine genügt nicht für den Datenaustausch und die Datenbearbeitung, da die Baumstruktur von HTML-Dokumenten für das Selektieren von
Knoten aufgrund uneindeutiger Tagbezeichnungen nicht geeignet ist. HTML
ist trotz fehlenden Eigenschaften von enormer Wichtigkeit für die BrowserDarstellung von Internetseiten und Anwendungen und kommt daher auch
zum Einsatz, nämlich dann, wenn das fertige XML-Dokument für die Ablage
im SAP BW in das HTML-Format transformiert wird.
Für die Transformation wird aufgrund der XML-Syntax und der verschiedenen Stylegebungsmöglichkeiten XSL eingesetzt. Glücklicherweise unterstützen SAP und Microsoft die beiden Formate und es gibt in dem .NET Framework und in der Oracle-Datenbank zahlreiche Klassen und Methoden zu ihrer
Bearbeitung.
Seite 39
4.2. Oracle-Datenbank
Oracle ist ein objekt-relationales Datenbanksystem. Bei relationalen Datenbanken werden per SQL-Anweisungen (Structured Query Language) Anfragen an die Datenbank ausgeführt20. Mit der DDL (Data Definition Language)
TP
PT
ist das Anlegen von Tabellen, Spalten, Constraints und Triggern realisierbar.
Das Manipulieren von Daten ist per INSERT, UPDATE oder DELETE (DML,
data manipulation language) möglich. Objekt-relational ist eine Erweiterung
der relationalen Datenbank um Objekte. Objekte sind z.B. Tabellen, Klassen
und Tupel (Zeilen). Außerdem
existieren SQL-Spracherweiterungen wie
prozedurale Sprachen. Die Dokumentationsverwaltung benötigt die OracleInstanz für die Zwischenspeicherung von XML-Dokumenten und die permanente Speicherung anderer Daten (Rechte, User, Suchfunktionen). Für diese
Arbeit wurde eine neue Oracle-Instanz mit dem Namen vwfsdw1e aufgesetzt.
Es handelt sich um die Version 9i Release, die auf der Entwicklungsumgebung liegt. Die Version 9i enthält einige Neuerungen bei der Speicherung
und Bearbeitung von XML, auf die im Folgenden eingegangen werden soll.
Es gibt drei Möglichkeiten der Speicherung von XML-Dokumenten:
•
LOB (Large Object): LOB: CLOB (Character LOB), BLOB (Binary
T
T
LOB). Methode, eine große Menge (bis zu 4GB) unstrukturierter Daten
in einer Tabellenspalte zu speichern
•
Relational: Verteilung der Elemente/ Attribute auf rel. Tabellen (ohne
T
T
Tags), Datenorientiert
•
Decomposed (strukturiert):
T
T
geringerer Speicherbedarf, weil Tags
nicht gespeichert werden müssen, Zugriff aus einzelne Elemente
schneller. Liegt ein XML-Schema vor, kann man eine XML-Dokumentation
in relationale Tabellen zerlegen und umgekehrt. XMLTYPE:
neu entwickelter Datentyp, der das Speichern und Abfragen von XMLDokumenten möglich macht. XMLType ist intern als CLOB definiert,
TP
20
PT
[Mül]
Seite 40
Dokumentenorientiert (unregelmäßige Struktur), Composed (unstrukturierte Speicherung), XML-Validierung möglich
Vor- und Nachteile XMLTYPE zu der relationalen Speicherung
Die Möglichkeit, ein XML-Document als CLOB/BLOB zu speichern, kann
verworfen werden, da der neue Datentyp XMLTYPE, der intern als CLOB
verwaltet wird, mehr Features für die Speicherung hat. Es bleibt nur abzuwiegen, ob ein XML-Document als XMLTYPE oder aber in relationalen
Tabellen gespeichert werden sollte.
Vorteile von XMLType
•
XPath ist Standard für den Zugriff auf Inhalte der XML-Datei
•
SQL arbeitet zunehmend mit XML zusammen21,
•
das Original-Dokument geht nicht verloren (XMLTYPE beinhaltet
TP
PT
Dokumentation Byte für Byte),
•
Validierung, Volltextindex und DOM-Zugriff auf XML möglich.
•
Ein sehr wichtiger Aspekt ist, dass das Einfügen von XML-Dokumenten mit variabler Struktur einfacher ist!
•
Weiterhin sind diverse Funktionen und Operationen vorhanden um
XML-Dokumente abzufragen und zu bearbeiten. Diese werden bei der
Erstellung
von
HTML-Dokumentationen
verwendet
(Kapitel
Nachteile von XMLType
•
Zugriff und Update nur auf ganzem Dokument möglich
•
Kombination mit rel. Daten schwierig
•
Mittelmäßige DML Performance
•
verbraucht mehr Speicherplatz (aufgrund des XML-Overhead)
Seite 41
5).
Diverse Funktionen und Packages
Funktionen:
ExistsNode():
Überprüfung der Existenz eines Knotens per XPath,
Extract():
extrahiert einen oder mehrere Knoten, die der XPathAngabe entsprechen,
ExtractValue():
liefert den Inhalt eines Knotens
Xmltransform:
Transformation von XML per XSL
Weitere:
updatexml, xmlelement, xmlforest, xmlsequenz,
xmlconcat, xmlagg
Package:
Dbms_xmlgen:
Generierung von XML aus relational gespeicherten Daten
Weitere:
Dmbs_xmlschema, Sys_xmlgen
Fazit:
In der Dokumentationsverwaltung werden die Daten erst in relationaler Form
in den Datenbanktabellen gespeichert. Erst wenn das XML- bzw. HTML-Dokument benötigt wird, wird aus diesen Daten ein Dokument vom Typ
XMLTYPE durch oben genannte Funktionen und Packages erzeugt. Die
Speicherung von relationalen Daten hat den Vorteil, dass diese per SQL
einfacher zu manipulieren und im DataGrid anzuzeigen sind. Auch ist den
meisten Entwicklern, wenn das Programm später weiterentwickelt werden
soll, die relationale Speicherung besser bekannt. Die XML-Dokumentationen
unterscheiden sich nur gering in ihrem Aufbau und weisen eine einheitliche
Struktur auf, weswegen die Generierung von XML-Dokumenten aus relational abgelegten Daten problemlos möglich ist.
TP
21
PT
ISO-Standard 9075 -14:2003: definiert, wie SQL mit XML zusammenarbeitet
Seite 42
4.3. .NET Technologie
Die .NET Strategie wird seit Mitte 2000 von Microsoft stetig weiterentwickelt.
Der Begriff .NET umfasst verschiedene Techniken und lässt sich schwerlich
in einem Satz zusammenfassen. Auf dem ersten Blick ist .NET ein Marketingbegriff, der die Zukunftsträchtigkeit webbasierter Anwendungen, vor allen
Dingen von XML-WebServices herausstellt. WebServices sind Webdienste,
die wiederum von anderen Anwendungen genutzt werden können.
Ein Entwickler hat den Versuch gemacht, den Begriff .NET in einem Satz zu
definieren:
.NET ist die neue Programmierumgebung von Microsoft, die als Nachfolger
von COM eine einheitliche Laufzeitumgebung für alle Programmiersprachen,
eine umfangreiche Klassenbibliothek, eine Infrastruktur für die Ausführung
von Programmen und Komponenten und neue Sprachencompiler, die einen
Zwischencode erzeugen, der von der Laufzeitumgebung vor der Ausführung
in Maschinencode kompiliert wird, für alle Programmierer zur Verfügung
stellt.22
TP
PT
Diese Aussage soll im Folgenden näher erläutert werden.
•
.NET ist eine Ansammlung und Weiterentwicklung zum Teil schon
bestehender Techniken und Programmiersprachen . Einige Beispiele
sind ASP, C++, Visual Basic, ADO und diverse Server. Die neu von
Microsoft entwickelten Sprachen heißen C#23, J#, Oberon.net u.a.
TP
•
PT
Der wichtigste Bestandteil von .NET ist das .NET Framework SDK.
Dieses enthält die Hauptbestandteile Common Language Runtime
(CLR, deutsch: Laufzeitumgebung) und die .NET Framework Klassenbibliothek. Die CLR des .NET Frameworks ist, genau wie die
Virtual Machine von Java, plattformunabhängig. Die CLR führt den
TP
22
PT
[Mo01]
Seite 43
Code aus. Bevor ein Programm von der CLR ausgeführt werden kann,
wird der Code in IL (Intermediate Language), eine plattformunabhängige Zwischensprache, umgewandelt.
•
Aufgrund der Plattformunabhängigkeit können Compiler oder eine
Implementierungen von .NET erstellt werden. Im Rahmen des MonoProjektes24 werden daher sowohl ein Compiler für C# als auch ein
TP
PT
.NET Framework für Linux entwickelt, die beide als Open Source verfügbar sind.
•
Das .NET Framework enthält eine umfangreiche Klassenbibliothek,
auf die alle wichtigen Entwicklungssprachen zugreifen können
•
Das wichtigste Tool von Microsoft für die .NET-Entwicklung ist das
Visual Studio .NET.
Dieses ist eine integrierte Entwicklungsumge-
bung, die Editor, diverse Assistenten für Windows-, Web-, Web-Service und Konsolenanwendungen, einen Designer für Formulare, ausführliche Dokumentationen, Debugger und Klassenbrowser vereint.
4.4. Visual Basic.net
Visual Basic hat ihren Ursprung in der Sprache Basic, welche 1964 erfunden
wurde. Im Laufe der Jahre wurde VB durch das Hinzufügen vieler Funktionen
verbessert. Mit dem Schritt von VB 6 zu VB.net wurden überflüssige Funktionen beseitigt und neue Funktionen hinzugefügt.
VB.NET Programme nutzen, wie alle .NET-Sprachen, die Klassen des .NET
Framework und haben daher in etwa den gleichen Funktionsumfang. Die
Syntax der Sprachen ähnelt sich, so dass der Umstieg von C# auf Visual
Basic nicht sehr schwerfällt.
23
TP
PT
TP
24
PT
[Bri03]
[Mono]
Seite 44
Da die Mitarbeiter der Abteilung eher Visual Basic als C# Kenntnisse haben,
wird das Programm in Visual Basic entwickelt..
4.5. ADO.net
Mit ADO.net (Microsoft ActiveX Data Objects) wird der Zugriff auf Datenbanken realisiert. In der .Net-Klassenbibliothek befinden sich die von ADO verwendeten Klassen im Namensraum System.Data. Die Verbindung zu der
Oracle-Datenbank geschieht mit dem OleDb-Provider (Object Linking and
Embedding Provider).
Der wichtigste Unterschied von ADO.net zu ADO ist die leistungsfähige
Unterstützung von XML. ADO.NET verwendet selbst XML als Format für den
Datenaustausch zwischen den einzelnen Applikationen. Weiterhin ist die
Einführung von DataSets eine Neuerung. Diese speichern den abgefragten
Datenbankinhalt zwischen, so dass keine Verbindung zur Datenbank nötig ist
um Informationen darzustellen.
4.6. ASP.net / Webserver
ASP („Active Server Pages“) dient zur Erzeugung dynamischer Webseiten
und ist eine Erweiterung des IIS (Internet Information Services). IIS ist ein
Webserver, dessen Hauptaufgabe es ist, Verbindungen von Remoteclients
anzunehmen,
eingehende
HTTP-Anforderungen
zu
beantworten,
Usereingaben durch einen Sitzungsstatus zu verwalten, sowie diverse
Sicherheitsaspekte zu gewährleisten.
Eine ASP-Seite besteht aus HTML-Code und - optional - Scriptcode (z.B. VB,
Java Script). Ruft der Client eine ASP-Seite auf, so schickt er eine Anfrage
an den IIS (Request). Der IIS antwortet dem Client (Response) und die ASPSeite wird angezeigt.
Erwähnenswert ist das ASP.NET-Steuerelement DataGrid. Es sieht einer
Tabelle ähnlich und wird für die Bindung von Daten aus einer Datenquelle
verwendet. Weiterhin stellt es eine Vielfalt von Funktionen zur Verfügung, wie
es sie bisher für dynamische Webanwendungen nicht gab. Das DataGrid
Seite 45
kann seine Daten per ADO aus einer Datenbank beziehen. Dabei kann der
Datenbankinhalt in einem DataSet zwischengespeichert werden, so dass
eine permanente Verbindung zu der Datenbank nicht mehr nötig ist.
Das DataGrid in Verbindung mit dem DataSet wird das zentrale Steuerelement der Dokumentationsverwaltung sein.
Abbildung 4-3: DataGrid-Beispiel
4.7. Anbindung an das SAP BW: Der SAP .NET-Connector
Das neuste technische Konzept der SAP ist der SAP NetWeaver. Er ist die
Integrations- und Anwendungsplattform, heterogene Umgebungen, Informationen und Geschäftsprozesse technologie- und organisationsübergreifend
zusammenführt. Alle zukünftigen Lösungen werden auf SAP NetWeaver aufbauen.
Der SAP NetWeaver ermöglicht die vollständige Interoperabilität mit Microsoft .NET. Die Interoperabilität wird auf Ebene der Anwendungsplattformen
über den Web Application Server, eine der zentralen Komponenten des
NetWeaver, bereitgestellt.
Mit dem SAP.NET-Connector können auf .NET basierende Windowsanwendungen, Webanwendungen und WebServices erstellt werden, welche dann
Zugriff auf Geschäftsfunktionen des SAP-Systems haben. In diesem Fall sind
die .NET-Anwendung der Client und das SAP-System der Server (Outside-
Seite 46
in). Umgekehrt kann auch eine SAP-Anwendung als Client auf einen .NET
Service (Server) zugreifen (Inside-out).
Der Datenaustausch geschieht hier mit RFC, es kann aber auch SOAP eingesetzt werden, welches für WebServices verwendet wird.
Systemvoraussetzungen und Installation
Um mit dem SAP.NET-Connector arbeiten zu können ist das Visual Studio.net und der Zugang zu einigen DLL’s des SAP-Systems Vorraussetzung.
Ist der SAP GUI auf dem System installiert, sollte die Verbindung zu SAP
erfolgreich herzustellen sein.
Der SAP .NET-Connector kann kostenlos im SAP Service Marketplace heruntergeladen werden25 . Zusätzlich ist die Installation der Java Runtime EnviTP
PT
ronment26 notwendig. Nach der erfolgreichen Installation dieser beiden
TP
PT
Komponenten steht bei der Erstellung eines neuen Projektes im Visual Studio das ICON .SAP Connector Class im Visual Studio .NET zur Auswahl. Bei
dieser Klasse handelt es sich um eine Proxyklasse. Ein Proxy ist ein Programm, das zwischen Server und Client vermittelt und das nur in C# geneH
H
H
H
riert werden kann.
Die Grundvoraussetzungen für die Anbindung an ein SAP-System sind
geschaffen.
4.8. Die TREX-Suchmaschine
Zu Anfang der Diplomarbeit wurde festgestellt, dass noch keine Suchmaschine für das Metadata Repository des BW existiert und TREX (Text Retrieval and Classification) installiert werden müsste.
Bei TREX handelt es sich um eine SAP-eigene Suchmaschine, welche über
diverse Suchfunktionen verfügt, von der allgemeinen Abfrage bis hin zu speziellen Begriffsabfragen. Außerdem ermöglicht der TREX-Server verschiedene Text-Mining-Funktionen
(exakte Suche, Phrasensuche, Boolesche
Suche, Fuzzysuche, linguistische Suche, Wildcard-Suche). Text Mining ist
TP
25
PT
[DowNET]
Seite 47
eine Sammlung von Techniken und Algorithmen zur automatischen Analyse
unstrukturierter Daten. Es sind hier ebenso alle Suchfunktionen vorhanden,
über die auch gängige Suchmaschinen im Internet verfügen.
Recherchen ergaben, dass TREX im Umfeld von VW bisher noch nicht produktiv im Einsatz ist. Diverse Testinstallationen sind jedoch vorhanden. Da
der Aufwand des Customizing von TREX als sehr hoch und somit teuer eingeschätzt wurde (ca. 40 Personentage), musste der Einsatz von TREX auf
das Jahr 2005 verschoben werden. TREX wird dann über das SAP Enterprise Portal zugänglich sein und für alle SAP-Module zur Verfügung stehen.
Die Anbindung von TREX an die Dokumentationsverwaltung wird dann von
geringem Aufwand sein, da beides webbasiert ist und sich die fertigen
Dokumentationen ganz normal im Metadata-Repository, auf welches TREX
zugreift, befinden.
4.9. Aufbau der Dokumentationsverwaltung
Aus den in diesem Kapitel beschriebenen Komponenten ergibt sich folgender
Aufbau.
Die Landschaft besteht aus drei Schichten. Zur Datenbankschicht gehören
zum einen die Datenbank vwfsdw1e mit den gesammelten Daten und den
sich in Bearbeitung befindlichen Dokumentationen und das SAP Portal, welches unter anderem aus dem SAP BW und dem in naher Zukunft
integriertern Suchmaschine TREX besteht. Das Portal ist durch den SAP
.NET-Connector mit der Applikationsschicht, bestehend aus IIS, den ASPXSeiten und dem Visual Basic Code, verbunden. Per Visual Basic bzw. ADO
wird sowohl mit der Datenbank als auch über SAP .NET Connector mit dem
SAP-System kommuniziert. Auf dem Client wird schließlich das Programm
angezeigt. Dieser sendet Http-Requests zum IIS, welcher nach Erhalt einer
Antwort dem Client per Http-Response das Ergebnis anzeigt.
TP
26
PT
[DowJRE]
Seite 48
Abbildung 4-4: Aufbau der Dokumentationsverwaltung
Seite 49
5. Anzeigen und Speichern von Daten
Damit der Benutzer diverse Informationen zu InfoObjects und ihren Dokumentationen einsehen kann, ist die Anzeige von im SAP-System befindlichen
Daten notwendig. Hierfür wird der SAP .NET-Connector verwendet. Weiterhin ist die Speicherung von Daten erforderlich, die der Anwender vor der
Anlage eines neuen InfoObjects sammelt. Diese werden wiederum in einer
separaten Oracle-Datenbank gespeichert. Wird ein InfoObject und seine
Dokumentation im BW angelegt, so gelangen die in der Oracle-Datenbank
gespeicherten Daten per SAP .NET-Connector in das SAP BW-System.
Im Folgenden werden zuerst der praktische Einsatz des SAP .NET-Connectors und anschließend der Aufbau der Oracle-Datenbank dargestellt.
5.1. SAP .NET Connector
In Kapitel 4 der SAP .NET-Connector und seine Installation bereits erwähnt.
Nachstehend wird erläutert, wie eine Proxy-Klasse erstellt wird und wie man
diese verwendet um SAP-Daten zu erhalten.
5.1.1.
Erstellung einer Proxy-Klasse
Um ein neues Projekt anzulegen, wird im Visual Studio die SAP Connector
Class ausgewählt (Abbildung 5-1).
Seite 50
Abbildung 5-1: Auswahl der SAP Proxy-Klasse
Nach der Erstellung des Projekts erscheint ein Assistent (Abbildung 5-2).
Diesem müssen alle Angaben zur Verbindung mit dem gewünschten SAPSystem mitgeteilt werden. Weiterhin ist der Objekttyp auswählbar. Bei dem
Client Proxy ist das .NET- Programm der Client und das SAP-System der
Server. Bei Auswahl des Server Stub ist das SAP-System der Client.
Abbildung 5-2: Der NET Connector Assistent (Logon)
Im nächsten Schritt können mithilfe eines Filters alle Funktionsbausteine des
SAP-Systems angezeigt werden. Je nach Bedarf werden ein oder mehrere
benötigte Funktionsbausteine ausgewählt (Abbildung 5-3).
Seite 51
Abbildung 5-3: Der NET Connector Assistent 2 (FuBa-Auswahl)
Nach erfolgreicher Generierung der Proxy-Klasse kann diese nun für den
Austausch von Daten mit dem SAP-System verwendet werden.
5.1.2.
Kommunikation von .NET per SAP-Funktionsbaustein
RFC_READ_TABLE
Für das Auslesen von Inhalten einer SAP-internen Tabelle wird der Funktionsbaustein RFC_READ_TABLE verwendet. Funktionsbausteine sind die
mit Abstand am häufigsten verwendete Methode, um anwendungsübergreifende wieder verwendbare Softwarekomponenten für ein SAP-System abzubilden. Dieser Funktionsbaustein hat die Aufgabe die Inhalte von SAP-Tabellen anzuzeigen.
Um eine Liste von InfoObjects anzeigen zu können, muss der Inhalt der
Tabelle RSDIOBJT ausgelesen werden. Diese Tabelle enthält eine Liste aller
InfoObjects mit Langtext (TXTLG), Kurztext (TXTSH) und der jeweiligen
Sprache dieser Texte (LANGU) sowie der Objektversion (OBJVERS)
(Abbildung 5-4)
Seite 52
Abbildung 5-4: SE16, Tabelle RSDIOBJT
Der Funktionsbaustein RFC_READ_TABLE
Zuerst erfolgt ein kurzer Einblick in die Funktionalität des Funktionsbausteins
RFC_READ_TABLE. Der Aufruf eines Funktionsbaustein kann sowohl innerhalb eines SAP-Systems als auch von anderen SAP-Systemen und Fremdsystemen per RFC (Remote Function Call) erfolgen. Da dieser Funktionsbaustein RFC-fähig ist, kann er von Außen, in diesem Fall mittels des SAP
.NET-Connector, aufgerufen werden27.
TP
PT
Im Deklarationsteil werden diverse Parameter angegeben: die Importparameter, welche beim Aufruf des Funktionsbausteins übergeben werden müssen, die Exportparameter, die nach Durchlauf des Programms an den Aufrufenden zurückgegeben werden, die Exceptions, die die Aufgabe haben, auf
einen Fehler im Programm zu reagieren und die Tabellenparameter, welche
die Parameter in Form von Tabellen definieren (Abbildung 5-5).
Der Quelltext selber wird durch FUNCTION und ENDFUNCTION eingeschlossen. Im Quelltext wird der Inhalt der gewünschten Tabelle mittels einer
Query ausgelesen und alle Inhalte in die Ausgabetabelle DATA geschrieben.
TP
27
PT
[Kel03]
Seite 53
Abbildung 5-5: Funktionsbaustein RFC_READ_TABLE
Erklärung der Importparameter
Um Daten ein oder mehrere Spalten einer Tabelle zu erhalten, müssen dem
Funktionsbaustein RFC_READ_TABLE folgende Import-Parameter von
außen übergeben werden:
Importparameter
Bedeutung
Delimiter
Markierung von Feldgrenzen
No_Data
falls <> NULL, wird nur Fields (s.u.)
gefüllt
Query_Table
Tabelle, aus der gelesen wird
Rowcount
Anzahl der zurückzugebenden Datensätze (Rows, Zeilen)
Rowskips
Anzahl der Zeilen, die übersprungen
werden sollen
Data
gelesene Daten (out), d.h. Inhalt der
Spalten
Seite 54
Fields
Namen der Tabellenfelder
Options
Selektionsangaben (Where-Clause)
Der Wert der zu dem Visual Basic-Programm zurückgegeben wird, ist Data.
Dieser Table-Parameter enthält die Inhalte der Tabelle.
5.1.3.
Verwendung eines Proxys mit VB
In der Dokumentationsverwaltung ist das SAP-System immer der Server und
die Visual Basic .NET- Anwendung der Client.
Wie oben beschrieben, wird mithilfe des Assistenten für den Funktionsbaustein RFC_READ_TABLE eine Proxy- Klasse erstellt. Diese heißt in der
Dokumentationsverwaltung
ebenfalls Rfc_Read_Table. Da der Quellcode
automatisch generiert wurde, wird auf diesen nicht weiter eingegangen.
Da die Proxy-Klasse in C# generiert ist, die Dokumentationsverwaltung aber
in Visual Basic implementiert ist, muss von einem separaten VB-Projekt aus
auf
die
Proxy-Klasse
zugegriffen
werden.
Diese
Klasse
heißt
IOBJListFromBW und kann ebenfalls im Anhang (Anhang B, S.104) eingesehen werden. Um den Quellcode besser verständlich zu machen, wird die
Implementierung erläutert.
Ist
das
VB-Projekt
erstellt,
muss
die
DLL
der
Proxy-Klasse,
die
SAP.Connector.dll und zusätzlich – bei einer Webanwendung – die
System.Web.Services.dll. in das Projekt eingebunden werden.
Die generierte Proxy-Klasse wird benötigt, um die Felder der Tabelle
(FIELDS) und die Selektionskriterien (OPTIONS) festzulegen. Die benötigten
Felder sind in diesem Fall der technische Name des InfoObjects (IOBJNM)
und der Langtext (TXTLG). Das erste Selektionskriterium bestimmt, ob die
InfoObjects mit dem deutschen oder dem englischen Langtext erscheinen
soll und das 2.Selektionskrieterium legt fest, dass nur die InfoObjects der
Objektversion A (= Aktiv) gezeigt werden sollen.
Seite 55
Weiterhin wird eine neue Instanz der SAP.Connector.Destination-Klasse erzeugt. Die Benutzer- und Systemdaten werden hier festgelegt, so dass der
Verbindungsaufbau zum SAP-System erfolgen kann.
Jetzt kann das Destination-Objekt initialisiert und die Verbindung zum SAPSystem geöffnet werden. Die Parameter, die der Funktionsbaustein zum
Ausführen benötigt, werden der Proxy-Klasse Rfc_Read_Table übergeben.
Diese Parameter wurden vorher festgelegt:
Rfc_Read_Table
(delimiter,
no_data,
Query_Table,
Rowcount,
Rowskips,
rsdiobj,
sapTableFields, sapTableOptions)
Der Aufruf der Klasse IOBJListFromBW, die mit der zuvor generierten ProxyKlasse kommuniziert, bewirkt wiederum den Aufruf des Funktionsbausteins
RFC_READ_TABLE. War dieser Aufruf erfolgreich, gibt der Funktionsbaustein den Rückgabeparameter DATA an die Klasse zurück, welcher den
Inhalt der gewünschten Tabellenspalten enthält.
Gespeichert wird der Inhalt der Spalten IOBJNM und TXTSH letztendlich in
der Variablen rsdiobj, welche vom Typ Tab512Table ist. Der erhaltene Inhalt
muss noch in zwei separate Spalten geteilt werden, einem DataTable zugeordnet und einem DataSet zugewiesen werden, welches schließlich an das
DataGrid gebunden wird.
Neuer User für den Zugriff auf RFC_READ_TABLE
Der Großteil der User hat im Normalfall keine Berechtigung per RFC auf
Funktionsbausteine zuzugreifen.
Damit jeder User der Dokumentationsverwaltung mithilfe des Funktionsbausteins RFC_READ_TABLE die SAP-Daten der internen Tabellen angezeigt
bekommt, wurde ein neuer User test02 eingeführt. Dieser User hat nur die
spezielle Berechtigung auf den Funktionsbaustein RFC_READ_TABLE
zuzugreifen.
Seite 56
Die Anzeige von InfoObjects aus der SAP-internen Tabelle RSDIOBJT sieht
folgendermaßen aus:
Abbildung 5-6: DataGrid mit Tabelleninhalt
5.1.4.
Verwendung von Funktionsbausteinen und Tabellen
Im Function Builder (Transaktion se37) können alle Funktionsbausteine des
SAP-Systems eingesehen werden. Die für diese Arbeit verwendeten Funktionsbausteine und ihre Funktionalität werden unten aufgelistet.
Funktionsbaustein
Funktionalität
Rsod_doc_meta_change Anlegen und Ändern von Dokumentationen
Bapi_iobj_create
Anlegen von InfoObjects im SAP BW-System
Rfc_read_table
Auslesen von SAP-internen Tabellen
Tabellen
Per Funktionsbaustein werden - wie erläutert - Daten diverser SAP-interner
Tabellen ausgelesen.
Die Tabelle IOBJ_PRFX ist eigens für die Dokumentationsverwaltung erstellt
und mit Daten gefüllt worden. Sie enthält eine Liste der Datentypen der
Seite 57
InfoObjects und ihre Abkürzungen. Diese Tabelle und die Tabelle tksysappl,
welche alle benötigten VW-Bank-Systeme und Applikationen enthält, sind
aufgrund der Notwendigkeit der Namenskonvention erstellt worden.
Folgende Tabellen finden in der Dokumentationsverwaltung Verwendung:
Tabelle
Erläuterung
rsdiobjt
Texte aller InfoObjects
Iobj_prfx
Datentypen der InfoObjects und Abkürzungen (Shortcuts)
5.2. Oracle – Datenbank vwfsdw1e
5.2.1.
Logischer Datenbankentwurf
Die Tabelle T_IOBJ (Abbildung 5-7) ist die Mastertabelle der Oracle-Datenbank. In dieser Tabelle werden die Daten gespeichert, die für jedes InfoObject gelten. während die Tabellen T_IOBJKYF und T_IOBJCHA nur die
Daten enthalten, die für Kennzahlen und Merkmale gelten. Dazu gehören
z.B. die Spalte IOBJ_ID, in der der Name des InfoObjects gespeichert ist und
die Spalte InfoArea der Tabelle T_IOBJ, in der die InfoArea steht, der das
InfoObject angehört.
Da ein InfoObject Texte in mehreren Sprachen besitzt, hat ein Eintrag in der
Tabelle T_IOBJ mehrere Datensätze in der Tabelle T_LANGUAGE (1:nBeziehung).
Weiterhin kann ein InfoObject mehrere Quellsystemeinträge besitzen. Somit
besteht zwischen der Tabelle T_IOBJ und T_SOURCESYSTEM eine 1:nBeziehung. Um einen Überblick über alle Tabellen der Oracle-Datenbank
vwfsdw1e zu bekommen, kann die Grafik im Anhang (Anhang C, S.107)
eingesehen werden.
Seite 58
Abbildung 5-7: Datenbanktabellen
5.2.2.
Physischer Datenbankentwurf
Nach dem logischen Datenbankentwurf erfolgt der physische Entwurf, also
die Implementierung des logischen Modells. Die Implementierung erfolgt mit
Hilfe der DDL (Data Definition Language), der Sprache zur Definition von
Datenbankobjekten. Per Create Table-Anweisungen werden Tabellen und
ihre Spalten erstellt.
CREATE TABLE t_iobj
(iobj_pk_id
NUMBER(9,0) NOT NULL,
iobj_id
VARCHAR2(20) NOT NULL,
gistype
NUMBER(1,0) DEFAULT 0,
contenttimestamp
NUMBER(1,0) DEFAULT 0,
hasdescriptionlong
hasdescriptionmiddle
hasdescriptionshort
infoobjecttype
infoarea
iobj_fk_projectpart
VARCHAR2(5) DEFAULT 'true',
VARCHAR2(5) DEFAULT 'false',
VARCHAR2(5) DEFAULT 'true',
VARCHAR2(9) DEFAULT NULL
VARCHAR2(9),
NUMBER(9,0),
Seite 59
iobj_fk_reference
iobj_format
iobj_annotation
iobj_fk_status
NUMBER(9,0),
VARCHAR2(30),
VARCHAR2(100),
NUMBER(3,0) DEFAULT 0
iobj_isiobjkyf
iobj_isiobjcha
iobj_bwappl
iobj_iscreatedinbw
NUMBER(1,0),
NUMBER(1,0),
VARCHAR2(9) DEFAULT 'BW'
NUMBER(1,0) DEFAULT 0
CONSTRAINT PK_IOBJ
PRIMARY KEY (iobj_pk_id)
)
/
-- Constraints for T_IOBJ
ALTER TABLE t_iobj
ADD CONSTRAINT ch_iobj_iobjtype CHECK ("INFOOBJECTTYPE"='CHA' AND
"IOBJ_ISIOBJKYF" IS NULL AND "IOBJ_ISIOBJCHA" IS NOT NULL OR
"INFOOBJECTTYPE"='KYF' AND "IOBJ_ISIOBJCHA" IS NULL AND "IOBJ_ISIOBJKYF" IS
NOT NULL)
DISABLE
/
ALTER TABLE t_iobj
ADD CONSTRAINT uniqueiobj_id UNIQUE (iobj_id)
/
-- Comments for T_IOBJ
COMMENT ON COLUMN t_iobj.iobj_annotation IS 'pers. Bemerkung, die beim Anlegen des
IOBJ gemacht wurde'
/
COMMENT ON COLUMN t_iobj.iobj_fk_reference IS 'the iobj_pk_id of the IOBJ THIS IOBJ
is reference from'
/
COMMENT ON COLUMN t_iobj.iobj_fk_status IS 'New IOBJ''s are always 0 (=NEW)'
/
-- End of DDL Script for Table DWOWN.T_IOBJ
-- Foreign Key
ALTER TABLE t_iobj
ADD CONSTRAINT fk_projectpart_iobj FOREIGN KEY (iobj_fk_projectpart)
REFERENCES t_projectpart (pp_pk_id) ON DELETE CASCADE
/
-- End of DDL script for Foreign Key(s)
Beispiel 5-1: Create Table- und Contraint-Anweisungen
Wie in Beispiel 5-1 zu sehen gehören Constraints, Trigger und Sequences
zum physischen Datenbankentwurf. Constraints gewährleisten die Datenintegrität. Dazu gehören Primärschlüssel, referentielle Constraints und einfache feldgebundene Prüfungen. Auch sind sie wichtig, um einen Wertebereich
Seite 60
zu ergänzen oder um die Abhängigkeit von Tabellen untereinander festzulegen.
Sequenz und Trigger
Jeder Datensatz hat einen eindeutigen Schlüssel, genannt Primary Key. Um
die Eindeutigkeit zu gewährleisten, werden diese Zahlen bei jedem Einfügen
eines Datensatzes von der Datenbank automatisch vergeben. Dazu sind eine
Sequenz und ein Trigger zu erstellen. Eine Sequenz ist ein Datenbankobjekt,
das
aufsteigende
Nummern
performant
generiert.
Die
Sequenz
S_DW_Autowert generiert ganze Zahlen mit dem Inkrement von 1.
CREATE SEQUENCE s_dw_autowert
INCREMENT BY 1
START WITH 1
MINVALUE 1
MAXVALUE 99999999
NOCYCLE
NOORDER
CACHE 20
Beispiel 5-2: Sequence S_DW_AUTOWERT
Damit die von der Sequenz generierte Zahl in die entsprechenden Spalten
eingefügt wird, muss ein Trigger erstellt werden. Ein Trigger ist ein Programm, welches ausgelöst (getriggert) wird, bevor oder nachdem eine
Delete-, Insert- oder Update-Anweisung ausgeführt wird. Dieser Trigger
tr_iobj wird vor jeder Insert-Anweisung ausgelöst und bewirkt, dass die von
der Sequence generierte Zahl in die Tabelle eingefügt wird.
CREATE OR REPLACE TRIGGER tr_iobj
BEFORE
INSERT
ON t_iobj
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
-- Wenn Primary Key Identifier nicht gefuellt ist,
-- automatisch mit Sequenznummer fuellen
if :NEW.iobj_PK_ID is Null then
-- HOLT WERT AUS SEQUENCE S_DW_AUTOWERT
Seite 61
select S_dw_AUTOWERT.nextval into :new.iobj_PK_ID from
DUAL;
end if;
END;
Beispiel 5-3: Trigger TR_IOBJ
Für alle anderen Tabellen wird auch ein Trigger TR_[Tabellenname] erstellt.
Stored Procedure / Function
Diverse Datenbankmanipulationen lassen sich sowohl mit Visual Basic-Code
und ADO als auch mit Oracle Stored Procedures und Functions realisieren.
Der größte Vorteil in der Realisierung von Stored Procedures und Functions
liegt darin, dass diese gekapselt in der Datenbank vorliegen und mit den
Rechten des Schemaowners versehen sind. So kann der Anwender die Procedure nur mit den entsprechenden Rechten ausführen.
Sie sind auch performanter als Visual Basic Code. Bei mehreren SQL-Anweisungen
wirkt
sich
das
auf
die
Geschwindigkeit
aus.
Ein weiterer Vorteil ist, dass zum Auslesen von Tabellen, im Visual Basic
Quellcode nur die Prozedur angegeben werden muss. Wenn nun an einer
Datenbanktabelle etwas zu ändern ist, muss nicht die betreffende Stelle im
Visual Basic Quellcode gesucht und geändert werden, sondern nur die
datenbanknahe Stored Procedure.
Stored Procedures und Functions werden mit der von Oracle entwickelten
SQL-Erweiterung PL/SQL geschrieben. PL/ SQL steht für procedural language/ structured query language und ist eine prozedurale Sprache und kann
aus mehreren auch ineinander verschachtelten Blöcken bestehen.
In Kapitel 6 werden die erstellten Stored Procedures und Functions vorgestellt. Der Quellcode ist im Anhang einzusehen.
Einfügen eines Test-InfoObjects in die Datenbank
Um Daten in die Tabellen schreiben zu können, wird die DML (Data Manipulation Language) verwendet. Zu Testzwecken sollen später (Kapitel 6) alle
Daten eines InfoObjects in die Tabellen eingefügt werden. In dem unten zu
Seite 62
sehenden Beispiel werden Testdaten für ein Merkmals-InfoObject in die
Tabellen eingefügt:
Zuerst werden der Name (iobj_id), der Typ (Merkmal oder Kennzahl) und die
InfoArea in die Haupttabelle T_IOBJ eingefügt.
insert into t_iobj (iobj_id, infoobjecttype, infoarea, iobj_annotation) values
('YTESTCHA', 'CHA', 'TESTAREA', '')
Nach dem Insert wird der Trigger TR_IOBJ_LANGUAGE_INSERT (Beispiel
5-4) ausgelöst, welcher für alle Sprachen neue Datensätze für das InfoObject
einfügt. Dieses ist notwendig, da später, wenn das DataGrid, in welches die
Eintragungen gemacht werden, erstellt wird, es nicht aus Versehen zu doppelten Eintragungen in T_Language kommt und nicht bei jeder Änderung
überprüft werden muss, ob der Datansatz schon existiert. Nachdem der Trigger für jede Sprache einen Datensatz angelegt hat, müssen diese nur noch
per Update ergänzt werden.
CREATE OR REPLACE TRIGGER tr_iobj_language_insert_rows
AFTER
INSERT
ON t_iobj
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
--:NEW.PK_RELATION :=
--:NEW.iobj_pk_id :=
P_INSERT_LANGUAGES(:NEW.iobj_pk_id);
END;
Beispiel 5-4: Trigger TR_IOBJ_LANGUAGE_INSERT
Die
Procedure
P_INSERT_LANGUAGE
wird
von
dem
Trigger
TR_IOBJ_LANGUAGE_INSERT aufgerufen. Mittels eines Cursors wird in
der Tabelle T_LINGUA geschaut, in welchen Sprachen die Dokumentationen
anzulegen sind. Für jede Sprache wird dann ein Datensatz in der Tabelle
T_LANGUAGE angelegt.
Seite 63
PROCEDURE P_INSERT_LANGUAGES
(iobj_pk_id Number)
IS
--cursor traverses t_lingua to get all languages
cursor cursorLanguage IS Select li_short from t_lingua;
BEGIN
FOR c1 IN cursorLanguage
LOOP
Insert into t_language (la_fk_iobj, la_language) values ( iobj_pk_id , c1.li_short);
END LOOP;
END; -- Procedure
Beispiel 5-5: P_INSERT_LANGUAGES
Nachdem für alle Sprachen jeweils ein Datensatz in T_LANGUAGE existiert,
können die Inhalte per UPDATE für jede Sprache vervollständigt werden.
--English
update t_language set la_desc_short='descshorte', la_desc_long='desclonge',
la_desc_tec='desctece', la_desc_econ='descecone'
where la_fk_iobj=838 and la_language='E'
/
--Deutsch
update t_language set la_desc_short='descshortg', la_desc_long='desclongg',
la_desc_tec='desctecg', la_desc_econ='descecong'
where la_fk_iobj=838 and la_language='D'
/
--Französisch
update t_language set la_desc_short='descshortf', la_desc_long='desclongf',
la_desc_tec='desctecf', la_desc_econ='desceconf'
where la_fk_iobj=838 and la_language='F'
T_SOURCESYSTEM
Die Beziehung von T_IOBJ zu T_SOURCESYSTEM ist eine 1 : 0..N-Beziehung, da ein InfoObject Daten aus keinem oder ein- oder mehreren Quellsystemen bezieht. Für das Test-InfoObject werden zwei Datensätze angelegt:
Seite 64
-- Erster Datensatz
INSERT INTO t_sourcesystem
(SO_SOURCESYSTEM,SO_INTERFACEFILE,SO_FIELDNAME_OS,SO_FIELDLABEL_OS
,
SO_SAS_LIBRARY,SO_TABLE,SO_FIELD,SO_DATATYPE,SO_LENGTH,SO_FORMAT,
SO_TRANSFORMATION,SO_FK_IOBJ,SO_FK_ODS,SO_ANNOTATION)
VALUES
('Sourcesystem','Interfacefile','Filename','Fieldlabel','Sas_Library','Table',
'Field','Datatype','Length','Format','Transformation',838,NULL,'Annotation')
/
-- Zweiter Datensatz
INSERT INTO t_sourcesystem
(SO_SOURCESYSTEM,SO_INTERFACEFILE,SO_FIELDNAME_OS,SO_FIELDLABEL_OS
,
SO_SAS_LIBRARY,SO_TABLE,SO_FIELD,SO_DATATYPE,SO_LENGTH,SO_FORMAT,
SO_TRANSFORMATION,SO_FK_IOBJ,SO_FK_ODS,SO_ANNOTATION)
VALUES
('Sourcesystem2','Interfacefile2','Filename2','Fieldlabel2','Sas_Library2','Table2',
'Field2','Datatype2','Length2','Format2','Transformation2',838,NULL,'Annotation2')
Je nachdem, ob es sich um eine Kennzahl oder ein Merkmal handelt, wird
ein Eintrag in T_IOBJCHA oder T_IOBJKYF mit sämtlichen Parametern
erfolgen. Da das Test-InfoObject ein Merkmal ist, wird ein Eintrag in
T_IOBJCHA geschrieben.
INSERT INTO t_iobjcha
(CHA_CHACONST,CHA_CHAPRSNT,[…]
,CHA_CHECKODS,CHA_AUTHFIELD,CHA_FK_IOBJ)
VALUES
(NULL,'0',[…] ,NULL,NULL,838)
Jetzt sind alle Eintragungen für das InfoObject in der Datenbank gespeichert
und es kann eine Dokumentation erstellt und das InfoObject im SAP BWSystem angelegt werden. Die Speicherung gilt als Grundlage für die Erstellung der Dokumentation und der Anlage des InfoObjects im SAP BW-System
in Kapitel 6.
Seite 65
6. Prozess der Erstellung eines InfoObjects und
seiner Dokumentation im SAP BW-System
Inhalt dieses Kapitels ist die Beschreibung der einzelnen Schritte der Prozesserstellung eines InfoObjects und seiner Dokumentation im SAP BWSystem.
InfoObjects müssen oftmals bei neuen Projekten oder deren Weiterentwicklung angelegt bzw. definiert werden. Zuerst muss geschaut werden, ob ein
ähnliches InfoObejct schon im SAP BW-System existiert. Beim Anlegen
eines neuen InfoObjects ist der Idealfall die gleichzeitige Erstellung einer
zugehörigen Dokumentation in allen benötigten Sprachen.
Die Erstellung dieser Dokumentation und die Anlage eines InfoObjects werden hier als Prozess, bzw. Geschäftsprozess bezeichnet. Hauptziele der
Einführung dieses Prozesses sind zum einen die Vermeidung redundanter
Entwicklung, welche oftmals doppelt vorkommende InfoObjects im SAP BWSystem zur Folge hat und zum anderen die Sicherstellung, dass für jedes
InfoObject eine qualitätsgeprüfte Dokumentation existiert. Aus diesem Grund
erfolgt die Erstellung durch drei Personen, von denen jeweils eine der Rolle
Developer (Entwickler), Customer (Auftraggeber) und Supervisor (Kontrolleur) angehört.
Tritt der Geschäftsfall ein, dass ein neues InfoObject im Rahmen eines Projektes erstellt werden muss, wird folgender Prozess durchlaufen.
6.1. Erläuterung des Geschäftsprozesses
Der Entwickler, der das neue InfoObject erstellen möchte, öffnet die Seite
mainIOBJ.aspx der Dokumentationsverwaltung, in welcher er ein neues
InfoObject anlegt. Damit ein InfoObject nicht doppelt existiert, muss überprüft
werden, ob es schon ein InfoObject mit ähnlichem Namen gibt. Existiert
Seite 66
schon ein oder mehrere ähnliche InfoObjects, so bekommt er ein Liste mit
diesen InfoObjects zu sehen. Findet er ein InfoObject, das seinem neu
anzulegenden InfoObject entspricht, bricht das Programm ab.
Gibt es noch kein InfoObject dieser Art, werden alle vom Developer
gemachten Eingaben in der Datenbank gespeichert. Jetzt kann er sein
InfoObject freigeben. Mit der Freigabe wird eine Nachricht an den
zuständigen Customer geschickt. Dieser füllt nun den wirtschaftlichen Teil
vollständig aus und gibt ihn wiederum frei. Diese Freigabe bewirkt, dass eine
Nachricht an den Supervisor geschickt wird, damit der Supervisor die
Dokumentation überprüfen und bei Korrektheit freigeben kann. Nun kann der
Fall eintreten, dass der Supervisor einen Teil der Dokumentation zu
bemängeln hat. In diesem Fall schickt er, je nachdem ob Entwickler- oder
Auftraggeberteil, eine Nachricht an die betreffende Person mit der Bitte um
Korrektur. Ist die Korrektur erfolgt, prüft der Supervisor erneut und gibt im
Normalfall die Dokumentation frei.
Nach Freigabe wird vom System das InfoObject im SAP BW angelegt und
die in verschiedenen Sprachen vorhandenen zugehörigen Dokumentationen
in dem Content Repository abgelegt. Die Dokumentation kann jetzt im SAP
BW von allen Anwendern der Dokumentationsverwaltung in der jeweiligen
Anmeldesprache eingesehen werden.
In diesem Kapitel wird die Implementierung und die Vorgehensweise der
Speicherung aller relevanten InfoObject-Daten in der Datenbank, die
Erstellung und der Transfer der Dokumentationen in das SAP BW-System
und das Anlegen des
InfoObjects im SAP BW-System detailliert
beschrieben.
Nicht implementiert wurde aufgrund des großen Umfangs die Realisierung
der Rollen. Mit Rollen ist die Einführung der Benutzergruppen Entwickler,
Auftraggeber und Supervisor, welche verschiedene Rechte besitzen,
gemeint. Das theoretische Konzept für eine Realisierung der Rollen wird in
Kapitel 7 anhand eines Geschäftsprozesses und Aktivitätsdiagramms
erläutert.
Seite 67
6.2. Überblick/ Hauptseite
Es folgt ein Überblick über das Front-End. Im Anschluss daran wird die
Implementierung aus technischer Sicht erläutert.
Auf der Hauptseite mainIOBJ (Abbildung 6-1) werden die Daten eines
InfoObjects gesammelt. Von der Hauptseite aus gehen weitere Seiten ab, in
denen Daten eingetragen werden können. Ein guter Überblick über die
einzelnen Seiten ist im Anhang (Anhang D, S.108) zu finden.
Der Anwender gibt die englischen Beschreibungen (Langbeschreibung,
Kurzbeschreibung, wirtschaftliche Beschreibung, technische Beschreibung)
und wichtige Meta-Informationen des InfoObjects ein. Mit Klick auf den
Button OK legt er einen Datensatz in der Datenbanktabelle T_IOBJ an.
Weiterhin kann man durch Aufrufen der Links alle Daten, die für die Anlage
eines InfoObjects und seiner Dokumentation erforderlich sind, ergänzen. Zu
diesen Daten gehören die Beschreibungen (Button Descriptions) in allen
weiteren Sprachen (zur Zeit Deutsch und Französisch), Quellsysteme
(Button Sources), Ausprägungen (Button Characteristics) und Metadaten
(Button Metadata). Sind alle Eintragungen gemacht, kann durch Auslösen
des Buttons Create_Doc die Dokumentation im SAP BW angelegt und durch
Bestätigung des Buttons Create_IOBJ das InfoObject erstellt werden
Seite 68
Abbildung 6-1: mainIOBJ.aspx; Front-End
6.3. Erstellung von HTML-Dokumentationen aus relationalen
Daten
Dieses Kapitel beschreibt den Prozess der Ablage von InfoObject-Daten in
die Datenbank bis hin zur Erzeugung von XML-Dokumenten, der
Transformierung mittels XSL in HTML-Dokumente und den anschließenden
Import in das SAP BW aus technischer Sicht.
Für die Erzeugung von HTML-Dokumentationen aus relational gespeicherten
Daten wurden im Rahmen dieser Arbeit eine Oracle-Stored Procedure und
eine Oracle-Function entwickelt (Abbildung 6-2).
Seite 69
Abbildung 6-2: Generierung von HTML- Dokumentationen
6.3.1.
Anlage einer XML-Dokumentation in der Datenbank
Aus allen relevanten Daten, die in der Datenbank gespeichert sind, wird für
jede Sprache eine XML-Dokumentation generiert und in der Datenbank
zwischengespeichert. Aus dieser XML-Dokumentation wird später eine
HTML-Dokumentation generiert, welche in das SAP BW geladen wird.
Im Folgenden wird die Generierung von XML-Dokumentationen erläutert.
Diese werden bei Aufruf der Stored Procedure P_CREATE_XMLDOCS
(Anhang E, S.111) erstellt und als Datentyp Xmltype in der Spalte
La_Xmldoc der Tabelle T_LANGUAGE gespeichert.
Um die für die Dokumentation benötigten Inhalte als XML-Dokument
darstellen zu können, werden mithilfe des Oracle-eigenen PL/SQL-Packages
Seite 70
Dbms_xmlgen28 aus den relational gespeicherten Daten XML-Dokumente
TP
PT
generiert.
Mit Dbms_xmlgen
ist es möglich, mit Hilfe einer SQL-Query ein XML
Dokument zu erstellen. Die Ergebnisse einer Query werden als XML
dargestellt und können
z.B. als Datentyp Clob oder Xmltype in der
Datenbank gespeichert werden.
Dbms_xmlgen hat diverse Subprogramme in Form von Prozeduren oder
Funktionen.
In
diesem
Fall
werden
die
Prozeduren
SetRowTag,
setRowSetTag und die Funktionen newContext und getXML für die
Erstellung der XML-Dateien verwendet.
Die Prozedur SetRowTag legt den Elementnamen fest, der das jeweilige
Ergebnis der Abfrage bei mehreren Ergebnissen einschließt, während mit
SetRowSetTag der Elementname des ganzen Ergebnisses festgelegt wird.
Der Funktion newContext, die als Handle fungiert, wird ein QueryString
übergeben, der der Funktion getXMLType übergeben wird. Die Funktion
getXMLType generiert das XML-Dokument und gibt es als XMLType zurück.
Um die Abfragen einfacher zu gestalten, damit in Zukunft Änderungen leicht
vorgenommen, werden können, werden die für die Dokumentation benötigten
Spalten für jede Tabelle einzeln per Select-Anweisung abgefragt. Eine
Select-Abfrage über die Haupttabelle T_IOBJ ergibt das Haupt-XMLDokument, welchem alle weiteren Informationen hinzugefügt werden. Diese
Informationen befinden sich in den Tabelleneinträgen T_LANGUAGE,
T_CHARACTERISTIC und T_SOURCESYSTEM. Um diese Informationen
hinzufügen zu können, werden erst für jede Tabelle per Queries XMLFragmente generiert. Diese werden dann in das Haupt-XML-Dokument
eingefügt.
Da ein InfoObject derzeit drei physische Dokumentationen (Deutsch,
Englisch und Französisch) hat, ist der Taginhalt der Beschreibungen
unterschiedlich. Aus diesem Grund muss die Abfrage über die Tabelle
T_LANGUAGE für jede Sprache einzeln erfolgen.
TP
28
PT
[Ora]
Seite 71
Damit es keiner weiteren Anpassungen bedarf, wenn eine neue Sprache
hinzukommt, erfolgt die Generierung der Teil-Dokumentationen automatisch
mit Hilfe eines Cursors, der mit einer Schleife kombiniert wird.
Nun ist die XML-Dokumentation (Anhang F, S.114) für alle Sprachen in der
Datenbank gespeichert.
6.3.2.
Transformation mittels XSL in das HTML-Format
Eine Dokumentation wird zur Ansicht im SAP BW-System in HTML
transformiert. Die Transformation eines XML-Dokuments in ein HTMLDokument geschieht mithilfe eines XSL-Templates. Die XSL-Templates sind
in der Tabelle T_XSLDOC gespeichert. Ein BW-Objekt hat dabei zurzeit drei
Templates, je eines für Englisch, Deutsch und Französisch.
Die Function F_Create_XSLDocs (Anhang G, S.116) generiert mittels der
Oracle-Funktion XMLTRANSFORM ein HTML-Dokument und gibt diesen als
RETURN-Wert zurück an das aufrufende VisualBasic-Programm. Als
Argument müssen der Funktion XMLTransform das XML-Dokument vom Typ
XMLType und das XSL-Dokument ebenfalls vom Typ XMLType übergeben
werden.
6.3.3.
Wird
Anzeige der Dokumentationen
der
Button
Show
Doc.
ausgewählt,
öffnet
sich
die
Seite
ShowDocumentation und es wird die gewünschte Dokumentation im HTMLFormat angezeigt. Dieses geschieht durch Aufruf der bereits erwähnten
Oracle-Function F_create_XSLDOCS. Um eine Oracle-Function aus einem
Visual
Basic-Programm
System.Data.OracleClient
aus
(ab
aufrufen
.NET
zu
können,
Framework
wird
1.1)
die
Klasse
benötigt.
Der
Rückgabewert ist die generierte HTML-Datei (Anhang D, S.108). Diese wird
dem Client zum betrachten im Browser angezeigt. Angewendet wird dabei
die Methode Response.ContentType.
Die HTML-Datei befindet sich jetzt noch nicht im SAP BW-System. Wie die
Dokumentation in das BW gelangt, wird im Unterkapitel 6.3.4 erklärt.
Seite 72
6.3.4.
Anlage der Dokumentationen im SAP BW-System
Die per Function F_Create_XSLDocs in das HTML-Format transformierten
Dokumentationen werden bei Bestätigung des Buttons Create Doc in das
SAP BW-System transportiert.
Zuerst werden die InfoObject-Dokumentationen für alle drei Sprachen auf der
Serverfestplatte temporär zwischengespeichert und schließlich in das SAP
BW-System
geladen.
Dieses
geschieht
mit
dem
Proxy
proxy_rsod_doc_meta_change. Dabei wird darauf geachtet, dass alle
Beschreibungen vorhanden sind. Diese Überprüfung nimmt die OracleFunction F_Checkifdescriptions vor.
6.4. Anlegen eines InfoObjects im SAP BW-System
Nachdem die Dokumentation erfolgreich angelegt wurde, wird mittels des
SAP-Funktionsbausteins BAPI_IOBJ_CREATE das InfoObject im SAP BW
FBE angelegt.
Um das InfoObject im SAP BW-System anlegen zu können müssen alle
Metadaten in der Datenbank vorhanden sein. Die Metadaten befinden sich in
den Datenbanktabellen T_IOBJ, T_IOBJKYF bzw. T_IOBJCHA.
Klickt der Anwender auf den Button Metadata öffnet sich je nachdem ob es
sich um ein Merkmal oder eine Kennzahl handelt entweder die Seite
IOBJKYF oder IOBJCHA. Nach Eintrag der Werte und nach Betätigung des
Buttons Save wird ein neuer Datensatz in die Tabelle eingetragen. Erst wenn
dieser Datensatz existiert, besteht die Möglichkeit ein InfoObject per RFC
anzulegen. Diese Möglichkeit ist durch den Button Create_IOBJ gegeben.
Seite 73
Vollständigkeitsprüfung
6.4.1.
Nach Auslösen des Buttons Create_IOBJ wird – nach eingehender Prüfung –
das InfoObject angelegt.
Die
Prüfung
erfolgt
durch
Aufruf
der
Oracle-Funktion
F_CHECKCREATEIOBJ (Anhang H, S.117). Dieser Funktion wird der
Primärschlüssel iobj_pk_id übergeben und die Daten des InfoObjects werden
auf Vollständigkeit überprüft.
Diese Abfragen werden der Reihe nach für das entsprechende IOBJ getätigt:
1. Überprüfung, ob die Datensätze zu allen verlangten Sprachen in
T_LANGUAGE festgelegt wurden.
2. Kontrolle, ob die Kurz- und Langbeschreibungen zu allen drei
Sprachen existieren
3. Überprüfung, ob genau ein Eintrag in der Tabelle T_IOBJCHA – wenn
es sich bei dem IOBJ um ein Merkmal handelt – oder ob genau ein
Eintrag in der Tabelle T_IOBJKYF existiert. Dieses ist dann der Fall,
wenn der Anwender zuvor die Parameter unter dem Button Metadata
eingestellt und gespeichert hat.
Ist eine der Überprüfungen nicht erfolgreich, bekommt der Anwender den
entsprechenden Hinweis, er möge z.B. die fehlenden Eingaben noch
ergänzen.
Ist dagegen alles korrekt, so wird, je nachdem ob es sich um ein Merkmal
oder eine Kennzahl handelt, der Parameter KYF oder CHA zurückgegeben,
damit bekannt ist, ob die Parameter für eine Kennzahl oder ein Merkmal
benötigt werden.
6.4.2.
Anlage des InfoObjects per Funktionsbaustein im SAP BW
Nun erfolgt die Anlage des InfoObject im SAP BW-System mittels des
Funktionsbausteins Bapi_iobj_create.
Mit Hilfe der Oracle-View V_CreateIOBJCHA werden alle Daten, die für die
Anlage des InfoObjects benötigt werden, in das DataSet geladen. Wie in
Seite 74
Kapitel 5 beschrieben, wird abermals ein Proxy für die Verbindung mit dem
Funktionsbaustein BAPI_IOBJ_CREATE benötigt. Von dem Parameter
BAPI6108 wird eine neue Instanz, die hier DATA genannt wurde erzeugt.
Alle Daten aus der Datenbank werden nun an die Eigenschaftswerte
(Data.version) usw. gebunden und schließlich wird das InfoObject unter
Angabe diverser Parameter mit der Proxy-Funktion BAPI_IOBJ_CREATE
angelegt.
War
die
Anlage
erfolgreich,
wird
der
Inhalt
des
Datanbankfeldes
iobj_isCreatedInBW auf 1 (= wurde im BW-System erfolgreich angelegt)
gesetzt. Dies garantiert, dass der Versuch ein bereits existierendes
InfoObject anzulegen, von vornherein abgebrochen wird.
Die Anlage des InfoObjects kann im SAP BW-System kontrolliert werden. Mit
der Transaktion RSD1 ist das InfoObject mit den Parametereinstellungen
einzusehen:
Abbildung 6-3: RSD1, Anzeige des InfoObject s
Nun ist die Implementierung für die Anlage eines InfoObjects im BW und
seiner verschiedensprachigen Dokumentationen abgeschlossen.
Seite 75
7. Ausblick
Im folgenden Kapitel werden Möglichkeiten zur Erweiterung des Programms
beschrieben. Dabei werden Techniken und Methoden, die für die praktische
Umsetzung bedeutsam sein können, näher erläutert. Die einzelnen
Vorschläge wurden auf Realisierbarkeit getestet.
Diverse Komponenten können das Programm sinnvoll erweitern. Zuerst wird
über alle Komponenten ein Überblick gegeben, eine detaillierte Beschreibung
folgt in den einzelnen Unterkapiteln:
•
Rollenkonzept (User, Developer, Customer, Supervisor)
•
Versionisierung und Historisierung der Datenbankeinträge
•
Persönlicher Bereich, Benutzereinstellungen
•
Migration vorhandener InfoObject-Daten in die Oracle-Datenbank
•
Erweiterung der Implementierung um zusätzliche BW-Objekte
•
Einführung einer weiteren Sprache
•
Navigationsmöglichkeiten der Dokumentationsverwaltung
•
Erweiterung auf andere BW-Objekte
•
Direkte Anzeige einer Online-Dokumentation zu BW-Objekten
•
Anbindung an TREX und Einbindung in das SAP Enterprise Portal
7.1. Rollen
Da in Zukunft unterschiedliche Benutzergruppen das Programm verwenden
werden, ist die Einführung von Rollen notwendig. Rollen sind eng mit den
Rechten verknüpft. Jede Rolle besitzt diverse Rechte. So hat die Rolle User
nur das Recht zu lesen während die anderen Rollen auch die Rechte haben
in definierten Bereichen zu schreiben.
Die einzelnen Rollen sind:
Seite 76
•
Developer (Entwickler)
•
Supervisor (ein oder zwei für die Qualitätsüberprüfung bestimmte
Personen)
•
Customer (Auftraggeber des Fachbereichs)
•
User (Anwender mit dem Grundrecht Lesen)
Durch die Einführung von Rollen und Rechten ist die Datenqualität
gewährleistet, da nur mit den entsprechenden Rechten Daten geändert
werden können.
7.1.1.
Realisierung der Rollen
Die Realisierung der Rollen erfolgt mittels des Treeviews (s. Kap.7.7). Durch
den Treeview ist gewährleistet, dass ein Anwender, welcher einer
bestimmten Rolle angehört, nur mittels des Treeviews Zugriff auf bestimmte
Seiten hat.
Da die Anlage eines BW-Objekts und seiner Dokumentation ein Prozess ist,
an dem Anwender mit den drei Rollen Developer, Customer und Supervisor
beteiligt sind, erfordert die Realisierung dieses Prozesses eine genaue
Analyse.
Auf Basis der Rollen lassen sich die Zuständigkeiten in dem Prozess der
Erstellung einer InfoObject-Dokumentation realisieren. Dieser Prozess wird in
der Softwaretechnik als Geschäftsprozess bezeichnet. Ein Geschäftsprozess
(engl.: business process) ist eine Menge von miteinander verknüpfter
Aktivitäten, welche in einer bestimmten Reihenfolge ausgeführt werden, um
ein festgelegtes Ziel zu erreichen. Die verschiedenen Aktivitäten können
sequentiell und/oder parallel gestartet und ausgeführt werden.29
TP
PT
Da der Geschäftsprozess Erstellung einer InfoObject-Dokumentation sehr
umfangreich ist, ist er auch gleichzeitig ein eigener Meilenstein. „Ein
Geschäftsprozess
zusammenhängenden
TP
29
PT
ist
eine
Zusammenfassung
Aktivitäten,
die
[Beats]
Seite 77
notwendig
von
sind,
fachlich
um
einen
Geschäftsfall zu bearbeiten. Die einzelnen Aktivitäten können organisatorisch
verteilt
sein,
stehen
aber
Abhängigkeiten zueinander“
gewöhnlich
in
zeitlichen
und
logischen
TP
30
PT
Die einzelnen Aktivitäten werden auch Anwendungsfälle genannt. „Ein
Anwendungsfall sollte beschreiben, was ein Benutzer zu einem Zeitpunkt an
einem Anwendungssystem macht, um einen Geschäftsvorfall in einem
Geschäftsprozess zu bearbeiten“31 Zudem führt ein Anwendungsfall immer
TP
PT
zu einem wahrnehmbaren Ergebnis.
Im Folgenden ist der Geschäftprozess tabellarisch aufgezeigt. Er besteht aus
4 zeitlich abhängigen Anwendungsfällen. Diese enthalten zum Teil
Erweiterungen (1A, 4A). Eine Erweiterung ist eine alternative Variante eines
Anwendungsfalls.
7.1.2.
Geschäftsprozess
Geschäftsprozess: Anlegen einer InfoObject-Dokumentation
T
T
Von der Erstellung der Mindestinformationen eines InfoObjects bis zur
Freigabe der InfoObject-Dokumentation.
Vorbedingung:
-
Nachbedingung:
BW-Objekt und Dokumentation werden im SAP BW
angelegt
Akteure:
Customer, Developer, Supervisor
Auslösendes Ereignis:
Beschreibung
1. Anwendungsfall: Prüfung, ob IOBJ schon vorhanden
2. Anwendungsfall: Freigabe Developer
3. Anwendungsfall: Freigabe Customer
4. Anwendungsfall: Freigabe Supervisor
Erweiterungen:
30
TP
PT
TP
31
PT
[Gal]
[Oes97]
Seite 78
1.A
Wenn vorhanden, dann Abbruch und Anzeige einer
Liste der vorhandenen IOBJ’s und deren Dokus
4.A
Bei Bemängelung werden Prozess 2 und/oder 3
wiederholt, danach Wiedereinstieg bei 4
Aktivitätsdiagramm
Um den Ablauf des Geschäftsprozesses detailliert beschreiben zu können,
eignen sich insbesonders Aktivitätsdiagramme. „Ein Diagramm, bestehend
aus Aktions-Zuständen und Zustandsübergängen (Transition), heißt in der
UML Aktivitätsdiagramm (engl.: aktivity diagram) und stellt eine Variante
eines Zustandsautomaten dar. Aktivitätsdiagramm sind nicht einzelnen
Klassen zugeordnet“32
TP
PT
Bei einem Aktivitätsdiagramm ist die Bezeichnung von Aktivität statt Zustand
passender. Eine Aktivität wird - aus Benutzersicht - von einem Akteur
durchgeführt. Mit Hilfe eines Aktivitätsdiagramms wird festgelegt, in welcher
Reihenfolge die Verarbeitungsschritte ausgeführt werden. Jede Aktivität ist
mit einer Verarbeitung von Seiten des Akteurs verbunden. Wenn die
Verarbeitung beendet ist, wird ein Zustand verlassen. Weiterhin ist die
Einführung
von
Entscheidungsrauten
Entscheidungskriterien
nach
notwendig,
Beendigung
einer
da
verschiedene
Zustandsverarbeitung
eintreten können.
Das
folgende
Aktivitätsdiagramm
(Abbildung
7-1)
verdeutlicht
die
Reihenfolge der Aktivitäten und die Rollen der Akteure in dem Prozess der
Erstellung eines InfoObjects und seiner Dokumentation.
TP
32
PT
[Bal2000]
Seite 79
Abbildung 7-1: Aktivitätsdiagramm
Seite 80
7.1.3.
Anwendungsfälle
Ein Anwendungsfall (use-case) wird definiert „als eine Sequenz von
zusammengehörigen Transaktionen, die von einem Akteur im Dialog mit
einem System ausgeführt werden, um für den Akteur einen messbaren Wert
zu erstellen“33
TP
Um
einen
PT
Anwendungsfall
zu
beschreiben,
entwirft
man
in
der
Softwaretechnik eine Anwendungsfallbeschreibung34 (siehe unten). Diese
TP
PT
enthält verschiedene Informationen, wie z.B. Akteur und Zweck des
Anwendungsfalls.
Weiterhin werden Szenarios aufgelistet. Da der Geschäftsprozess Prozess
der Erstellung einer InfoObjct-Dokumentation mehrere Akteure hat, werden
die Szenarios auf die verfeinerten Anwendungsfälle angewandt. Ein
Anwendungsfall hat somit mehrere Scenarios. Es gibt die primären und die
sekundären Szenarios. Ein Primäres Szenario tritt am häufigsten auf,
während die sekundären Szenarios zumeist weniger häufig vorkommende
Abweichungen des primären Szenarios sind. Einige sekundäre Szenarios
sind negative Szenarios. Kommt es zu einem negativen Szenario, so ist der
Anwendungsfall nicht positiv beendet. In diesem Fall tritt die Nachbedingung
im Negativfall ein.
Dieser Geschäftsprozess ist eingeteilt in 4 Anwendungsfälle mit jeweils
einem Akteur.
Anwendungsfallbeschreibung 1:
Prüfung, ob BW-Objekt bereits im SAP BW vorhanden ist.
Name
1.1 Prüfung BW-Objekt
Akteure:
System SAP BW
Zweck:
Prüfung, ob IOBJ schon vorhanden
Für
die
Auslösung alle Daten, die für die Bezeichnung des BW-
benötigte Daten:
33
TP
PT
TP
34
PT
Objekts nach der Namenskonvention nötig sind
[Bal99]
[SoKo]
Seite 81
Vorbedingung:
Nachbedingung
Developer möchte ein BW-Objekt anlegen
im (BW-Objekt ist nicht doppelt) Anwendungsfall 2 tritt
Positivfall:
Nachbedingung
ein
im Optionaler Abbruch des Prozesses
Negativfall:
Interaktionsschritte im
Standardfall (Idealfall):
1. Developer füllt alle Felder im DataGrid aus und
drückt den Button „OK“
2. Mit Klick auf den Button „OK“ lässt der
Developer prüfen, ob das BW-Objekt bereits
vorhanden ist
3. Developer
bestätigt
Neuanlage
des
InfoObjects
Szenarios:
1A.
Developer vergisst Muss-Feld(er)
3A.
Ähnliche
BW-Objekte
bereits im SAP BW:
dieser
BW-Objekte.
existieren
Anzeige einer Liste
Möglichkeit
des
Developers, entweder abzubrechen, oder
das BW-Objekt trotzdem anzulegen.
Anwendungsfallbeschreibung 2:
Der Developer macht alle (technischen) Eingaben, die für die Freigabe
benötigt werden und gibt das BW-Objekt frei. Nach der Freigabe kann von
ihm keine Änderung mehr durchgeführt werden.
Name:
Freigabe Developer
Akteure:
Developer
Zweck:
Der Developer macht technische Angaben zu
einem BW-Objekt
Für die Auslösung benötigte Die technische Beschreibung
Daten:
Seite 82
Vorbedingung:
Anwendungsfall 1 war erfolgreich; Developer
hat entsprechende Rechte
Nachbedingung
im Anwendungsfall 3 tritt ein
Positivfall:
Nachbedingung
im -
Negativfall:
Interaktionsschritte
im Developer füllt alle Muss-Felder aus
Standardfall (Idealfall):
Developer gibt frei, indem er E-Mail sendet
Szenarios:
Developer vergisst ein oder mehrere MussFelder
Developer speichert (und ergänzt zu einem
anderen Zeitpunkt)
Developer vergisst die Freigabe (bzw. das
senden einer E-Mail)
Anwendungsfallbeschreibung 3:
Der Customer erhält eine E-Mail mit der Aufforderung die Daten für das BWObjekt zu ergänzen, er ergänzt die Lang- und Kurzbeschreibung und die
betriebswirtschaftliche Beschreibung und gibt das BW-Objekt frei.
Name:
Freigabe Customer
Akteure:
Customer
Zweck:
Der
Customer
ergänzt
die
betriebswirtschaftlichen Daten zu dem BWObjekt
Für
die
Auslösung Kurz- und Langbeschreibung (in allen Sprachen)
benötigte Daten:
und
betriebswirtschaftliche
Beschreibung
(in
Deutsch und Englisch)
Vorbedingung:
Nachbedingung
Anwendungsfall 2 wurde erfolgreich ausgeführt
im Anwendungsfall 4 tritt ein
Seite 83
Positivfall:
Nachbedingung
im -
Negativfall:
Interaktionsschritte
im Customer füllt alle Muss-Felder aus
Standardfall (Idealfall):
Customer gibt frei, indem er E-Mail sendet
Szenarios:
Customer vergisst ein oder mehrere MussFelder
Customer speichert (und ergänzt zu einem
anderen Zeitpunkt)
Customer sendet keine E-Mail
Anwendungsfallbeschreibung 4:
Der Supervisor erhält eine E-Mail mit der Aufforderung das BW-Objekt zu
kontrollieren. Hat er keine Fehler gefunden, kann er das BW-Objekt
freigeben und dieses und die Dokumentation im SAP BW-System anlegen.
Name:
Freigabe Supervisor
Akteure:
Supervisor
Zweck:
Der Supervisor kontrolliert die von Developer
und Customer gemachten Eingaben und gibt
sie im Idealfall frei
Für die Auslösung benötigte keine
Daten:
Vorbedingung:
Nachbedingung
Positivfall:
Nachbedingung
Anwendungsfall 3 war erfolgreich
im Anlage von BW- Objekt und Dokumentation
im SAP BW (FBE)
im -
Negativfall:
Interaktionsschritte
im Supervisor gibt frei
Standardfall (Idealfall):
Seite 84
Szenarios:
1.A
Supervisor
bemängelt
Developer, Nachricht per E-Mail,
Widereinstieg bei Anwendungsfall 2
2.A
Supervisor bemängelt Customer,
Nachricht per E-Mail, Widereinstieg
bei Anwendungsfall 3
2.B
Supervisor führt keine Aktion
aus,
Erinnerungsmail
nach
X-
Tagen
Wie weit die Freigabe eines BW-Objekts vorangeschritten ist, bzw. in
welchem Stadium sie sich befindet, wird durch das Setzen der Werte in der
Tabelle T_STATUS festgelegt. Um den einzelnen Anwendern die Rollen
zuordnen zu können, besteht die Möglichkeit die Daten aus der SAP BWTabelle USR02 zu verwenden. In dieser Tabelle sind alle Anwender des SAP
BW mit ihrer Rolle (Developer, Super…) aufgelistet.
Nun sind alle Informationen für die praktische Umsetzung der Rollen und des
Prozesses gegeben.
7.2. Versionisierung, Historisierung
Werden Daten zu BW-Objekten im Laufe der Zeit geändert, weil sich der
Kontext des BW-Objekts geändert hat, so ist es sicherlich von Vorteil, die alte
Version zu speichern, falls diese später noch einmal eingesehen oder
wiederhergestellt werden soll.
Aufgrund dessen ist die Einführung einer Historie angebracht, in der die alten
Daten, der ändernde Anwender und der Zeitpunkt notiert sind.
•
Das Versionsmanagement wurde schon in der abteilungseigenen
Datenbank BUG betrieben und kann daher mit einigen Anpassungen
Seite 85
(englische
statt
deutsche
Bezeichnungen,
Änderung
der
Bezugstabellen…) übernommen werden
•
Ändert sich ein InfoObject, so sollten die neuen Daten durch ein
Update in einer der Datenbanktabellen durch die alten Daten ersetzt
werden. Die alte Dateneinheit soll in die Tabelle T_HISTORY
eingetragen werden. In T_HISTORY wird außerdem das Datum und
der Anwender geschrieben, der die Daten geändert hat.
•
Weiterhin ist zu beachten, dass die alte Dokumentationsversion in
SAP BW durch die neue ersetzt werden muss. Soll der Inhalt einer
Dokumentation
geändert
werden,
I_Overwrite_Mode
muss
des
der
Parameter
Funktionsbausteins
RSOD_DOC_META_CHANGE auf 2 (=Replace) gesetzt werden.
•
Möchte
man
dagegen
ein
InfoObject
ändern,
muss
der
Funktionsbaustein BAPI_IOBJ_CHANGE verwendet werden. Dieser
sollte aber nur mit Vorsicht genutzt werden, damit das InfoObject nicht
beschädigt wird.
7.3. Benutzereinstellungen
Um als Nutzer des Programms individuelle Anpassungen tätigen zu können,
sollte ein persönlicher Bereich im Programm existieren. So braucht der
Anwender nicht jedes Mal die Einstellungen ändern, wenn er das Programm
öffnet.
Hier sind einige Beispiele welche Auswahlmöglichkeiten im persönlichen
Bereich Vorteile bringen:
•
Sprachumstellung
Deutsch/
Englisch
in
der
Dokumentationsverwaltung
•
Sowie Sprachauswahl bei Anmeldung im SAP-System, damit
standardmäßig die InfoObject-Dokumentation in der angemeldeten
Sprache erscheint
Seite 86
•
Voreinstellungen, z.B. das gewisse Teilbäume des Treeviews immer
beim Öffnen des Programms expandiert sind
•
Einsehen einer Liste von BW-Objekten die man noch freizugeben hat
bzw. Anzeige von Listen, in denen der Status (Wer hat bereits
freigegeben?) der BW-Objekte aufgeführt ist.
7.4. Migration vorhandener Daten in die Oracle-Datenbank
Die InfoObjects beziehen ihre Daten oftmals noch aus diversen Altystemen
(engl.: Legacy System). Diese Altsysteme sind die operativen Systeme
Leasis (das Leasingsystem), Kredis (das Kreditsystem), der Banking
Customer Application (BCA) und das Statistical Analysis System (SAS),
welches 2005 abgeschaltet werden soll. Das System der VW Bank ist so
aufgebaut, dass SAS seine Daten von Leasis, Kredis und BCA erhält. Da
Leasis, Kredis, BCA und SAS ihre Daten an das BW weitergeben, existieren
die
SAS-Daten
im
Prinzip
zweimal
bzw.
werden
doppelt
in
der
Dokumentation aufgeführt.
Um auch in Zukunft einsehen zu können, aus welchen (Alt-) Systemen die
InfoObjects ihre Daten beziehen, sollen diese in den Dokumentationen zu
den InfoObjects vermerkt sein.
Bisher sind diese Daten in folgenden Tabellen und Datenbanken gespeichert
und nur vereinzelt in den BW-Dokumentationen zu finden:
Datenbanken:
OBIS- Objekte-Info-System.mdb
OBIS enthält diverse Informationen zu einem Teil der im SAP BW-System
enthaltenen InfoObjects (ODS, SAS…).
Problem: Die Datenbank ist nicht mit dem SAP-System verbunden und
enthält daher keine aktuellen Daten. Die Daten müssen manuell gepflegt
werden.
Seite 87
PP8585-00 Projektdatenbank.mdb
Diese Datenbank ist für ein bestimmtes abteilungsinternes Projekt bestimmt
und enthält ebenso diverse
Daten über InfoObjects. Der Zweck der
Datenbank ist die Anlage eines neuen InfoObjects über XML. Dabei wird ein
XML-Dokument über die Daten der einzelnen Datenbanktabellen erstellt und
in das SAP BW geladen. Die Probleme hierbei sind, dass sogenannte
GUID’s (global unit id) zuvor im SAP-System per nicht-rfc-fähigem
Funktionsbaustein generiert werden müssen und auch die Anlage des
InfoObjects muss manuell über die Administrator Workbench in das SAP BW
geladen
werden.
Zudem
ersetzte
der
Funktionsbaustein
BAPI_IOBJ_CREATE diese Methode.
Aus diesen Gründen wurde diese Art der InfoObject-Erstellung nach
Implementierungsversuchen mit VB.NET wieder verworfen.
Tabellen
Weiterhin gibt es zahlreiche Excel-Tabellen, welche die im Rahmen eines
Projects anzulegenden SAP BW-Objekts enthalten. Diese Excel-Tabellen
werden in Zukunft durch die Dokumentationsverwaltung abgelöst werden.
Das primäre Ziel ist es, alle bisher in die Tabellen eingefügten Daten auf
einen Blick im gleichen System und nicht wie bisher in diversen Tabellen und
Datenbanken zu halten. Also müssen die Daten aus den Datenbanken in die
Oracle-Datenbank dwown transferiert werden. Im WWW gibt es eine große
Anzahl von Tools für die Transferierung von Excel und Access-Daten nach
Oracle.
7.5. Erweiterung um zusätzliche BW-Objekte
Für die Erweiterung der Dokumentationsverwaltung um ODS-Objects ist die
Tabelle T_ODS eingefügt worden. Da ein ODS-Object n InfoObjects besitzt
und ein InfoObject wiederum Teil von n ODS-Objects sein kann, ist die
Seite 88
Beziehung eine n:n-Beziehung. Als Zwischentabelle ist T_LANGUAGE
optimal, denn auch das ODS-Object besitzt die Texte Description long und
Description short. Die SAP-interne Tabelle der ODS-Objects ist RSDODSO
bzw. RSDODSOT für die Texte. Auch der SAP Funktionsbausteins für die
Anlage
des
ODS-Objects
existiert
im
SAP
BW.
Er
heißt
BAPI_ODSO_CREATE.
Die Namen der Tabellen und Funktionsbausteine der anderen BW-Objekte
heißen
analog zu diesen Bezeichnungen RSD[BW-Object-Shortcut] und
BAPI_[BW-Object-Shortcut]_CREATE.
7.6. Einführung einer weiteren Sprache
Da die Oracle Stored-Procedures und Functions dynamisch programmiert
wurden, muss bei der Einführung einer neuen Sprache bei BW-ObjektTexten nur die Tabelle T_LINGUA geändert werden. Wird z.B. die Sprache
Spanisch eingefügt, werden in Zukunft vier Datensätze in der Tabelle
T_LANGUAGE angelegt und letztendlich auch vier HTML-Dokumentationen
erzeugt.
7.7. Seitenaufbau/ Treeview
7.7.1.
Einführung und Installation
Um die Dokumentationsverwaltung zu einer Einheit zusammenzuführen, wird
eine Möglichkeit zur Navigation zwischen den einzelnen Seiten benötigt. Der
Anwender muss, je nachdem welcher Rolle er angehört, die Option haben
sich entweder die diversen BW-Objekten anzuschauen, sie zu erstellen oder
seine Benutzereinstellungen einzusehen und ändern zu können.
Die Navigation zu den unterschiedlichen Seiten soll mit einem Treeview
(Abbildung 7-2) umgesetzt werden. Ein Treeview besitzt, wie der Name
Seite 89
schon sagt, eine baumähnliche Struktur, so dass die verschiedenen Seiten in
Gruppen angeordnet werden können.
Die Navigationsmöglichkeiten eines Anwenders hängen davon ab, ob er
Developer,
Customer,
Supervisor
oder
normaler
Anwender
ohne
Sonderstatus ist. Je nach Status sieht der Anwender nach dem Login einige
Menüpunkte. Der Anwender hat z.B. ausschließlich die Seiten zur Auswahl,
auf denen er sich BW-Objekts nur anzeigen lassen kann, wogegen der
Supervisor sich den Status des neuen BW-Objekts anzeigen lassen kann
und die Möglichkeit zur Freigabe hat. Der Developer wird dagegen die
Auswahl der Seite haben, auf der er ein BW-Objekt neu erstellen kann.
Weiterhin gibt es auch Seiten wie die Benutzereinstellung, die jeder
Anwender als Element im Treeview zur Auswahl hat.
Abbildung 7-2: Treeview
Für die komfortable Navigation ist das Treeview-Steuerelement aufgrund der
Ähnlichkeit mit der übersichtlichen baumähnlichen Verzeichnisstruktur des
Windows Explorers das am besten geeignete. Dieses ist nicht im .NET
Framework
enthalten,
kann
aber
auf
der
Microsoft-Homepage35
TP
heruntergeladen werden.
Das Treeview ist neben der Toolbar, dem Tabstrip und der Multipage ein
Webserversteuerelement, welche die Funktionen des Internet Explorer
nutzen und deswegen auch IE-Websteuerelement genannt werden. Um es
TP
35
PT
[DowTrv]
Seite 90
PT
zu nutzen werden die IE-Websteuerelemente installiert und die DLL
Treeview.dll in das Visual Studio eingebunden. Jetzt kann das Treeview auf
verschiedene Weise verwendet werden. Zum einen kann es statisch
angewendet werden und zum anderen ist die dynamische Anbindung an eine
Datenbank möglich. In diesem Fall wurde die dynamische Möglichkeit
realisiert, da ein statisches Treeview aufgrund der unterschiedlichen Rollen
und der schlechten Wartbarkeit nicht ausreichend ist36
TP
7.7.2.
PT
Erklärung der Datenbank-Tabellen
In der Tabelle T_NODE
ist gespeichert, welcher Knoten welche Rolle
besitzt. So haben alle Anwender mit der Rolle User die Knoten zum Ansehen
und zur Suche von Dokumentationen, während alle Anwender mit der Rolle
Developer
Dokumentationen
z.B.
auch
anlegen
können.
Um
eine
Baumstruktur mit Eltern- und Kindknoten zu erhalten, enthält die Spalte
No_Parentnode Verweise auf die eigene Tabelle, welche besagen, ob und
welchen Elternknoten ein Knoten hat. Dies ist wichtig für die Realisierung der
einzelnen Ebenen, die durch Aufklappen des Treeviews entstehen. Weiterhin
steht in den Spalten No_NameG und No_NameE der
deutsche bzw.
englische Anzeigename.
Per Verweis auf die Tabelle T_PAGE wird für jeden einzelnen Knoten
bestimmt, auf welche Seite der Link des Knotens verweist. Bei T_PAGE und
T_NODE handelt es sich um eine 1:N-Beziehung, da ein Seitenverweis in
T_PAGE für jede Rolle einen Knoten mit anderen Elternknoten und Namen
hat.
TP
36
[MsIEWeb]
PT
Seite 91
Abbildung 7-3: Inhalt von T_Node und T_Page
Die VB-Klasse Treeview
Bei Aufruf der Seite werden entsprechend der Rolle des jeweiligen Nutzers
die Informationen der benötigten Knoten aus den Tabellen T_NODE und
T_PAGE der Datenbank abgefragt und an das Treeview angehängt.
Diese geschieht mit der rekursiven Funktion Fkt_Treeview
in der alle
Wurzelknoten nacheinander durchlaufen (traversiert) und als Root in das
Treeview eingefügt werden. Für jeden Wurzelknoten wird durch einen Aufruf
der eigenen Funktion untersucht, ob ein oder mehrere Kindsknoten
existieren. Auch bei den Kindknoten wird untersucht, ob diese wiederum
Kindknoten haben. Dieses ist bei einem Treeview mit 3 oder mehr Ebenen
der Fall37.
TP
PT
IFrame
Das Treeview wird durch ein so genanntes IFrame (Inline Frame) in jede
Seite eingebettet. IFrames gehören zum HTML 4-Standard und haben eine
ähnliche Funktionalität wie normale Frames.
Der Unterschied ist jedoch, dass eingebettete Frames keine Aufteilung des
Bildschirms erzeugen, sondern ähnlich wie Grafiken Bereiche innerhalb einer
Hauptseite sind. Dieses hat einen großen Vorteil. Da ein IFrame der
Hauptseite untergeordnet ist, kann der Anwender jede Seite mit einem
Lesezeichen versehen,
TP
37
PT
Der VB-Code wurde von dem Auszubildenden Holger Roedig implementiert
Seite 92
denn in der Adressleiste wird die vollständige URL mit der Iobj_pk_id
angezeigt.
http://localhost/PROJECT/mainIOBJ.aspx?iobj_pk_id=977
Abbildung 7-4: vollständige URL mit IFrames
Bei normalen Frames würde dieses nicht funktionieren, da immer nur die
Einstiegsseite als Lesezeichen gesetzt werden würde. Muss der Anwender
seine Eingaben z.B. zu einem InfoObject unterbrechen, kann er die Seite als
Lesezeichen setzen und beim nächsten Mal schnell wieder aufrufen.
Die Nachteile sind, dass sie nur in Browsern mit integriertem HTML 4
funktionieren, was ein Problem darstellen kann, wenn der Anwenderkreis
unterschiedliche Browserversionen hätte. Etwas umständlich ist außerdem,
dass der unten aufgeführte IFrame-Code in jede Seite, die diesen IFrame
haben soll, eingebettet werden muss.
Das der Anwender jedoch die Möglichkeit haben soll, die Seiten, an denen er
arbeitet, mit Lesezeichen zu versehen, ist dieses Feature ausschlaggebend.
<IFRAME style="Z-INDEX: 101; LEFT: 0px; WIDTH: 120px; POSITION: absolute; TOP: 72px;
HEIGHT: 280px" name="iframe" align="right" src="Treeview.aspx" width="40"
height="80"></IFRAME>
Abbildung 7-5: IFrame in der Dokumenationsverwaltung
7.8. Anzeige einer Online-Dokumentation
Die Online-Dokumentation ist nicht zu verwechseln mit der gewöhnlichen
Dokumentation
(s.
Kapitel
3).
Per
Pfadangabe
kann
die
Online-
Dokumentation zu einem gewünschten BW-Objekt eingesehen werden. Im
unten aufgeführten Beispiel wurde zu Testzwecken ein Hyperlink verwendet.
Der Pfad muss insofern angepasst werden, als dass der BW-Objekttyp und
der BW-Objektname eingesetzt werden muss. Um den Zugriff auf die OnlineDokumentation zu erhalten, muss der Anwender zuvor seinen Namen und
sein Passwort für den WebApplication-Server eingeben.
Seite 93
<asp:HyperLink id="lnkBeispiel" style="Z-INDEX: 102; LEFT: 19px; POSITION: absolute; TOP:
59px" runat="server" NavigateUrl=
"http://sap-fbp.vwfsag.de:8010/sap/bw/doc/metadata/page%3dBW_O_D%26SystemID%3d
FBP112%26ClassID%3dIOBJ%26ID%3d0country%26objectVersion%3dA"
Target="main">0country</asp:HyperLink>
H
H
Beispiel 7-1: Zugriff auf Online-Dokumentation des InfoObjects 0Country
Mit der Integration der Dokumentationsverwaltung in das SAP Enterprise
Portal wäre diese Art der Einbindung nicht mehr nötig.
7.9. TREX/ SAP Enterprise Portal
SAP arbeitet darauf hin, dass der Nutzer für alle SAP-Systeme nur noch eine
Oberfläche bzw. Plattform, nämlich das Portal haben wird. Dieses bringt
Vorteile, wie z.B. das einmalige Login (single-sign-on) und nur ein
Basisprogramm.
•
Integration in das Portal: Die Integration von .NET- Anwendungen
T
T
mit SAP-Lösungen wird von Microsoft und SAP vorangetrieben
(Kapitel 2.2). Somit kann die Dokumentationsverwaltung auf lange
Sicht in die Portalumgebung integriert werden, so dass in Zukunft die
Dokumentationsverwaltung
mit
SAP-eigenen
Anwendungen
verschmilzt.
„SAP entwickelt zudem ein Portal Developer Kit für IBM Websphere
sowie eines für Microsoft .NET. Dadurch können Entwickler FrontEnd-Dienste in .NET-Umgebungen erstellen und dies in SAP
Enterprise Portale einbetten. […] Entwickler können in [...] Microsoft
.NET-Umgebungen auf Services von SAP Enterprise Portal zugreifen,
beispielsweise auf die Benutzerverwaltung, Rollen, Seiten und
personalisierte Daten […]“38.
TP
TP
38
PT
PT
[SAPWeav]
Seite 94
•
Integration von TREX: Da die Dokumentationsverwaltung ein mit
T
T
MS.NET geschriebenes Programm ist und sich deshalb in das SAP
Enterprise Portal integrieren lässt, wird die Kommunikation mit der
Suchmaschine
TREX
ebenfalls
problemlos
möglich
sein.
Die
Suchmaschine wird auch zu einem Teil des SAP Enterprise Portals
werden und aufgrund der Tatsache, dass SAP (bei der VWFSAG)
über Oracle-Datenbanken als Back-End verfügt, kann TREX in
Zukunft die Daten der Oracle-Datenbank auslesen und diverse
Suchfunktionen über diese ausführen.
Seite 95
8. Schlusswort
8.1. Fazit
Zum Ende erläutere ich Vorgehensweisen, Probleme und Chancen der Entstehung dieser Diplomarbeit.
Der Umfang der Diplomarbeit war sehr komplex, da es zum einen galt, sich
im SAP BW-System mit seinen zahlreichen Transaktionen zurechtzufinden;
zum anderen war es notwendig, die Architektur und den Datenfluss innerhalb
des Business Warehouse verstehen zu lernen. Ein anderer wichtiger Faktor
war, herauszufinden, was die zukünftigen Anwender am meisten am IST-Zustand störte und welche Vorstellungen und Wünsche sie bezüglich der
Dokumentationen hatten. Bei diesen Nachforschungen traten recht unterschiedliche Meinungen auf, welche Neuerungen notwendig oder sinnvoll
seien.
Diese unterschiedlichen Ansichten waren auf einen gemeinsamen
Nenner zu bringen, damit das Gesamtkonzept erstellt werden konnte.
Für die Dokumentationsverwaltung musste zur Umsetzung des Sollkonzeptes eine Möglichkeit gefunden werden, Daten vor Änderungen im BW in einer
Datenbank zu speichern, auf die mit einer geeigneten Umgebung und Programmiersprache für Webanwendungen zugegriffen werden kann. Von der
gewählten Plattform Microsoft .NET konnte zudem die Kommunikationsmöglichkeit des SAP .NET-Connectors genutzt werden, um mit dem SAP BWSystem zu interagieren.
Nachdem diverse Möglichkeiten recherchiert - und die besten Technologien
für das SAP-System und die Systemlandschaft der VWFSAG gefunden
waren, begann die zeitaufwendige Beschaffung und Installation der verschiedenen benötigten Softwareprodukte und die Einarbeitungsphase in
diese verschiedenen Technologien. Dabei wurden die Möglichkeiten von
XML untersucht, die Sprache Visual Basic.net erlernt und eine Oracle-Datenbank eingerichtet. Dabei wurde die Entscheidung getroffen, dass die
Daten zunächst relational und erst später als XML-Dokumente gespeichert
werden.
Seite 96
Da das Thema der Dokumentationsverwaltung sehr umfangreich war, wurde
nach Rücksprache mit den Auftraggebern festgelegt, welcher Teil in einer
ersten Stufe realisiert und welcher für spätere Stufen theoretisch vorbereitet
wird. Einen Kompromiss zwischen einer rein theoretischen und einer rein
praktischen Arbeit zu finden, war mir sehr wichtig, da meines Erachtens die
Gefahr bestand, dass eine ausschließlich theoretisch existierende Dokumentationsverwaltung in der Praxis unter Umständen nicht realisierbar
gewesen wäre. Insofern war es wichtig für mich, den SAP .NET-Connector
und die übrigen Technologien als miteinander kommunizierende Einheiten zu
einem einheitlichen Programm zusammenzuführen um die praktischen Erfahrungen auf die Konzeption zu reflektieren. Da ein InfoObject als wichtigstes
SAP BW-Objekt gilt, war entschieden worden, dass die Archivierung von
Daten und die Erstellung des InfoObject und seiner Dokumentation
implementiert werden soll.
Die Vielfalt und zahlreichen Einsatzmöglichkeiten der eingesetzten aktuellen
Technologien sind für einen Entwickler sehr interessant und verdeutlichen
die Perspektiven, die sich für die Softwareentwicklung in der Zukunft auftun.
Der implementierte Teil der Dokumentationsverwaltung kann somit sowohl
als Arbeitserleichterung mit dem SAP BW-System als auch als Anreiz für die
Entwicklung innovativer interoperabilitäre Webanwendungen gesehen werden.
Seite 97
8.2. Danksagung
Ich danke allen Mitarbeitern der Volkswagen Bank und besonders den Mitarbeitern und Externen der Abteilung I-SEB und Herrn Prof. R. Rüdiger, die
mich mit fachlichem Rat bei der Erstellung der Diplomarbeit unterstützt
haben.
Besonders danke ich meinem Betreuer Uwe Arnold für seine Hilfe und dass
er mir die Motivation für die Fertigstellung dieser Arbeit gab.
Weiterhin bedanke ich mich herzlich bei Martin Trautwein, Kristina Birke und
meinen Eltern für die freundschaftliche Unterstützung.
8.3. Selbständigkeitserklärung
Hiermit versichere ich, dass ich diese Arbeit selbständig angefertigt habe und
keine anderen als die angegebenen Quellen und Hilfsmittel verwendet wurden.
Braunschweig, den
Sylvia Brink
Seite 98
I.
Anhang
A Bedarfsanalyse
Bedarfsanalyse
Dokumentenverwaltung in SAP BW
Entwickler
U
In SAP BW sollen zukünftig Dokumentationen für die BW-Objekte standardisiert verwaltet werden.
Im Moment gibt es zu einem Teil der BW-Objekte Dokumentationen ohne einheitliche Struktur.
Dokumentationen bestehen schon für manche InfoObjekte.
Hier ein Beispiel: Dokumentation
U
U
Zur Erstellung der Software ist es wichtig zu wissen, was die Anwender/Entwickler für
Anforderungen an diese Software stellen.
Bitte füllen sie diesen Fragebogen sorgfältig aus. Vielen Dank!
1. Angaben zur Person
Wie gut schätzen sie ihr Wissen bezüglich SAP BW ein?
•
Experte
•
Grundlagen, auf Teilgebieten Experte (z.B. ABAP, Bex Analyzer etc.)
Welche:
•
•
•
Grundlagen
kaum Wissen
kein Wissen bzw. sehr geringes Wissen
Bemerkungen:
Je nachdem, welche Aufgaben ein Mitarbeiter hat, arbeitet er unterschiedlich oft und intensiv mit BWObjekten.
Welche Erfahrungen haben sie zur Zeit mit Dokumentationen in SAP BW?
•
habe schon welche erstellt
•
ich lese sie hin und wieder
•
habe ich mal gesehen
•
keine
Bemerkungen:
Wie oft werden Sie voraussichtlich auf Dokumentationen von BW-Objekten zurückgreifen?
•
ständig
•
oft
•
hin und wieder
•
sehr selten
•
gar nicht, ich arbeite nie mit dem BW
Wenn sie „gar nicht“ angekreuzt haben, brauchen sie diesen Bogen nicht weiter auszufüllen.
Bemerkungen:
Seite 99
Werden Sie von Anwendern zu BW-Objekten um Rat gefragt (z.B. per Telefon), weil diesen
bestimmte technische Kenntnisse fehlen?
(z.B. Datenfluss, aktuellen Problemen/Änderungen)
•
jeden Tag mehrmals
Um was geht es z.B.?
•
fast jeden Tag
Um was geht es z.B.?
•
kommt selten vor
•
nie
Bemerkungen:
Arbeiten sie auch von zu Hause aus mit SAP BW?
•
oft
•
hin und wieder
•
nie
Bemerkungen:
2. Berechtigungen/ Zuständigkeiten
Zuständigkeiten
Zur Zeit gibt es noch keine Zuständigkeiten für die einzelnen BW-Objekte.
Diese Zuständigkeiten sollen demnächst festgelegt werden.
Somit ist immer eindeutig, welcher Mitarbeiter für welches BW-Objekt verantwortlich ist.
•
•
Zuständigkeiten sollen nicht eingeführt werden
Zuständigkeiten sind notwendig
Begründung:
Bemerkungen:
Berechtigungen
Ist - auf Basis dieser Zuständigkeiten – ein Berechtigungskonzept wünschenswert?
Nur berechtigte Mitarbeiter können dann ein Dokument aktivieren/ändern.
+ Dokumente können nicht (aus Versehen) geändert/ gelöscht werden
- Aufwand ist größer, da Berechtigungen angelegt/ gepflegt werden müssen
•
sinnvoll
•
weniger sinnvoll
Begründung:
Bemerkungen:
3. Prozess der Dokumentenverwaltung
Erstellung einer Dokumentation
An der Erstellung einer neuen Dokumentation arbeitet immer mehr als ein Mitarbeiter, damit die
Qualität sich verbessert.
Folgender Vorschlag:
Ausgangspunkt: Ein neues InfoObjekt wurde erstellt.
1.der Anwender erstellt die Dokumentation und fügt betriebswirtschaftliche Inhalte ein
2.der Entwickler ergänzt sie um die technischen Inhalte
Seite 100
3.Der Zuständige prüft die Dokumentation und gibt sie frei.
•
Vorgehensweise sinnvoll
•
anderer Vorschlag:
Bemerkungen:
4. Aufbau und Inhalt
Es geht um den Datenfluss bezüglich eines InfoObjekts
Es ist für Sie wichtig zu wissen:
...in welchen Queries das InfoObjekt verwendet wird
Wichtig
weniger wichtig
nicht wichtig
Anmerkung:
...aus welchen Fortschreibungsregeln das InfoObjekt Daten erhält
Wichtig
weniger wichtig
nicht wichtig
Anmerkung:
...in welchen InfoCubes das InfoObjekt verwendet wird
Wichtig
weniger wichtig
nicht wichtig
Anmerkung:
...Weiteres:
Dateiformate
Die Dokumentationen sollen auf Word, Excel und/ oder HTML basieren.
Soll es weitere Dateiformate geben?
z.B. Visio-Dokumente zur Erstellung von Grafiken, PowerPoint zur Präsentation
•
Ja
•
nicht notwendig
Welche?: Begründung:
Bemerkungen:
Vollautomatische Informationen
In die Dokumentationen können vom System generierte Informationen vollautomatisch eingefügt
werden:
• z.B. Ladeläufe (stattgefunden, nicht stattgefunden)
• Fehlermeldungen
•
•
sinnvoll
nicht sinnvoll
Begründung:
Seite 101
Bemerkungen:
Eigene Anmerkungen
Aktuelle eigene Anmerkungen können am Ende der Dokumentation angehängt werden (z.B. bei
Änderungen/ Fehlern)
sinnvoll
nicht sinnvoll
Begründung:
sinnvoll, sollten aber nach gewisser Zeit gelöscht werden
Bemerkungen:
5. Automatische E-Mailbenachrichtigung
Sie können automatisch per E-Mail benachrichtigt werden, wenn sie dafür bei der entsprechenden
Dokumentation eingetragen sind.
Die E-Mailbenachrichtigungen sollen möglichst gezielt stattfinden.
+ sie bekommen automatisch mit, wenn sich bezüglich der BW-Objekte etwas ändert
- die E-Mailflut wird noch grösser
Benachrichtigungen finde ich interessant, bei
•
Änderungen bezüglich betriebswirtschaftlichen Inhalten
•
Änderungen bezüglich BW-technischen Inhalten
•
stattgefundenen Ladeläufen
•
manuell erstellten Anmerkungen
•
Dokumentationen, die ich überprüfen soll
Bemerkungen:
Anzahl Mails
In welchem Rahmen darf sich die E-Mailbenachrichtigung bewegen?
Pro Woche:
•
•
•
bis zu 20 E-Mails
bis zu 5 E-Mails
möchte keine E-Mailbenachrichtigungen
Bemerkungen:
6. Struktur der Dokumentation
Reihenfolge der Inhalte
Bei der Reihenfolge ist zu beachten, dass wichtige Informationen zuerst angeführt werden.
Auch ist wichtig, dass die Informationen für die Anwender recht weit oben aufgeführt sind.
Vorschlag für die Reihenfolge der Inhalte:
1. kurze technische Informationen
(Name des InfoObjektes, techn. Name, Datentyp,Beschreibung
etc.)
2. betriebswirtschaftlicher Hintergrund
3. weitere technische Informationen (Zusammenhänge mit anderen BW-Objekten)
4. aktuelle Informationen:
4a. vollautomatische Informationen (z.B. Ladelauf)
4b. eigene Anmerkungen
Seite 102
•
sinnvoll
•
andere Reihenfolge:
Begründung:
Bemerkungen:
7. Suche
Die Suche nach Dokumentationen kann erfolgen durch Suche nach:
-dem technischen Namen
-der Beschreibung
-der BW-Objektklasse
Schlagwortsuche
Des weiteren gibt es die Überlegung, dass der Ersteller einer Dokumentation Schlagworte definiert,
nach denen man suchen kann.
+ die Suche ist schneller, da man nicht den gesamten Inhalt aller Dokumente durchsuchen muss
+ man kann nach mehreren Kriterien durchsuchen
-man muss die Schlagworte definieren
•
•
•
sinnvoll
weniger sinnvoll
nicht sinnvoll
Begründung:
Begründung:
Bemerkungen:
8. Weitere BW-Objekte
Für welche BW-Objekte (ausser InfoObjekten) wünschen sie noch Dokumentationen?
(Die Dokumentationen sollen zuerst nur für InfoObjekte standardisiert werden).
•
•
•
•
•
•
•
•
•
InfoCubes
ODS-Objekte
InfoSets
MultiProvider
InfoSource
Fortschreibungsregeln
Übertragungsregeln
Prozesskette
Rolle
InfoSet
Bemerkungen:
9. Druckfunktionen
Das Drucken von Dokumentationen ist für Sie:
•
•
•
unbedingt notwendig
bedingt notwendig
gar nicht notwendig
Begründung:
Bemerkungen:
10. Zusätzliche Anmerkungen/ Vorschläge:
Seite 103
B IOBJListFromBW.vb
Imports SAP.Connector
Imports rfc_read_table
Public Class IOBJListFromBW
Inherits System.Web.UI.Page
Protected WithEvents Label1 As System.Web.UI.WebControls.Label
Protected WithEvents DropDownList2 As System.Web.UI.WebControls.DropDownList
Protected WithEvents DataGrid1 As System.Web.UI.WebControls.DataGrid
Protected WithEvents Label2 As System.Web.UI.WebControls.Label
Dim dssapB512 As New System.Data.DataSet
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs)
Handles MyBase.Load
If Not Page.IsPostBack Then
LoadList(DropDownList2.SelectedValue.ToString())
End If
End Sub
Sub LoadList(ByVal strLanguage As String)
Dim oProxy As New rfc_read_table.rfc_read_table
Dim sapTableFields As New rfc_read_table.RFC_DB_FLDTable
Dim sapTableOptions As New RFC_DB_OPTTable
Dim sapTableOptions2 As New RFC_DB_OPTTable
Dim sapTableFieldsRow1 As New RFC_DB_FLD
Dim sapTableFieldsRow2 As New RFC_DB_FLD
Dim sapTableOptionsRow As New RFC_DB_OPT
Dim sapTableOptionsRow2 As New RFC_DB_OPT
Dim rsdiobj As New TAB512Table
Dim Rowcount As Integer = rsdiobj.Count
'FIELDS-Parameter: needed fields from the table
'IOBJNM (Name of the IOBJ) and TXTSH (Short Description)
sapTableFieldsRow1.Fieldname = "IOBJNM"
sapTableFieldsRow2.Fieldname = "TXTSH"
sapTableFields.Add(sapTableFieldsRow2)
sapTableFields.Add(sapTableFieldsRow1)
'OPTIONS-Parameter: where-clause from Query
sapTableOptionsRow.Text = "LANGU EQ '" + strLanguage + "' "
sapTableOptions.Add(sapTableOptionsRow)
sapTableOptionsRow2.Text += "and OBJVERS EQ 'A'"
sapTableOptions.Add(sapTableOptionsRow2)
'Destination-Class with test-user
Dim Dest As New SAP.Connector.Destination
Dest.Client = "112"
Seite 104
Dest.AppServerHost = "reg02l01b"
Dest.SystemNumber = "12"
Dest.Username = "test02"
Dest.Password = "start123"
Dest.Language = "DE"
oProxy.Connection = New SAP.Connector.SAPConnection(Dest.ConnectionString)
Dim delimiter As Char() = "|"
Dim no_data As String = ""
Dim Query_Table As String = "RSDIOBJT"
Dim Rowskips As String = "0"
oProxy.Connection.Open()
oProxy.Rfc_Read_Table(delimiter, no_data, Query_Table, Rowcount, Rowskips,
rsdiobj, sapTableFields, sapTableOptions)
oProxy.Connection.Close()
'Call Function "MakeNamesTable"
Dim dtsapB512 As DataTable = MakeNamesTable()
'The returned Columns IOBJNM and TXTSH have to be splitted to become two
separated columns
'They look like this: 0country | 0country-description
Dim split As String() = Nothing
Dim strTemp As String
Dim myRow As DataRow
Dim myRow2 As DataRow
Dim i As Integer
'Listengröße: Problem!
For i = 0 To 2000 - 1
strTemp = rsdiobj.Item(i).Wa.ToString()
split = strTemp.Split(delimiter)
myRow = dtsapB512.NewRow()
myRow2 = dtsapB512.NewRow()
strTemp = split(0)
myRow("Name") = split(1)
myRow("Short Description") = split(0)
dtsapB512.Rows.Add(myRow)
Next i
dssapB512.Tables.Add(dtsapB512)
DataGrid1.DataSource = dtsapB512.DefaultView
DataGrid1.DataBind()
End Sub
'Adds Columns 'Name' (of the IOBJ) and 'Short description' to the DataTable "Names"
Private Function MakeNamesTable() As DataTable
Dim namesTable As DataTable = New DataTable("Names")
Dim idColumn As DataColumn = New DataColumn
idColumn.DataType = System.Type.GetType("System.Int32")
Seite 105
idColumn.ColumnName = "No."
idColumn.AutoIncrement = True
namesTable.Columns.Add(idColumn)
Dim IOBJNMColumn As DataColumn = New DataColumn
IOBJNMColumn.DataType = System.Type.GetType("System.String")
IOBJNMColumn.ColumnName = "Name"
IOBJNMColumn.DefaultValue = "IOBJNM"
namesTable.Columns.Add(IOBJNMColumn)
Dim TXTSHColumn As DataColumn = New DataColumn
TXTSHColumn.DataType = System.Type.GetType("System.String")
TXTSHColumn.ColumnName = "Short Description"
namesTable.Columns.Add(TXTSHColumn)
' Creates an array for DataColumn objects.
Dim keys(0) As DataColumn
keys(0) = idColumn
namesTable.PrimaryKey = keys
' Return the new DataTable.
MakeNamesTable = namesTable
End Function
Private Sub DropDownList2_SelectedIndexChanged(ByVal sender As System.Object,
ByVal e As System.EventArgs) Handles DropDownList2.SelectedIndexChanged
Dim strTemp As String = DropDownList2.SelectedValue
LoadList(strTemp)
End Sub
End Class
Seite 106
C Oracle-Datenbank dwown
Seite 107
D Front-End
Seite 108
Eingabemasken
Daten für die Dokumentation
(1) Descriptions (Beschreibungen)
(2) Sourcesystems (Quellsysteme)
(3) Characteristics (Ausprägungen)
Metadaten
Keyfigures (Kennzahlen)
Characteristics (Merkmale)
Seite 109
InfoObject-Dokumentation (ShowDocumentation)
Seite 110
E Procedure P_Create_XMLDocs
PROCEDURE P_CREATE_XMLDOCS(iobj_pk_id Number)
as
-- Handle for the Main-Table
qryCtx DBMS_XMLGEN.ctxHandle;
-- Handle for the descriptions
qryCtx2 DBMS_XMLGEN.ctxHandle;
-- gets ALL actual LANGUAGES (E,F,D...) FROM T_LANGUAGE
(la_language)
CURSOR cursorLanguage IS SELECT la_language FROM T_LANGUAGE
WHERE la_fk_iobj= iobj_pk_id;
XMLTable xmltype;
-- this procedure joins all columns needed for the documentation
-- and inserts them into t_language(column la_xmldoc)
-- uses DBMS_XMLGEN-Packet to generate XML from relational Tables
-- Definition DBMS_XMLGEN
-- "DBMS_XMLGEN converts the results of a SQL query to a canonical
XML format.
-- The package takes an arbitrary SQL query as input, converts it to
XML format,
-- and returns the result as a CLOB."
-- for further Details look at:
-**http://nss.felk.cvut.cz/doc/ora901/DOC/appdev.901/a89852/d_xmlgen.
htm#ARPLS066**
BEGIN
-- ******************* Table T_IOBJ *********************
-- ***** for all languages ******
-- Function newContext
-- This function, given a query string, generates a new context
handle to be
-- used in subsequent functions.
-- SYNTAX: DBMS_XMLGEN.newContext (queryString IN VARCHAR2)RETURN
ctxHandle;
qryCtx := dbms_xmlgen.newContext
('select iobj_id, gistype As language, conversionmode As
Sourcesystem,
selection As Characteristic, iobj_format As Format from t_iobj
where iobj_pk_id='|| iobj_pk_id);
-- Procedure SETROWTAG:
Sets the name of the element enclosing
each row of
-- the result. The default tag is ROW.
DBMS_XMLGEN.setRowTag(qryCtx, 'IOBJDoc');
-- Procedure SETROWSETTAG:
Sets the name of the element
Seite 111
enclosing the
-- entire result. The default tag is ROWSET.
DBMS_XMLGEN.setRowSetTag (qryCtx, 'SAPBW');
--Function GETXMLTYPE: generates the XML document and returns
it as XMLTYPE
XMLTable := DBMS_XMLGEN.getXMLType(qryCtx);
--CURSOR: Insert XMLDocument for all Languages into T_LANGUAGE,
la_xmldoc
FOR c1 IN cursorLanguage
LOOP
UPDATE T_LANGUAGE SET la_xmldoc= XMLTable WHERE la_fk_iobj =
iobj_pk_id
AND la_language = c1.la_language;
END LOOP;
--**************************************************************
--********************** Table T_LANGUAGE **********************
FOR c1 IN cursorLanguage
LOOP
qryCtx2 := dbms_xmlgen.newContext
('SELECT la_desc_long, la_desc_short, la_desc_tec,
la_desc_econ FROM
T_LANGUAGE where la_language = '''|| c1.la_language ||'''
and la_fk_iobj = '|| iobj_pk_id);
DBMS_XMLGEN.setRowTag(qryCtx2, 'description');
DBMS_XMLGEN.setRowSetTag (qryCtx2, '');
XMLTable := DBMS_XMLGEN.getXMLType(qryCtx2);
-- XML-Tag DESCRIPTIONLONG will be replaced by "XMLTable"
-- Insertion into the XML-Document by UpdateXML(XMLType-Row,
XPath)
UPDATE T_LANGUAGE t
SET
la_xmldoc=updateXML(la_xmldoc,
'/SAPBW/IOBJDoc/LANGUAGE[1]' , XMLTable) WHERE
existsNode(la_xmldoc,'/SAPBW') = 1 AND la_fk_iobj=
iobj_pk_id AND la_language = c1.la_language ;
END LOOP;
--******************************************************************
--********************** Table T_SOURCESYSTEM **********************
qryCtx2 := dbms_xmlgen.newContext
('SELECT so_pk_id, so_sourcesystem, so_interfacefile,
so_fieldname_os,so_fieldlabel_os, so_sas_library, so_table,
so_field,so_datatype,so_length, so_format, so_transformation,
so_annotation FROM t_sourcesystem
WHERE so_fk_iobj='|| iobj_pk_id);
Seite 112
DBMS_XMLGEN.setRowTag(qryCtx2, 'sourcesystem');
DBMS_XMLGEN.setRowSetTag (qryCtx2, 'sourcesystems');
XMLTable := DBMS_XMLGEN.getXMLType(qryCtx2);
--FOR ALL LANGUAGES: ISREFERENCE will be replaced by actual
"XMLTable"-Content
UPDATE T_LANGUAGE t
SET la_xmldoc =
updateXML(la_xmldoc,'/SAPBW/IOBJDoc/SOURCESYSTEM[1]', XMLTable)
WHERE existsNode(la_xmldoc,'/SAPBW') = 1 AND la_fk_iobj= iobj_pk_id;
-*******************************************************************
--********************** Table T_CHARACTERISTIC
**********************
--*****all Languages******
qryCtx2 := dbms_xmlgen.newContext
('SELECT ch_characteristic, ch_definition, ch_annotation from
T_CHARACTERISTIC
WHERE ch_fk_iobj='|| iobj_pk_id);
DBMS_XMLGEN.setRowTag(qryCtx2, 'characteristic');
DBMS_XMLGEN.setRowSetTag (qryCtx2, 'characteristics');
XMLTable := DBMS_XMLGEN.getXMLType(qryCtx2);
--For ALL LANGUAGES: SELECTION will be replaced by actual
"XMLTable"-Content
UPDATE T_LANGUAGE t
SET la_xmldoc =
updateXML(la_xmldoc,'/SAPBW/IOBJDoc/CHARACTERISTIC[1]', XMLTable)
WHERE existsNode(la_xmldoc,'/SAPBW') = 1 AND la_fk_iobj= iobj_pk_id;
-********************************************************************
**
-*******************************************************************
DBMS_XMLGEN.closeContext(qryCtx);
END;
Seite 113
F XML-Dokumentation (Beispiel)
<SAPBW>
<IOBJDoc>
<IOBJ_ID>YZINS</IOBJ_ID>
<description>
<LA_DESC_LONG>interest categorization</LA_DESC_LONG>
<LA_DESC_SHORT>interest category</LA_DESC_SHORT>
<LA_DESC_TEC>There will be no master data built. If the
contracts are read in, the expansion-factors will be read from this
table.</LA_DESC_TEC>
<LA_DESC_ECON>Interest categorisation for multi-level
customer-financing.</LA_DESC_ECON>
</description>
<sourcesystems>
<sourcesystem>
<SO_PK_ID>1152</SO_PK_ID>
<SO_SOURCESYSTEM>Kredis</SO_SOURCESYSTEM>
<SO_INTERFACEFILE>DLP.DVV.DW0007B.W01#</SO_INTERFACEFILE>
<SO_FIELDNAME_OS>ZISTUFE</SO_FIELDNAME_OS>
<SO_FIELDLABEL_OS>-</SO_FIELDLABEL_OS>
<SO_SAS_LIBRARY>-</SO_SAS_LIBRARY>
<SO_TABLE>-</SO_TABLE>
<SO_FIELD>11</SO_FIELD>
<SO_DATATYPE>-</SO_DATATYPE>
<SO_LENGTH>2</SO_LENGTH>
<SO_FORMAT>---</SO_FORMAT>
<SO_TRANSFORMATION>1:1</SO_TRANSFORMATION>
</sourcesystem>
<sourcesystem>
<SO_PK_ID>1153</SO_PK_ID>
<SO_SOURCESYSTEM>SAS</SO_SOURCESYSTEM>
<SO_INTERFACEFILE>-</SO_INTERFACEFILE>
<SO_FIELDNAME_OS>ZISTUFE</SO_FIELDNAME_OS>
<SO_FIELDLABEL_OS>-</SO_FIELDLABEL_OS>
<SO_SAS_LIBRARY>-</SO_SAS_LIBRARY>
<SO_TABLE>VWFS.BHDL</SO_TABLE>
<SO_FIELD>-</SO_FIELD>
<SO_DATATYPE>DEC</SO_DATATYPE>
<SO_LENGTH>2</SO_LENGTH>
<SO_FORMAT>---</SO_FORMAT>
<SO_TRANSFORMATION>1:1</SO_TRANSFORMATION>
</sourcesystem>
</sourcesystems>
<characteristics>
<characteristic>
<CH_CHARACTERISTIC>1</CH_CHARACTERISTIC>
<CH_DEFINITION>low level interest category</CH_DEFINITION>
<CH_ANNOTATION>only for poor people...</CH_ANNOTATION>
</characteristic>
<characteristic>
<CH_CHARACTERISTIC>2</CH_CHARACTERISTIC>
<CH_DEFINITION>mid-level interest category</CH_DEFINITION>
<CH_ANNOTATION>for people like you and me</CH_ANNOTATION>
</characteristic>
<characteristic>
<CH_CHARACTERISTIC>3</CH_CHARACTERISTIC>
Seite 114
<CH_DEFINITION>high-level interst category</CH_DEFINITION>
<CH_ANNOTATION>for privileged people </CH_ANNOTATION>
</characteristic>
</characteristics>
</IOBJDoc>
</SAPBW>
Seite 115
G Function F_Create_XSLDocs
FUNCTION F_CREATE_XSLDOCS
( iobj_pk_id IN Number, la_language1 IN varCHAR)
RETURN CLOB IS
--- To modify this template, edit file FUNC.TXT in TEMPLATE
-- directory of SQL Navigator
--- Purpose: This Function F_CREAT_XSLDocs converts each Document of
an IOBJ
--(look at T_Language, La_xmldoc)
-- with the help of an XSL-Document into an HTML Document
-- The HTML-Document will be RETURNed as CLOB to the VB-Programm
-- for importing it into SAP via .NET Connector
-----
MODIFICATION HISTORY
Person
Date
Comments
Brink, dkx8954 02.09.2004 Beginnning
-------------- -------------------------------------------
--Variables
XSLDoc
Varchar(4000);
BEGIN
SELECT XMLTRANSFORM(la_xmldoc, xsl_xsldoc).getStringVal()
INTO XSLDoc
FROM T_XSLDOC, T_LANGUAGE
WHERE la_fk_iobj = iobj_pk_id AND la_language = la_language1
AND xsl_language = la_language1 and xsl_objtype = 'IOBJ';
return XSLDoc;
END ; -- Procedure
Seite 116
H Function F_CheckCreateIOBJ
FUNCTION F_CHECKCREATEIOBJ
(iobj_pk_id IN NUMBER )
RETURN varchar IS
--Variables
intCountCHA
intCountKYF
descshortE
desclongE
descshortD
desclongD
descshortF
desclongF
strReturn
intCountLanguage
intNumberLang
NUMBER(2,0);
NUMBER(2,0);
Varchar(20);
Varchar(50);
Varchar(20);
Varchar(50);
Varchar(20);
Varchar(50);
VARCHAR(100);
NUMBER(2,0);
NUMBER(2,0);
-- Purpose: This function looks if there exists exactly one record in the Tables
-- T_IOBJKYF and T_IOBJCHA which contain the Metadata
--(these Metadata are at least needed to create an IOBJ in SAP BW)
--- MODIFICATION HISTORY
-- Sylvia Brink 28.10.2004 'Beginning
-- Sylvia Brink 29.10.2004 'Updated
-- --------- ------ ------------------------------------------BEGIN
--Get the Number of records from the tables t_iobjkyf and t_iobjcha
SELECT Count(*) AS IOBJLaCount INTO intCountLanguage FROM T_Language
WHERE la_fk_iobj= iobj_pk_id;
SELECT Count(*) AS numberLanguages INTO intNumberLang FROM T_LINGUA;
--if the number of languages match the number of languages in t_lingua
IF intCountLanguage = intNumberLang then
-- Check if Shortdescription and Longdescriptions for ALL(!) Languages
-- have been made in Table T_Language
SELECT la_desc_short INTO descshortE FROM t_language
WHERE la_fk_iobj= iobj_pk_id and la_language='E';
SELECT la_desc_long INTO desclongE FROM t_language
WHERE la_fk_iobj= iobj_pk_id and la_language='E';
SELECT la_desc_short INTO descshortD FROM t_language
WHERE la_fk_iobj= iobj_pk_id and la_language='D';
SELECT la_desc_long INTO desclongD FROM t_language
WHERE la_fk_iobj= iobj_pk_id and la_language='D';
SELECT la_desc_short INTO descshortF FROM t_language
WHERE la_fk_iobj= iobj_pk_id and la_language='F';
SELECT la_desc_long INTO desclongF FROM t_language
WHERE la_fk_iobj= iobj_pk_id and la_language='F';
IF (descshortE is not NULL) and (descshortD is not NULL) and
(descshortF is not NULL) and (desclongE is not null) and
(desclongD is not null) and (desclongF is not null) then
Seite 117
--***if all Languages are present, check if METADATA is present,too:***
--Get the Number of records from the tables t_iobjkyf and t_iobjcha
SELECT Count(*) As IOBJCHACount INTO intCountCHA FROM T_IOBJCHA
WHERE cha_fk_iobj= iobj_pk_id ;
SELECT Count(*) As IOBJKYFCount INTO intCountKYF FROM T_IOBJKYF
WHERE kyf_fk_iobj= iobj_pk_id ;
--IF:
IF intCountCHA = 1 THEN
--ready to create IOBJ in SAP BW (FBE)!
strReturn :='CHA';
ELSIF intCountKYF = 1 THEN
strReturn := 'KYF';
ELSIF intCountCHA = 0 and intCountKYF = 0 THEN
strReturn:= 'noMetadata';
ELSE
strReturn:='ERROR';
END IF;
--*************************************************************
--if one item is missing, tell the user (return value)
ELSIF descshortE is NULL or descshortD is NULL or descshortF is NULL or
desclongE is null or desclongD is null or desclongF is null then
strReturn := 'noLanguage';
ELSE
strReturn := 'fehler';
END IF;
ELSIF intCountLanguage <= intNumberLang THEN
strReturn := 'noLanguage';
-- not enough records in t_language
ELSE
strReturn := 'noLanguage';
-- another mistake
END IF;
return strReturn;
END
Seite 118
II. Abkürzungsverzeichnis
VWFSAG
Volkswagen Financial Services AG
SAP BW
SAP Business Information Warehouse
SAP R/3
SAP Realtime System, Version 3
ABAP
AllgemeinerBerichts-Aufbereitungsprozessor,
Programmiersprache für SAP-Anwendungen
PSA
Persistant Staging Area
ODS
Operational Data Store
IOBJ
InfoObject
GUI
Graphical User Interface
HTML
Hypertext Markup Language
XML
Extensible Markup Language
SQL
Structured Query Language
XSL
XML Stylesheet Language
DTD
Document Type Definition
XSD
XML Schema Definition
CSS
Cascading Stylesheets
DOM
Document Object Model
DML
Data Manipulation Language
SQL
Structures Query Language
(C-)LOB
(Character-) Large Object
ADO
ActiveX Data Objetcs
IIS
Internet Information Services
J2EE
Java 2 Enterprise Edition
TREX
Text Retrieval and Classification
Seite 119
III. Literaturverzeichnis
Kaptitel 1:
[VWint2-04] VWFSAG
T
T
Organisationshandbuch der VWFSAG, Intranet der VWFSAG, 2004
Kapitel 2:
[Buc98]
Rüdiger Buck-Emden
T
T
Die Technologie das SAP R/3 Systems, Addison Wesley, 1998, ISBN 3 8273
1379 1, S.110
[Reu04]
T
Reuse, Svend
T
Data Warehouse, 2004,
http://www.lehrer-online.de/dyn/bin/420778-421140-2-dwh_merkblatt.pdf,
HTU
UTH
16.11.2004
[Kle04]
T
Klein, Raimund,
T
Erklärung diverser Begriffe des SAP BW- Systems, 2004
http://www.raimund-klein.de/index.html, 15.11.2004
HTU
UTH
[VWint1-03]
T
T
Semrau, Frank
SAP Business Information Warehouse, Intranet der VWFSAG
Dateiname: FKS BW Präsentation.ppt
[CoWo01] Computerwoche
T
T
Plattner: "ABAP und Java sind künftig gleichberechtigt", 2001
http://www.computerwoche.de/index.cfm?pageid=258&artid=30848&main_id
HTU
=30848&category=157&currpage=1&type=detail&kw=
Seite 120
UTH
[CoWo04]
T
SAP
Computerwoche
T
baut
Partnerschaft
mit
Microsoft
erheblich
aus,
15.05.2004,
http://www.computerwoche.de/index.cfm?pageid=254&artid=60892&type=de
HTU
tail&kw=sap%20webservices, 16.11.2004
UTH
[NetLex]
T
T
Net-Lexikon
Stichwort: Data-Warehouse, 16.11.2004
http://www.net-lexikon.de/Data-Warehouse.html
HTU
UTH
[Meh03]
T
Mehrwald, Christian
T
SAP Business Information Warehouse, Architektur, Konzeption,
Implementierung
dpunkt-Verlag, 2003, ISBN 3-89864-179-1 (BW G 803)
[See01]
T
Seemann, Achim et.al.
T
SAP Business Information Warehouse
SAP Press, 2001, ISBN 3934358411 (in Abt. I-SEB)
[MySAP01] Jens Krüger
T
T
Fallstudie mySAP.com, 28.01.2002
http://www.wiwiss.fu-berlin.de/php/suhl/referate/SAP.PDF, 16.11.2004
HTU
UTH
Kapitel 3:
[SAPHlp] SAP
T
T
Dokument als Online-Dokumentation, 2004,
http://help.sap.com/saphelp_sem320bw/helpdata/de/5e/f1f73a11e18449e10
HTU
000000a11402f/content.htm, 16.11.2004
UTH
Kapitel 4:
Seite 121
[Wol03]
T
Wolf, Frank
T
SAP Web Application Server
dpunkt-Verlag, 2003, ISBN 3-89864-214-3 (CS J 241)
[Pro02]
T
Prodise, Jeff
T
Entwicklerbuch Microsoft .NET
Microsoft Press, 2002, ISBN 3-87063-642-1
[The03]
T
Theobald, Patrick
T
SAP R/3 Kommunikation mit RFC und Visual Basic
Vieweg Verlag , ISBN 3-528-05878-1
[SAPConn02]
T
T
SAP
SAP .NET-Connector Version 1.0, 2002.
http://www.microsoft-sap.com/docs/dotnetconnector.nov02.pdf, 16.11.2004
HTU
UTH
[Lin03]
T
Thomas Lindner
T
Oracle 9.2 XML Datenbanken, 2002/03,
http://www.imn.htwk-leipzig.de/~kudrass/Lehrmaterial/Oberseminar/2002HTU
03/10.ppt;
UTH
16.11.2004
T
[Ora]
Oracle Referenz
http://downloadwest.oracle.com/docs/cd/B10501_01/appdev.920/a96612/d_xmlge2.htm
T
T
HTU
UTH
[W3C]
T
T
World Wide Web Consotium
XML Path Language (XPath) W3C Work Draft, 29.10.2004,
http://www.w3.org/TR/xpath20/, 16.11.2004
HTU
T
UTH
[Mül]
T
Prof. Gerriet Müller
SQL Tutorium, Jahr unbekannt
Seite 122
http://horatio.wiwi.uni-frankfurt.de/sql/intro.html, 16.11.2004
HTU
UTH
[Mo01]
T
Monadjemi, P.; Groth, F.
T
Visual Basic.net, Markt und Technik, ISBN 3-8272-6041-8, 2001, S.61
[DowNET]
T
SAP
T
Download .NET Connector
http://www.sap.com/services/servsuptech/smp/, 16.11.2004
HTU
UTH
[DowJRE]
T
Sun
T
Download Java Runtime Environment
http://java.sun.com/j2se/1.4.2/download.html, 16.11.2004
HTU
UTH
[Mono]
T
Das Mono-Projekt
T
Offizielle Seite des Mono-Projektes (Open Source-Alternative zu MS.NET)
http://www.mono-project.com/about/index.html, 09.12.2004
HTU
UTH
[Bri03]
T
Brink, Sylvia
T
Erstellung einer Intranetanwendung unter .NET mit Datenbankanbindung“,
Studienarbeit, FH Braunschweig/Wolfenbüttel, 2002-03, S.6
Kapitel 5:
[Kel03]
T
Keller, Krüger
T
ABAP Objects, SAP Press, ISBN 3-934358-37-3, 2003, S.254
Kapitel 6:
[Ora] s. Kapitel 4
T
T
Kapitel 7:
[DowTrv]
T
T
Microsoft
Seite 123
Download IE-Websteuerelemente für MS.NET
http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=
HTU
fac6350c-8ad6-4bca-8860-8a6ae3f64448, 09.12.2004
UTH
[SAPWeav] SAP
T
T
Plattform-Interoperabilität von SAP NetWeaver mit IBM Websphere und
Microsoft .NET, 2003
http://www.sap.com/germany/media/50063160.pdf, 09.12.2004
HTU
UTH
[MsIEWeb]
T
T
Microsoft
Internet Explorer WebControls Überblick über IE-Webcontrols, 2004
http://msdn.microsoft.com/workshop/webcontrols/overview/overview.asp,
HTU
UTH
09.12.2004
[Beats]
T
Beats Biblionetz
T
Definition des Begriffs Geschäftsprozess, 2003
http://beat.doebe.li/bibliothek/w01327.html, 09.12.2004
HTU
UTH
Zitiert aus: H. R: Hansen, G. Neumann im Buch Wirtschaftinformatik I im Text
H
H
Planung, Entwicklung und Betrieb von Informationssystemen (1978)
H
H
[Bal99]
T
Balzert, Heide
T
Lehrbuch der Objektmodellierung,Spektrum Akademischer Verlag ,ISBN:
3827402859, 1999, S.62
[Oes97] Oesterreich, Bernd
T
T
Objektorientierte Softwareentwicklung mit der Unified Modeling Language,
ISBN 3-486-23999-6, 1997, S.87
[Gal] Galileo Netlexikon
http://www.galileocomputing.de/glossar/gp/anzeige-8502/FirstLetter-G,
HTU
UTH
09.12.2004
Seite 124
[Bal2000]
T
T
Helmut Balzert,
Lehrbuch der Softwaretechnik, Spektrum Akademischer Verlag, ISBN
3827403014, S. 335
[SoKo] Software-Kompetenz
T
T
Gliederung einer Anwendungsfallbeschreibung, 2001-2004
http://www.software-kompetenz.de/?6131, 09.12.2004
HTU
UTH
Anmerkung:
Internetlinks können bei Aufruf nicht mehr aktuell sein.
Seite 125
IV. Abbildungsverzeichnis
Abbildung 1-1: Organisationsstruktur Informatik VWFS ................................. 5
Abbildung 2-1- Produktanalyse .................................................................... 11
Abbildung 2-2: Architektur des SAP BW ...................................................... 13
Abbildung 2-3: Datenfluss ............................................................................ 16
Abbildung 2-4. einfaches Bsp. einer additiven Fortschreibung .................... 18
Abbildung 2-5: Star-Schema ........................................................................ 19
Abbildung 2-6: m:n-Beziehung InfoCube-InfoObject .................................... 22
Abbildung 2-7: Beispiel einer Hierarchie ..................................................... 23
Abbildung 3-1: Dokumentationen im BW ..................................................... 25
Abbildung 4-1: Baumdarstellung eines XML-Dokuments ............................. 33
Abbildung 4-2: XML-Dokument-Anzeige per XSLT ...................................... 37
Abbildung 4-3: DataGrid-Beispiel ................................................................. 46
Abbildung 4-4: Aufbau der Dokumentationsverwaltung ............................... 49
Abbildung 5-1: Auswahl der SAP Proxy-Klasse ........................................... 51
Abbildung 5-2: Der NET Connector Assistent (Logon) ................................. 51
Abbildung 5-3: Der NET Connector Assistent 2 (FuBa-Auswahl)................. 52
Abbildung 5-4: SE16, Tabelle RSDIOBJT .................................................... 53
Abbildung 5-5: Funktionsbaustein RFC_READ_TABLE .............................. 54
Abbildung 5-6: DataGrid mit Tabelleninhalt .................................................. 57
Abbildung 5-7: Datenbanktabellen ............................................................... 59
Abbildung 6-1: mainIOBJ.aspx; Front-End ................................................... 69
Abbildung 6-2: Generierung von HTML- Dokumentationen ......................... 70
Abbildung 6-3: RSD1, Anzeige des InfoObject s .......................................... 75
Abbildung 7-1: Aktivitätsdiagramm ............................................................... 80
Abbildung 7-2: Treeview .............................................................................. 90
Abbildung 7-3: Inhalt von T_Node und T_Page .......................................... 92
Abbildung 7-4: vollständige URL mit IFrames .............................................. 93
Abbildung 7-5: IFrame in der Dokumenationsverwaltung ............................. 93
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
UT
TU
TU
UT
TU
UT
TU
UT
TU
UT
Seite 126
V. Begriffserklärungen erstellter Programmteile
Oracle-Tabellen
Tabellenname
Inhalt/
T_CHARACTE
Alle Characteristics (Ausprägungen) des InfoObjects (z.B.
RISTIC
N= New, O= Old)
T_IOBJ
Haupttabelle mit den Parametern, die für alle InfoObjects
gelten
T_IOBJCHA
Metadaten der Merkmale (Characters)
T_IOBJKYF
Metadaten der Kennzahlen (Keyfigures)
T_LANGUAGE
alle Kurz- und, technische und betriebswirtschaftliche
Beschreibungen,
XML-
Dokumentationen,
Langbeschreibung in diversen Sprachen (z. Zt. English,
Deutsch und Französisch)
T_LINGUA
alle Sprachen, in denen eine Dokumentation erstellt
werden soll
T_NODE
alle Knoten des Treeview-Steuerelements zur Navigation
zu den entsprechenden Seiten (-> T_Page)
T_ODS
Wird in Zukunft Haupttabelle für ODS-Objects sein und ist
über T_Language mit T_IOBJ verbunden, da ODS-Objects
und InfoObjects eine n:n- Beziehung haben.
T_PAGE
Enthält alle ASPX-Seiten der Dokumentationsverwaltung
T_ROLE
Enthält die Rollen Developer, Supervisor, User und
Customer. Jeder Anwender des Programms gehört in
Zukunft einer dieser Rollen an
T_SOURCESY
alle
STEM
InfoObject Daten bezieht (Kredis, Leasis und SAS)
T_STATUS
Status, in dem sich ein InfoObject befindet, z.B. von wem
es
Quellsystene
bereits
(Sourcesystems),
freigegeben
wurde
aus
und
ob
denen
sich
Dokumentation schon im SAP BW-System befindet
Seite 127
das
die
Oracle-Procedures und Functions
Procedure/ Function
Aufgabe
F_Check_create_iobj
Überprüft vor Anlage des InfoObjects im SAP BWSystem, dass alle für die Anlage notwendigen Daten
vorhanden sind. Wenn z.B. die Kurzbeschreibung
fehlt, bekommt der Anwender einen Hinweis.
F_Checkifdescriptions Überprüft vor Anlage der InfoObject-Documentation
im
SAP
BW-System,
ob
die
notwendigen
Beschreibungen in allen Sprachen vorhanden sind
F_Create_Xsldocs
Aus dem in der Tabelle T_Language (Spalte
La_xmldoc) gespeicherten XML-Dokument wird per
XSL-Document
(Tabelle
T_XSL)
ein
HTML-
Dokument generiert, welches an das aufrufende
Visual-Basic Programm zurückgegeben wird
P_Insert_Languages
Wird
durch
Aufruf
Tr_iobj_language_insert
des
ausgelöst,
Trigger
fügt
die
Procedure für jede Sprache einen neuen Datensatz
in T_LANGUAGE ein
P_Create_Xmldocs
Erstellt
aus
den
T_IOBJKYF/CHA,
Oracle-Tabellen
T_IOBJ,
T_LANGUAGE,
T_CHARACTERISTIC und T_SOURCESYSTEM für
jede Sprache ein XML-Dokument und speichert
dieses
in
der
Spalte
La_xmldoc der
Tabelle
T_LANGUAGE
Oracle-Views
View
Aufgabe
V_CreateIOBJCha
Enthält die Spalten der Tabellen, die für die Anlage
eines Merkmals (Characters) nötig sind
V_CreateIOBJKyf
Enthält die Spalten der Tabellen, die für die Anlage
Seite 128
einer Kennzahl (Keyfigure) nötig sind
Oracle-Triggers
Trigger
Aufgabe
Tr_[Tabellenname]
Wird vor Einfügen eines Datensatzes ausgelöst. Holt
z.B. Tr_IOBJ
den aktuellen Wert aus der Sequenz S_DB_Autowert
und fügt ihn in den Primary Key der Tabelle ein
Tr_IOBJ_Language_I Wird nach Einfügen eines Datensatzes in T_IOBJ
nsert_Rows
ausgelöst. Für jede Sprache wird eine Datensatz in
T_LANGUAGE eingefügt.
SAP- Funktionsbausteine
Funktionsbaustein
Aufgabe
BAPI_RFC_IOBJ_C
legt ein InfoObject im SAP BW-System an
REATE
RSOD_DOC_META_ legt eine Dokumentation zu dem angegebenen BWCHANGE
Objekt (hier: InfoObject) an
RFC_READ_TABLE
Liest den Inhalt aus der/ den angegebene(n)
Spalte(n) der SAP-internen Tabelle(n) aus
Erstellte Proxies
Proxy
Für Funktionsbaustein
RFC_READ_TABLE
RFC_READ_TABLE
PROXY_RSOD_DOC_META_CHANGE
RSOD_DOC_META_CHANGE
BAPI_IOBJ_CREATE
BAPI_RFC_IOBJ_CREATE
Seite 129