Embed Size (px)
Citation preview
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. Aufbau der Arbeit ................................................................................................................1 1.2. Motivation ...........................................................................................................................3 1.3. Volkswagen Financial Services ...........................................................................................4
2. Die Firma SAP und das SAP BW ........................................................ 6 2.1. Die Firma SAP und ihre Produkte ......................................................................................6 2.2. Die MySAP-Technologie ....................................................................................................7 2.3. Das Data Warehouse............................................................................................................9 2.4. SAP BW ............................................................................................................................11
2.4.1. Aufbau/ Architektur ......................................................................................................11 2.4.2. Datenfluss .....................................................................................................................14 2.4.3. InfoObject .....................................................................................................................20
3. Ist- und Sollzustand........................................................................... 25 3.1. IST-Zustand .......................................................................................................................25 3.2. SOLL-Zustand ...................................................................................................................28
4. Einsatz von Software-Techniken ....................................................... 31 4.1. XML ..................................................................................................................................31
4.1.1. Grundlagen XML..........................................................................................................32 4.1.2. Die Stylesheets CSS/ XSL ............................................................................................35 4.1.3. Weitere XML-Begriffe .................................................................................................37 4.1.4. Gründe für die Entscheidung für XML.........................................................................38
4.2. Oracle-Datenbank ..............................................................................................................40 4.3. .NET Technologie..............................................................................................................43 4.4. Visual Basic.net .................................................................................................................44 4.5. ADO.net.............................................................................................................................45 4.6. ASP.net / Webserver..........................................................................................................45 4.7. Anbindung an das SAP BW: Der SAP .NET-Connector..................................................46 4.8. Die TREX-Suchmaschine..................................................................................................47 4.9. Aufbau der Dokumentationsverwaltung ............................................................................48
5. 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. Erläuterung des Geschäftsprozesses ..................................................................................66 6.2. Überblick/ Hauptseite ........................................................................................................68 6.3. Erstellung von HTML-Dokumentationen aus relationalen Daten .....................................69
6.3.1. Anlage einer XML-Dokumentation in der Datenbank..................................................70 6.3.2. Transformation mittels XSL in das HTML-Format ......................................................72 6.3.3. Anzeige der Dokumentationen......................................................................................72 6.3.4. Anlage der Dokumentationen im SAP BW-System......................................................73
6.4. Anlegen eines InfoObjects im SAP BW-System...............................................................73 6.4.1. Vollständigkeitsprüfung................................................................................................74 6.4.2. Anlage des InfoObjects per Funktionsbaustein im SAP BW........................................74
7. 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. Versionisierung, Historisierung .........................................................................................85 7.3. Benutzereinstellungen........................................................................................................86 7.4. Migration vorhandener Daten in die Oracle-Datenbank....................................................87 7.5. Erweiterung um zusätzliche BW-Objekte..........................................................................88 7.6. Einführung einer weiteren Sprache....................................................................................89 7.7. Seitenaufbau/ Treeview .....................................................................................................89
7.7.1. Einführung und Installation ..........................................................................................89 7.7.2. Erklärung der Datenbank-Tabellen ...............................................................................91
7.8. Anzeige einer Online-Dokumentation ...............................................................................93 7.9. TREX/ SAP Enterprise Portal............................................................................................94
8. Schlusswort ....................................................................................... 96 8.1. Fazit ...................................................................................................................................96 8.2. Danksagung .......................................................................................................................98 8.3. 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-Ware-
house Produkt, das SAP Business Information Warehouse (SAP BW), wer-
den 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 Soft-
wareprogramm werden in Kapitel 4 die geeigneten Softwaretools und Tech-
niken knapp erläutert. Das Unterkapitel XML ist aufgrund der hohen Rele-
vanz 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 Archivie-
rung 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 Dokumenta-
tion im BW beschrieben, Weiterhin werden die Implementierungstechniken
Seite 1
Seite 2
mit Schwerpunkt auf die in Oracle programmierten Funktionen und Prozedu-
ren 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 3
1.2. Motivation
Anlass der Diplomarbeit ist eine zunehmende Unübersichtlichkeit über die
Zusammenhänge der BW-Objekte des SAP Business Information Ware-
house-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 Entwicklungsabtei-
lungen, 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 betriebswirtschaftli-
che 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 zu-
sammenzutragen, auf Basis dieser ein Konzept zu erstellen und dieses an-
satzweise 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ätssiche-
rung geschaffen werden. Von Vorteil ist zudem eine einheitliche Spei-
cherung 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 4
Für diese Hauptanforderungen wird ein Konzept erarbeitet, in dem die not-
wendigen Leistungsmerkmale, die die Dokumentenverwaltung haben soll,
herausgestellt, aufbereitet und in Zusammenhang gebracht werden. Basie-
rend 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 Kun-
denservice 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. Personal-
Steuerung).
Die Service Center sind Auftragnehmer der Market Center, die in diesem
Falle als Auftraggeber bzw. Kunde auftreten. Die Kosten werden intern ver-
rechnet. 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 Sys-
tementwicklung 1-4. Die Systementwicklung 4, in der sich auch die Abteilung
I-SEB befindet, entwickelt und wartet die Systeme der Unternehmenssteue-
rung. I-SEB beschäftigt sich mit dem SAP Business Information Warehouse,
ein Data Warehouse-System, das Daten aus verschiedenen Systemen zent-
ral zur Auswertung bereitstellt. Die Abteilung besteht aus etwa 15 internen
und 20 externen Mitarbeitern. Ihr Aufgabenbereich ist es, im Auftrag der
Seite 5
Fachbereiche Systeme und Programme für das BW zu entwickeln und die
Funktionalität und Korrektheit bestehender BW-basierter Systeme zu ge-
währleisten.
Weiterhin ist die Systementwicklung 1 für die Finanzierungs- und Leasing-
produkte, 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. TP
1PT
Abbildung 1-1: Organisationsstruktur Informatik VWFS
TP
1PT [VWint2-04]
Seite 6
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 Be-
deutung 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 erfolg-
reich betriebswirtschaftliche Standard-Anwendersoftware her. SAP bedeutet
ursprünglich „Systeme, Anwendungen und Produkte“.
Bei dem ersten Produkt der SAP AG handelte es sich um eine Finanzbuch-
haltungssoftware mit dem Namen RF. Die Software, die in Assembler pro-
grammiert wurde und unter DOS lief, ist auch unter dem Namen R/1 (Real-
time-System, Version 1) bekannt. Für den Nachfolger R/2 wurde zur besse-
ren 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 Interpreter-
sprache.
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äsenta-
tionsschicht, der Applikationsschicht und der Datenbankschicht. Weiterhin
gibt es eine Webserver-Schicht, so dass SAP-Anwendungen aus dem Web-
browser aufgerufen werden können.
Verwendet wurden in dem R/3 System auch erstmals relationale Datenban-
ken, einheitliche grafische Oberflächen und plattformunabhängige Anwen-
dungen.
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 7
Business Objekten und der objektorientierten Weiterentwicklung von ABAP
mit ABAP Objects ergänzt. Das Laufzeitsystem des R/3 selbst ist in den Pro-
grammiersprachen 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 betriebswirtschaftli-
che Anwendungsbereiche wie Controlling, Anlagenwirtschaft, Materialwirt-
schaft, Vertriebslogistik, Qualitätsmanagement und einige mehr abgedeckt.
Die bekanntesten SAP-Module sind die Module für die Bereiche Kundenver-
waltung (SAP CRM, Customer Relationship Management), Finanzbuchhal-
tung (SAP FI, Financial Accounting), Data Warehouse (SAP BW) und Bank-
kunden (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 unterneh-
mensweiter betriebswirtschaftlicher Client/ Server-Anwendungen. TP
2PT In dem
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-Applikation TP
3PT. Diese ist im Begriff, das Sys-
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-
TP
2PT [Buc98]
TP
3PT [MySAP01]
Seite 8
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 Webanwendun-
gen 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-Anwendun-
gen erstellt werden TP
4PT“. Die Computerwoche schrieb weiter, dass die „Die
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-Infra-
struktursoftware Netweaver mit Microsofts .NET.“TP
5PT.
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 einma-
liges Einloggen (single-sign-on) kann ein SAP-Anwender auf alle Anwendun-
gen, 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.
TP
4PT [CoWo01]
TP
5PT [CoWo04]
Seite 9
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 rele-
vanten Daten aus den Datenquellen zu einem gemeinsamen konsistenten
Datenbestand zusammengeführt werden.“ TP
6PT
Das Konzept des Data-Warehouse-Systems wurde 1992 von Immon einge-
fü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.”TP
7PT TP
8PT
Subject-oriented bedeutet, dass der Informationsbedarf von Entscheidungs-
trä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 basie-
rende 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
TP
6PT [NetLex]
TP
7PT [Reu04]
TP
8PT [VWint1-03]
Seite 10
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 reagie-
ren. 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-Sys-
tems:
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 ver-
kauft 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, Pro-
dukt). Aus dieser Abfrage resultiert die Anzahl der verkauften Produkte (Pro-
duktmenge), aufgeteilt nach Region und Zeit.
Seite 11
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-Ob-
jekte beschrieben.
Die Client / Server- Architektur des SAP BW teilt sich in folgende drei
Schichten auf: Datenbankschicht, Applikationsschicht und Präsentations-
schicht (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 Ein-
satz sind - MS-SQL-Server und DB2 eingesetzt. Diese Daten können im
2.4.1. Aufbau/ Architektur
Seite 12
ABAP-Dictionary eingesehen werden. Das ABAP-Dictionary ist das Meta-
data-RepositoryTP
9PT für die Datenstrukturen des SAP BW. TP
10PT Im ABAP-Dictionary
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 Fel-
dern bestehen. Die technischen Eigenschaften eines Feldes werden dabei
als Domäne und die semantischen als Datenelement bezeichnet. Zum Bei-
spiel 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 tech-
nisch 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 Applikations-
schicht zur Verarbeitung weitergeleitet werden.
TP
9PT Repository (engl.) = Behälter, Aufbewahrungsort
TP
10PT [Meh03], S.16
Seite 13
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 Bild-
schirmbild 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 Admi-
nistrator 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 Datenbereit-
stellungsprozess 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 ausge-
wertet 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 14
Monat mit den am meisten verkauften Produkten eines Jahres. Das Repor-
ting erfolgt mittels QueriesTP
11PT auf Stamm- und Bewegungsdaten.
Im SAP BW gibt es die drei Daten: Stammdaten, Bewegungsdaten sowie die
aufzubereitenden Metadaten. Stammdaten sind die Daten eines Unterneh-
mens, die sich im Laufe der Zeit kaum oder nicht verändern. Dieses können
z.B. Informationen über Kunden oder Produkte (z.B. Produktname, Produkt-
nummer) 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 Stammda-
ten 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 BW-
Objekt besteht aus technischen und fachlichen Metadaten. Die technischen
Metadaten sind z.B. das Datenformat (INT, CHAR …) bzw. die Ablagestruk-
tur 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.
Um Daten auswerten zu können, werden diese aus Quellsystemen extrahiert
und im BW-System zur Datenanalyse modifiziert und aufbereitet. Dieser Pro-
TP
11PT Query (engl.) = Abfrage; basierend auf der SQL-Syntax
2.4.2. Datenfluss
Seite 15
zess wird als Staging bezeichnet. In dem Staging-Prozess durchlaufen die
Daten vier logische Ebenen TP
12PT:
• Extraction Layer TP
13PT
• Inflow Layer
• Transformation Layer
• Integration Layer
Die einzelnen Layer sind die Schnittstellen zwischen den oben genannten
Schichten (s. Abbildung 2-2). Der Extraction Layer ist die Schnittstelle zwi-
schen 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 Daten-
bankschicht 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äsentations-
schicht.
Zur Verdeutlichung des Prozesses der Datenaufbereitung erfolgt eine detail-
lierte 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-
TP
12PT [Meh03]
TP
13PT Layer (engl.) = Schicht, Ebene
Seite 16
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 17
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 Metadaten TP
14PT.
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 quellsystem-
spezifischer 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 Über-
tragungsregeln gelangen die quellsystemspezifischen Daten der DataSource
in die InfoSources. Sie werden technisch mit Mapping, Zuweisung von Kon-
stanten, 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 Kommunikati-
onsstruktur bezeichnet.
TP
14PT [Meh03], S.18
Seite 18
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 Daten-
ziel-spezifisch, d.h. es wird für jedes Datenfeld eines Datenzieles die Fort-
schreibungsart festgelegt. Jede InfoSource kann dabei Daten in mehrere
Datenziele fortschreiben. Mögliche Fortschreibungsarten sind: keine Fort-
schreibung, Ü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 19
piert und optimiert wurde. Ein InfoCube deckt einen betriebswirtschaftlichen
Bereich ab (z.B. Vertrieb ) und ist prädestiniert für das Reporting aus hoch-
verdichteten, unveränderlichen Daten.
Weiterhin gibt es ODS-Objekte, die den Vorteil der sofortigen Verfügbarkeit
haben (transaktionale ODS-Objekte), aber auch den Nachteil der schlechte-
ren Performance und Qualitätssicherung bei größeren Datenmengen aufwei-
sen. ODS-Objekte dienen der Speicherung von Daten, die sich schnell
verändern. Das ODS-Objekt hat den Vorteil des Delta-Mechanismus, wes-
wegen 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 Faktenta-
belle 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 20
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 gemeinsa-
men Kontext darstellen.
Eine weitere Möglichkeit der Analyse und des Reporting ist das Anlegen
eines InfoSets. Im BW-System der Volkswagen Bank werden zumeist Info-
Sets verwendet, da dort auf ODS-Objekten selber nicht analysiert wird. Info-
Sets haben wie Multiprovider keine eigene physische Datenhaltung, sondern
erhalten temporär zum Zeitpunkt der Analyse die nötigen Daten aus den
angegebenen (ODS-) Objekten.
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
2.4.3. InfoObject
Seite 21
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 hinzuge-
fügt werden. Diese Dimension ist das Zeitmerkmal. Die Dimension Zeit-
merkmal 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 Aus-
lieferung bereits konfigurierten InfoObjects bezeichnet. Man kann aus-
schließlich Zeitmerkmale des Business Content benutzen, das Anlegen eige-
ner 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 22
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 darge-
stellt werden.
Begriffserklärungen Im Folgenden werden einige Begriffe TP
15PT erklärt, welche in Zusammenhang mit
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 „Auf-
traggeber“ hat zum Beispiel die Attribute „Auftraggeberland“ und „Aktienge-
sellschaft“. 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
15PT [Kle04]
Seite 23
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 Kundenstamm-
texten gefüllt.
Abbildung 2-7: Beispiel einer Hierarchie
Klammerung (Merkmal)
Mehrere Merkmale können miteinander zu einem neuen Merkmal geklam-
mert 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 Stammda-
ten dieses so definierten Merkmals sind völlig unabhängig von den Stamm-
daten 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 24
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 InfoOb-
jects Kunde.
Aggregation (Kennzahl)
Die Aggregation wird für die Verdichtung von Daten benötigt. Zumeist wer-
den Werte aufsummiert. Zum Beispiel verdichtet das Produktaggregat die
Kennzahlen pro Produkt-Nr und Zeit.
Seite 25
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 26
Um nicht jede Dokumentation manuell anlegen zu müssen, gibt es bisher
eine von Mitarbeitern selbst erstellte Access-Datenbank. Diese wird aller-
dings 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 modifi-
ziert 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 Doku-
mentationen nur ein Satz
• es gibt keine Zuständigkeiten für das Anlegen und Pflegen von Doku-
mentationen
• Ä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 27
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 Design-
mö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-In-
formationen zu dem Datenfluss, zur Herkunft und Verwendung eines BW-
Objektes. 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-Dokumenta-
tion 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 zueinan-
der ist hierarchisch verlinkt. Diese Online-Dokumentation soll später in die
Dokumentation eingebaut werden.
Die Struktur der Online-Dokumentation ist in drei Teile eingeteiltTP
16PT:
• allgemeine Angaben (Erstellungsdatum, technischer Name, System,
Beschreibung (kurz), Beschreibung (lang) )
• BW-Objekt- Dokumentation (s.o.)
• Links zu Online-Dokumentationen abhängiger BW-Objekte
TP
16PT [SAPHlp]
Seite 28
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 Mitarbeiterbefra-
gungen entstehen die Anforderungen an die neue Dokumentationsverwal-
tung.
Da zu Beginn dieser Arbeit kaum Informationen über das Arbeitsgebiet vor-
lagen, wurden die internen Mitarbeiter teils per Interview, teils per Fragebo-
gen (Anhang TAT, S.99) befragt. Aufgrund der großen Anzahl, erfolgte die
Befragung der externen Mitarbeiter ausschließlich per Fragebogen TP
17PT. So
konnten diverse Kritikpunkte des Ist-Zustands, Wünsche zu deren Verbesse-
rung und Informationen über die Mitarbeiter (Bedarf an Dokumentenverwal-
tung, 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 29
• zu der Einführung eines Change Request-Verfahrens bei Anmerkun-
gen 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 fol-
gen die groben Anforderungen des SOLL-Zustands. Es soll eine plattformu-
nabhä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 wer-
den. 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
• TEinführung von Zuständigkeiten bzw. Rollen: T
Fachbereichsverantwortlicher bzw. Auftraggeber(Customer), zustän-
diger Entwickler (Developer), Supervisor (Kontrolle der Dokumentatio-
nen) und normaler Anwender ohne Sonderstatus
• Einführung von Berechtigungen (Lesen, Schreiben, Ändern, Freige-
ben) analog zu den Zuständigkeiten
• Anzeige aktueller Informationen und Anmerkungen zu einem BW-Ob-
jekt
• komfortable Navigation zwischen den in Bezug stehenden
Dokumentationen und Meta-Daten der BW-Objekte
• Für die Beschaffung von Informationen besteht Holpflicht; eine Email-
Benachrichtigung erfolgt nur, wenn ein Mitarbeiter im Rahmen des
Erstellprozesses für eine Dokumentation zuständig ist
• Einrichtung eines Versionsmanagements erwünscht
Seite 30
• Die Darstellung des Datenflusses per Web Applikation Server, bzw.
die Einbindung der bestehenden Seiten
• Im Falle der Dokumentationserstellung ist die Erstellung einer webba-
sierten Anwendung nötig, damit sich im Außendienst befindliche Mit-
arbeiter die Anwendung von jedem internetfähigen Endgerät nutzen
können
• Einführung eines Prozesses zur Erstellung eines BW-Objektes, wel-
cher 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 not-
wendig. Diese müssen diverse Kriterien wie z.B. die Plattformunabhängig-
keit, die Schnittstelle zu einer Datenbank, den Austausch der Dokumentatio-
nen mit der SAP-Datenbank und die grafische Darstellung der Dokumentati-
onen erfüllen.
In Kapitel 4 werden diese Techniken und Tools näher beschrieben.
Seite 31
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 grundlegen-
der und wichtigster Bestandteil der Dokumentationsverwaltung ist.
Seite 32
XML (Extensible Markup Language) ist seit 1998 ein Standard des W3CTP
18PT.
Seinen Ursprung hat XML in SGML (Standard Generalized Markup Langu-
age).
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 Leis-
tungsumfang 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 > geschrieben werden
• Kommentare: <!-- -->
Sämtlicher Text, der kein Markup ist, bildet die Zeichendaten des Doku-
ments.
XML-Dokumente beginnen mit einer XML-Deklaration (Prolog):
T<? xml version="1.0" encoding="ISO-8859-15"?>
In dieser stehen die verwendete XML-Version und ggf. die Kodierungs- de-
klaration 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
18PT W3C: World Wide Web Consortium
4.1.1. Grundlagen XML
Seite 33
Zwischen diesen Tags befinden sich die Kindelemente, die wiederum Kind-
elemente 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 Ele-
mente. 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"?> T<Seminar> <Name> </Name> <Teilnehmer> <Anzahl></Anzahl>
Seite 34
</Teilnehmer> <Treffen> </Treffen> </Seminar>
Beispiel 4-1: XML-Dokument
Wohlgeformtheit Ein XML-Dokument muss wohlgeformt sein, d.h. es muss sich an die syn-
taktischen 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 Kodie-
rungsdeklaration
• 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 darge-
stellt. 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 35
<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.
XML ist sehr gut für den plattformunabhängigen Austausch von Daten geeig-
net. Weiterhin können XML-Dokumente auch zur Ansicht bereitgestellt wer-
den. 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 Styles-
heets. 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 wer-
den. 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
4.1.2. Die Stylesheets CSS/ XSL
Seite 36
vor. Die Regeln, wie ein Dokument transformiert wird, werden mit Templates
aufgestellt, die mit XPath definiert werden. XPath selektiert Teile eines XML-
Dokuments mittels Pfadangaben. Das Beispiel unten zeigt ein simples XSL-
Stylesheet. 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> <!-- Non-XSLT Elements are simply copied --> <head> <title>Seminar</title> </head> <h1>Seminar</h1> <table border="1"> <tr> <th>Name</th> <th>Zeit</th> </tr> <!-- Now find templates to transform my children --> <xsl:apply-templates select="Seminar"/> </table> </html> </xsl:template> <!--*********** 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 37
Abbildung 4-2: XML-Dokument-Anzeige per XSLT
Vor- und Nachteile CSS/ XSL Das CSS-Stylesheet ist einfacher zu erlernen, hat aber begrenzte Möglich-
keiten. 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.
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 angege-
ben 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).
4.1.3. Weitere XML-Begriffe
Seite 38
Die DTD Spezifikationen wurden vom W3C Konsortium vorgeschlagen, wäh-
rend die XML Schemas auf einen Vorschlag von Microsoft basieren aber
kürzlich vom W3C Konsortium vereinheitlicht und standardisiert wurden.
TDOM T (Document Object Model):
DOM gibt ein Dokument in Form eines Baumes wieder. Die meisten XML-
Parser implementieren einen von zwei API’s: entweder DOM oder SAX
(Simple API for XML).
TXPathT (XML Path Language):
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 2003TP
19PT und
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 Doku-
mentationsverwaltung tendieren zu dem dokumentenorientierten XML, da sie
letztendlich zur Ansicht genutzt werden und von unterschiedlicher Struktur
sind.
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
19PT [W3C]
4.1.4. Gründe für die Entscheidung für XML
Seite 39
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 Datenbearbei-
tung, 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 Browser-
Darstellung 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 verschiede-
nen Stylegebungsmöglichkeiten XSL eingesetzt. Glücklicherweise unterstüt-
zen SAP und Microsoft die beiden Formate und es gibt in dem .NET Frame-
work und in der Oracle-Datenbank zahlreiche Klassen und Methoden zu ihrer
Bearbeitung.
Seite 40
4.2. Oracle-Datenbank
Oracle ist ein objekt-relationales Datenbanksystem. Bei relationalen Daten-
banken werden per SQL-Anweisungen (Structured Query Language) Anfra-
gen an die Datenbank ausgeführtTP
20PT. Mit der DDL (Data Definition Language)
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 Oracle-
Instanz für die Zwischenspeicherung von XML-Dokumenten und die perma-
nente 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 Entwicklungsumge-
bung 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:
• TLOB (Large Object):T LOB: CLOB (Character LOB), BLOB (Binary
LOB). Methode, eine große Menge (bis zu 4GB) unstrukturierter Daten
in einer Tabellenspalte zu speichern
• TRelational:T Verteilung der Elemente/ Attribute auf rel. Tabellen (ohne
Tags), Datenorientiert
• TDecomposed (strukturiert):T geringerer Speicherbedarf, weil Tags
nicht gespeichert werden müssen, Zugriff aus einzelne Elemente
schneller. Liegt ein XML-Schema vor, kann man eine XML-Dokumen-
tation in relationale Tabellen zerlegen und umgekehrt. XMLTYPE:
neu entwickelter Datentyp, der das Speichern und Abfragen von XML-
Dokumenten möglich macht. XMLType ist intern als CLOB definiert,
TP
20PT [Mül]
Seite 41
Dokumentenorientiert (unregelmäßige Struktur), Composed (unstruk-
turierte 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 abzu-
wiegen, 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 zusammenTP
21PT,
• das Original-Dokument geht nicht verloren (XMLTYPE beinhaltet
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-Dokumen-
ten 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 5).
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 42
Diverse Funktionen und Packages Funktionen: ExistsNode(): Überprüfung der Existenz eines Knotens per XPath,
Extract(): extrahiert einen oder mehrere Knoten, die der XPath-
Angabe 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 Da-
ten
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-Do-
kument 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 relatio-
nal abgelegten Daten problemlos möglich ist.
TP
21PT ISO-Standard 9075 -14:2003: definiert, wie SQL mit XML zusammenarbeitet
Seite 43
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 Marke-
tingbegriff, 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. TP
22PT
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#TP
23PT, J#, Oberon.net u.a.
• 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 Klas-
senbibliothek. Die CLR des .NET Frameworks ist, genau wie die
Virtual Machine von Java, plattformunabhängig. Die CLR führt den TP
22PT [Mo01]
Seite 44
Code aus. Bevor ein Programm von der CLR ausgeführt werden kann,
wird der Code in IL (Intermediate Language), eine plattformunabhän-
gige Zwischensprache, umgewandelt.
• Aufgrund der Plattformunabhängigkeit können Compiler oder eine
Implementierungen von .NET erstellt werden. Im Rahmen des Mono-
Projektes TP
24PT werden daher sowohl ein Compiler für C# als auch ein
.NET Framework für Linux entwickelt, die beide als Open Source ver-
fü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-Ser-
vice und Konsolenanwendungen, einen Designer für Formulare, aus-
fü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 Funktio-
nen 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.
TP
23PT [Bri03]
TP
24PT [Mono]
Seite 45
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 Datenban-
ken realisiert. In der .Net-Klassenbibliothek befinden sich die von ADO ver-
wendeten 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 ASP-
Seite 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 46
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 Steuerele-
ment 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, Informa-
tionen und Geschäftsprozesse technologie- und organisationsübergreifend
zusammenführt. Alle zukünftigen Lösungen werden auf SAP NetWeaver auf-
bauen.
Der SAP NetWeaver ermöglicht die vollständige Interoperabilität mit Micro-
soft .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 Windowsanwen-
dungen, 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 47
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 ein-
gesetzt werden, welches für WebServices verwendet wird.
Systemvoraussetzungen und Installation Um mit dem SAP.NET-Connector arbeiten zu können ist das Visual Stu-
dio.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 her-
untergeladen werden TP
25PT . Zusätzlich ist die Installation der Java Runtime Envi-
ronment TP
26PT notwendig. Nach der erfolgreichen Installation dieser beiden
Komponenten steht bei der Erstellung eines neuen Projektes im Visual Stu-
dio das ICON .SAP Connector Class im Visual Studio .NET zur Auswahl. Bei
dieser Klasse handelt es sich um eine Proxyklasse. Ein Proxy ist ein Pro-
gramm, das zwischen HServer H und HClient H vermittelt und das nur in C# gene-
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 Suchma-
schine für das Metadata Repository des BW existiert und TREX (Text Retrie-
val 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 spe-
ziellen Begriffsabfragen. Außerdem ermöglicht der TREX-Server verschie-
dene Text-Mining-Funktionen (exakte Suche, Phrasensuche, Boolesche
Suche, Fuzzysuche, linguistische Suche, Wildcard-Suche). Text Mining ist TP
25PT [DowNET]
Seite 48
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 pro-
duktiv im Einsatz ist. Diverse Testinstallationen sind jedoch vorhanden. Da
der Aufwand des Customizing von TREX als sehr hoch und somit teuer ein-
geschätzt wurde (ca. 40 Personentage), musste der Einsatz von TREX auf
das Jahr 2005 verschoben werden. TREX wird dann über das SAP Enter-
prise 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, wel-
ches 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 ASPX-
Seiten 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
26PT [DowJRE]
Seite 49
Abbildung 4-4: Aufbau der Dokumentationsverwaltung
Seite 50
5. Anzeigen und Speichern von Daten
Damit der Benutzer diverse Informationen zu InfoObjects und ihren Doku-
mentationen einsehen kann, ist die Anzeige von im SAP-System befindlichen
Daten notwendig. Hierfür wird der SAP .NET-Connector verwendet. Weiter-
hin 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-Connec-
tors 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.
Um ein neues Projekt anzulegen, wird im Visual Studio die SAP Connector
Class ausgewählt (Abbildung 5-1).
5.1.1. Erstellung einer Proxy-Klasse
Seite 51
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 SAP-
System 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 52
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.
Für das Auslesen von Inhalten einer SAP-internen Tabelle wird der Funk-
tionsbaustein RFC_READ_TABLE verwendet. Funktionsbausteine sind die
mit Abstand am häufigsten verwendete Methode, um anwendungsübergrei-
fende wieder verwendbare Softwarekomponenten für ein SAP-System abzu-
bilden. Dieser Funktionsbaustein hat die Aufgabe die Inhalte von SAP-Ta-
bellen 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)
5.1.2. Kommunikation von .NET per SAP-Funktionsbaustein RFC_READ_TABLE
Seite 53
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 inner-
halb eines SAP-Systems als auch von anderen SAP-Systemen und Fremd-
systemen per RFC (Remote Function Call) erfolgen. Da dieser Funktions-
baustein RFC-fähig ist, kann er von Außen, in diesem Fall mittels des SAP
.NET-Connector, aufgerufen werden TP
27PT.
Im Deklarationsteil werden diverse Parameter angegeben: die Importpara-
meter, welche beim Aufruf des Funktionsbausteins übergeben werden müs-
sen, die Exportparameter, die nach Durchlauf des Programms an den Auf-
rufenden 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 einge-
schlossen. Im Quelltext wird der Inhalt der gewünschten Tabelle mittels einer
Query ausgelesen und alle Inhalte in die Ausgabetabelle DATA geschrieben.
TP
27PT [Kel03]
Seite 54
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 Da-
tensätze (Rows, Zeilen)
Rowskips Anzahl der Zeilen, die übersprungen
werden sollen
Data gelesene Daten (out), d.h. Inhalt der
Spalten
Seite 55
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.
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 Funktionsbau-
stein 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) eingese-
hen 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.
5.1.3. Verwendung eines Proxys mit VB
Seite 56
Weiterhin wird eine neue Instanz der SAP.Connector.Destination-Klasse er-
zeugt. 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 SAP-
System 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 Proxy-
Klasse kommuniziert, bewirkt wiederum den Aufruf des Funktionsbausteins
RFC_READ_TABLE. War dieser Aufruf erfolgreich, gibt der Funktionsbau-
stein 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 zuge-
ordnet 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 Funktionsbau-
steins 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 57
Die Anzeige von InfoObjects aus der SAP-internen Tabelle RSDIOBJT sieht
folgendermaßen aus:
Abbildung 5-6: DataGrid mit Tabelleninhalt
Im Function Builder (Transaktion se37) können alle Funktionsbausteine des
SAP-Systems eingesehen werden. Die für diese Arbeit verwendeten Funk-
tionsbausteine 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
5.1.4. Verwendung von Funktionsbausteinen und Tabellen
Seite 58
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
Die Tabelle T_IOBJ (Abbildung 5-7) ist die Mastertabelle der Oracle-Daten-
bank. In dieser Tabelle werden die Daten gespeichert, die für jedes InfoOb-
ject 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:n-
Beziehung).
Weiterhin kann ein InfoObject mehrere Quellsystemeinträge besitzen. Somit
besteht zwischen der Tabelle T_IOBJ und T_SOURCESYSTEM eine 1:n-
Beziehung. Um einen Überblick über alle Tabellen der Oracle-Datenbank
vwfsdw1e zu bekommen, kann die Grafik im Anhang (Anhang C, S.107)
eingesehen werden.
5.2.1. Logischer Datenbankentwurf
Seite 59
Abbildung 5-7: Datenbanktabellen
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 VARCHAR2(5) DEFAULT 'true', hasdescriptionmiddle VARCHAR2(5) DEFAULT 'false', hasdescriptionshort VARCHAR2(5) DEFAULT 'true', infoobjecttype VARCHAR2(9) DEFAULT NULL infoarea VARCHAR2(9), iobj_fk_projectpart NUMBER(9,0),
5.2.2. Physischer Datenbankentwurf
Seite 60
iobj_fk_reference NUMBER(9,0), iobj_format VARCHAR2(30), iobj_annotation VARCHAR2(100), iobj_fk_status NUMBER(3,0) DEFAULT 0 iobj_isiobjkyf NUMBER(1,0), iobj_isiobjcha NUMBER(1,0), iobj_bwappl VARCHAR2(9) DEFAULT 'BW' iobj_iscreatedinbw 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 Datenin-
tegrität. Dazu gehören Primärschlüssel, referentielle Constraints und einfa-
che feldgebundene Prüfungen. Auch sind sie wichtig, um einen Wertebereich
Seite 61
zu ergänzen oder um die Abhängigkeit von Tabellen untereinander festzule-
gen.
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 Pro-
gramm, 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 62
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 Pro-
cedure nur mit den entsprechenden Rechten ausführen.
Sie sind auch performanter als Visual Basic Code. Bei mehreren SQL-An-
weisungen 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 langu-
age/ 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 vorge-
stellt. 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 Manipu-
lation Language) verwendet. Zu Testzwecken sollen später (Kapitel 6) alle
Daten eines InfoObjects in die Tabellen eingefügt werden. In dem unten zu
Seite 63
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 dop-
pelten Eintragungen in T_Language kommt und nicht bei jeder Änderung
überprüft werden muss, ob der Datansatz schon existiert. Nachdem der Trig-
ger 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 64
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-Bezie-
hung, da ein InfoObject Daten aus keinem oder ein- oder mehreren Quell-
systemen bezieht. Für das Test-InfoObject werden zwei Datensätze ange-
legt:
Seite 65
-- 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 BW-
System angelegt werden. Die Speicherung gilt als Grundlage für die Erstel-
lung der Dokumentation und der Anlage des InfoObjects im SAP BW-System
in Kapitel 6.
Seite 66
6. Prozess der Erstellung eines InfoObjects und
seiner Dokumentation im SAP BW-System
Inhalt dieses Kapitels ist die Beschreibung der einzelnen Schritte der Pro-
zesserstellung eines InfoObjects und seiner Dokumentation im SAP BW-
System.
InfoObjects müssen oftmals bei neuen Projekten oder deren Weiterentwick-
lung 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 wer-
den 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 BW-
System 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 (Kontrol-
leur) angehört.
Tritt der Geschäftsfall ein, dass ein neues InfoObject im Rahmen eines Pro-
jektes 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 67
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 68
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 69
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 70
Abbildung 6-2: Generierung von HTML- Dokumentationen
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
6.3.1. Anlage einer XML-Dokumentation in der Datenbank
Seite 71
Dbms_xmlgen TP
28PT aus den relational gespeicherten Daten XML-Dokumente
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-XML-
Dokument, 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 XML-
Fragmente 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
28PT [Ora]
Seite 72
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.
Eine Dokumentation wird zur Ansicht im SAP BW-System in HTML
transformiert. Die Transformation eines XML-Dokuments in ein HTML-
Dokument 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.
Wird der Button Show Doc. ausgewählt, öffnet sich die Seite
ShowDocumentation und es wird die gewünschte Dokumentation im HTML-
Format angezeigt. Dieses geschieht durch Aufruf der bereits erwähnten
Oracle-Function F_create_XSLDOCS. Um eine Oracle-Function aus einem
Visual Basic-Programm aus aufrufen zu können, wird die Klasse
System.Data.OracleClient (ab .NET Framework 1.1) 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.
6.3.2. Transformation mittels XSL in das HTML-Format
6.3.3. Anzeige der Dokumentationen
Seite 73
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 Oracle-
Function 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.
6.3.4. Anlage der Dokumentationen im SAP BW-System
Seite 74
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.
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
6.4.1. Vollständigkeitsprüfung
6.4.2. Anlage des InfoObjects per Funktionsbaustein im SAP BW
Seite 75
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 76
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 77
• 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.
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. TP
29PT
Da der Geschäftsprozess Erstellung einer InfoObject-Dokumentation sehr
umfangreich ist, ist er auch gleichzeitig ein eigener Meilenstein. „Ein
Geschäftsprozess ist eine Zusammenfassung von fachlich
zusammenhängenden Aktivitäten, die notwendig sind, um einen
TP
29PT [Beats]
7.1.1. Realisierung der Rollen
Seite 78
Geschäftsfall zu bearbeiten. Die einzelnen Aktivitäten können organisatorisch
verteilt sein, stehen aber gewöhnlich in zeitlichen und logischen
Abhängigkeiten zueinander“ TP
30PT
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“ TP
31PT Zudem führt ein Anwendungsfall immer
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.
Geschäftsprozess: TAnlegen einer InfoObject-DokumentationT
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:
TP
30PT [Gal]
TP
31PT [Oes97]
7.1.2. Geschäftsprozess
Seite 79
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“ TP
32PT
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 notwendig, da verschiedene
Entscheidungskriterien nach Beendigung einer 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
32PT [Bal2000]
Seite 80
Abbildung 7-1: Aktivitätsdiagramm
Seite 81
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“TP
33PT
Um einen Anwendungsfall zu beschreiben, entwirft man in der
Softwaretechnik eine Anwendungsfallbeschreibung TP
34PT (siehe unten). Diese
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
benötigte Daten: alle Daten, die für die Bezeichnung des BW-
Objekts nach der Namenskonvention nötig sind
TP
33PT [Bal99]
TP
34PT [SoKo]
7.1.3. Anwendungsfälle
Seite 82
Vorbedingung: Developer möchte ein BW-Objekt anlegen
Nachbedingung im
Positivfall: (BW-Objekt ist nicht doppelt) Anwendungsfall 2 tritt
ein
Nachbedingung im
Negativfall: Optionaler Abbruch des Prozesses
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 existieren
bereits im SAP BW: Anzeige einer Liste
dieser BW-Objekte. 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
Daten:
Die technische Beschreibung
Seite 83
Vorbedingung: Anwendungsfall 1 war erfolgreich; Developer
hat entsprechende Rechte
Nachbedingung im
Positivfall:
Anwendungsfall 3 tritt ein
Nachbedingung im
Negativfall:
-
Interaktionsschritte im
Standardfall (Idealfall):
Developer füllt alle Muss-Felder aus
Developer gibt frei, indem er E-Mail sendet
Szenarios: Developer vergisst ein oder mehrere Muss-
Felder 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 BW-
Objekt 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 BW-
Objekt
Für die Auslösung
benötigte Daten:
Kurz- und Langbeschreibung (in allen Sprachen)
und betriebswirtschaftliche Beschreibung (in
Deutsch und Englisch)
Vorbedingung: Anwendungsfall 2 wurde erfolgreich ausgeführt
Nachbedingung im Anwendungsfall 4 tritt ein
Seite 84
Positivfall:
Nachbedingung im
Negativfall:
-
Interaktionsschritte im
Standardfall (Idealfall):
Customer füllt alle Muss-Felder aus
Customer gibt frei, indem er E-Mail sendet
Szenarios: Customer vergisst ein oder mehrere Muss-
Felder 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
Daten:
keine
Vorbedingung: Anwendungsfall 3 war erfolgreich
Nachbedingung im
Positivfall:
Anlage von BW- Objekt und Dokumentation
im SAP BW (FBE)
Nachbedingung im
Negativfall:
-
Interaktionsschritte im
Standardfall (Idealfall):
Supervisor gibt frei
Seite 85
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 BW-
Tabelle 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 86
(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, muss der Parameter
I_Overwrite_Mode des 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 87
• 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 88
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 89
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-Objekt-
Texten 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
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
7.7.1. Einführung und Installation
Seite 90
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-Homepage TP
35PT
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
35PT [DowTrv]
Seite 91
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 istTP
36PT
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
36PT[MsIEWeb]
7.7.2. Erklärung der Datenbank-Tabellen
Seite 92
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 FallTP
37PT.
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
37PT Der VB-Code wurde von dem Auszubildenden Holger Roedig implementiert
Seite 93
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 Online-
Dokumentation zu erhalten, muss der Anwender zuvor seinen Namen und
sein Passwort für den WebApplication-Server eingeben.
Seite 94
<asp:HyperLink id="lnkBeispiel" style="Z-INDEX: 102; LEFT: 19px; POSITION: absolute; TOP: 59px" runat="server" NavigateUrl= "Hhttp://sap-fbp.vwfsag.de:8010/sap/bw/doc/metadata/page%3dBW_O_D%26SystemID%3d FBP112%26ClassID%3dIOBJ%26ID%3d0country%26objectVersion%3dAH" Target="main">0country</asp:HyperLink>
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.
• TIntegration in das Portal:T Die Integration von .NET- Anwendungen
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 Front-
End-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 […]“TP
38PT.
TP
38PT [SAPWeav]
Seite 95
• TIntegration von TREX: T Da die Dokumentationsverwaltung ein mit
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 96
8. Schlusswort
8.1. Fazit
Zum Ende erläutere ich Vorgehensweisen, Probleme und Chancen der Ent-
stehung 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-Zu-
stand störte und welche Vorstellungen und Wünsche sie bezüglich der
Dokumentationen hatten. Bei diesen Nachforschungen traten recht unter-
schiedliche 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 Sollkonzep-
tes eine Möglichkeit gefunden werden, Daten vor Änderungen im BW in einer
Datenbank zu speichern, auf die mit einer geeigneten Umgebung und Pro-
grammiersprache für Webanwendungen zugegriffen werden kann. Von der
gewählten Plattform Microsoft .NET konnte zudem die Kommunikationsmög-
lichkeit des SAP .NET-Connectors genutzt werden, um mit dem SAP BW-
System 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 ver-
schiedenen 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-Da-
tenbank eingerichtet. Dabei wurde die Entscheidung getroffen, dass die
Daten zunächst relational und erst später als XML-Dokumente gespeichert
werden.
Seite 97
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 Doku-
mentationsverwaltung 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 Erfah-
rungen 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 wer-
den.
Seite 98
8.2. Danksagung
Ich danke allen Mitarbeitern der Volkswagen Bank und besonders den Mitar-
beitern 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 wur-
den.
Braunschweig, den
Sylvia Brink
Seite 99
I. Anhang
A Bedarfsanalyse
U Bedarfsanalyse
Dokumentenverwaltung in SAP BW Entwickler 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: UDokumentationU
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 BW-Objekten. 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 100
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 Begründung: • Zuständigkeiten sind notwendig 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 101
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 Welche?: Begründung: • nicht notwendig 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 102
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 103
• 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 Begründung: • nicht sinnvoll 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 Begründung: • bedingt notwendig • gar nicht notwendig Bemerkungen: 10. Zusätzliche Anmerkungen/ Vorschläge:
Seite 104
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 105
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 106
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 107
C Oracle-Datenbank dwown
Seite 108
D Front-End
Seite 109
Eingabemasken Daten für die Dokumentation
Metadaten Keyfigures (Kennzahlen) Characteristics (Merkmale)
(2) Sourcesystems (Quellsysteme)
(3) Characteristics (Ausprägungen)
(1) Descriptions (Beschreibungen)
Seite 110
InfoObject-Dokumentation (ShowDocumentation)
Seite 111
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 112
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 113
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 114
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 115
<CH_DEFINITION>high-level interst category</CH_DEFINITION> <CH_ANNOTATION>for privileged people </CH_ANNOTATION> </characteristic> </characteristics> </IOBJDoc> </SAPBW>
Seite 116
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 117
H Function F_CheckCreateIOBJ
FUNCTION F_CHECKCREATEIOBJ (iobj_pk_id IN NUMBER ) RETURN varchar IS --Variables intCountCHA NUMBER(2,0); intCountKYF NUMBER(2,0); descshortE Varchar(20); desclongE Varchar(50); descshortD Varchar(20); desclongD Varchar(50); descshortF Varchar(20); desclongF Varchar(50); strReturn VARCHAR(100); intCountLanguage NUMBER(2,0); intNumberLang 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 118
--***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 119
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 120
III. Literaturverzeichnis Kaptitel 1: T[VWint2-04] TVWFSAG
Organisationshandbuch der VWFSAG, Intranet der VWFSAG, 2004
Kapitel 2: T[Buc98] T Rüdiger Buck-Emden
Die Technologie das SAP R/3 Systems, Addison Wesley, 1998, ISBN 3 8273
1379 1, S.110
T[Reu04] T Reuse, Svend
Data Warehouse, 2004,
HTUhttp://www.lehrer-online.de/dyn/bin/420778-421140-2-dwh_merkblatt.pdf UTH,
16.11.2004
T [Kle04] TTKlein, Raimund,
Erklärung diverser Begriffe des SAP BW- Systems, 2004
HTUhttp://www.raimund-klein.de/index.html UTH, 15.11.2004
T[VWint1-03] T Semrau, Frank
SAP Business Information Warehouse, Intranet der VWFSAG
Dateiname: FKS BW Präsentation.ppt
T [CoWo01] T Computerwoche
Plattner: "ABAP und Java sind künftig gleichberechtigt", 2001
HTUhttp://www.computerwoche.de/index.cfm?pageid=258&artid=30848&main_id
=30848&category=157&currpage=1&type=detail&kw= UTH
Seite 121
T[CoWo04] T Computerwoche
SAP baut Partnerschaft mit Microsoft erheblich aus, 15.05.2004,
HTUhttp://www.computerwoche.de/index.cfm?pageid=254&artid=60892&type=de
tail&kw=sap%20webservices UTH, 16.11.2004
T[NetLex] T Net-Lexikon
Stichwort: Data-Warehouse, 16.11.2004
HTUhttp://www.net-lexikon.de/Data-Warehouse.htmlUTH
T[Meh03] T Mehrwald, Christian
SAP Business Information Warehouse, Architektur, Konzeption,
Implementierung
dpunkt-Verlag, 2003, ISBN 3-89864-179-1 (BW G 803)
T[See01] T Seemann, Achim et.al.
SAP Business Information Warehouse
SAP Press, 2001, ISBN 3934358411 (in Abt. I-SEB)
T[MySAP01] T Jens Krüger
Fallstudie mySAP.com, 28.01.2002
HTUhttp://www.wiwiss.fu-berlin.de/php/suhl/referate/SAP.PDF UTH, 16.11.2004
Kapitel 3:
T[SAPHlp] T SAP
Dokument als Online-Dokumentation, 2004,
HTUhttp://help.sap.com/saphelp_sem320bw/helpdata/de/5e/f1f73a11e18449e10
000000a11402f/content.htmUTH, 16.11.2004
Kapitel 4:
Seite 122
T[Wol03]T Wolf, Frank
SAP Web Application Server
dpunkt-Verlag, 2003, ISBN 3-89864-214-3 (CS J 241)
T[Pro02] T Prodise, Jeff
Entwicklerbuch Microsoft .NET
Microsoft Press, 2002, ISBN 3-87063-642-1
T [The03] T Theobald, Patrick
SAP R/3 Kommunikation mit RFC und Visual Basic
Vieweg Verlag , ISBN 3-528-05878-1
T[SAPConn02] T SAP
SAP .NET-Connector Version 1.0, 2002.
HTUhttp://www.microsoft-sap.com/docs/dotnetconnector.nov02.pdf UTH, 16.11.2004
T[Lin03] T Thomas Lindner
Oracle 9.2 XML Datenbanken, 2002/03,
HTUhttp://www.imn.htwk-leipzig.de/~kudrass/Lehrmaterial/Oberseminar/2002-
03/10.ppt UTH;
T16.11.2004
T[Ora]T Oracle Referenz HTUhttp://download-west.oracle.com/docs/cd/B10501_01/appdev.920/a96612/d_xmlge2.htmUTH
T [W3C]T World Wide Web Consotium
XML Path Language (XPath) W3C Work Draft, 29.10.2004,
HTUhttp://www.w3.org/TR/xpath20/ UTH, 16.11.2004
T [Mül]T Prof. Gerriet Müller
SQL Tutorium, Jahr unbekannt
Seite 123
HTUhttp://horatio.wiwi.uni-frankfurt.de/sql/intro.htmlUTH, 16.11.2004
T[Mo01]T Monadjemi, P.; Groth, F.
Visual Basic.net, Markt und Technik, ISBN 3-8272-6041-8, 2001, S.61
T[DowNET]T SAP
Download .NET Connector
HTUhttp://www.sap.com/services/servsuptech/smp/ UTH, 16.11.2004
T[DowJRE] TSun
Download Java Runtime Environment
HTUhttp://java.sun.com/j2se/1.4.2/download.htmlUTH, 16.11.2004
T[Mono]T Das Mono-Projekt
Offizielle Seite des Mono-Projektes (Open Source-Alternative zu MS.NET)
HTUhttp://www.mono-project.com/about/index.html UTH, 09.12.2004
T[Bri03]T Brink, Sylvia
Erstellung einer Intranetanwendung unter .NET mit Datenbankanbindung“,
Studienarbeit, FH Braunschweig/Wolfenbüttel, 2002-03, S.6
Kapitel 5:
T[Kel03] T Keller, Krüger
ABAP Objects, SAP Press, ISBN 3-934358-37-3, 2003, S.254
Kapitel 6: T[Ora]T s. Kapitel 4
Kapitel 7: T[DowTrv]T Microsoft
Seite 124
Download IE-Websteuerelemente für MS.NET
HTUhttp://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=
fac6350c-8ad6-4bca-8860-8a6ae3f64448 UTH, 09.12.2004
T[SAPWeav] T SAP
Plattform-Interoperabilität von SAP NetWeaver mit IBM Websphere und
Microsoft .NET, 2003
HTUhttp://www.sap.com/germany/media/50063160.pdf UTH, 09.12.2004
T[MsIEWeb] T Microsoft
Internet Explorer WebControls Überblick über IE-Webcontrols, 2004
HTUhttp://msdn.microsoft.com/workshop/webcontrols/overview/overview.asp UTH,
09.12.2004
T[Beats] T Beats Biblionetz
Definition des Begriffs Geschäftsprozess, 2003
HTUhttp://beat.doebe.li/bibliothek/w01327.htmlUTH, 09.12.2004
Zitiert aus: H. R: Hansen, G. Neumann im Buch HWirtschaftinformatik IH im Text
HPlanung, Entwicklung und Betrieb von InformationssystemenH (1978)
T[Bal99] T Balzert, Heide
Lehrbuch der Objektmodellierung,Spektrum Akademischer Verlag ,ISBN:
3827402859, 1999, S.62
T[Oes97] T Oesterreich, Bernd
Objektorientierte Softwareentwicklung mit der Unified Modeling Language,
ISBN 3-486-23999-6, 1997, S.87
[Gal] Galileo Netlexikon HTUhttp://www.galileocomputing.de/glossar/gp/anzeige-8502/FirstLetter-GUTH,
09.12.2004
Seite 125
T[Bal2000] T Helmut Balzert,
Lehrbuch der Softwaretechnik, Spektrum Akademischer Verlag, ISBN
3827403014, S. 335
T[SoKo] T Software-Kompetenz
Gliederung einer Anwendungsfallbeschreibung, 2001-2004
HTUhttp://www.software-kompetenz.de/?6131 UTH, 09.12.2004
Anmerkung: Internetlinks können bei Aufruf nicht mehr aktuell sein.
Seite 126
IV. Abbildungsverzeichnis
TUAbbildung 1-1: Organisationsstruktur Informatik VWFSUT ................................. 5 TUAbbildung 2-1- Produktanalyse UT .................................................................... 11 TUAbbildung 2-2: Architektur des SAP BWUT ...................................................... 13 TUAbbildung 2-3: DatenflussUT ............................................................................ 16 TUAbbildung 2-4. einfaches Bsp. einer additiven FortschreibungUT .................... 18 TUAbbildung 2-5: Star-SchemaUT ........................................................................ 19 TUAbbildung 2-6: m:n-Beziehung InfoCube-InfoObject UT .................................... 22 TUAbbildung 2-7: Beispiel einer HierarchieUT ..................................................... 23 TUAbbildung 3-1: Dokumentationen im BW UT ..................................................... 25 TUAbbildung 4-1: Baumdarstellung eines XML-DokumentsUT ............................. 33 TUAbbildung 4-2: XML-Dokument-Anzeige per XSLT UT ...................................... 37 TUAbbildung 4-3: DataGrid-BeispielUT ................................................................. 46 TUAbbildung 4-4: Aufbau der Dokumentationsverwaltung UT ............................... 49 TUAbbildung 5-1: Auswahl der SAP Proxy-KlasseUT ........................................... 51 TUAbbildung 5-2: Der NET Connector Assistent (Logon)UT ................................. 51 TUAbbildung 5-3: Der NET Connector Assistent 2 (FuBa-Auswahl)UT................. 52 TUAbbildung 5-4: SE16, Tabelle RSDIOBJTUT .................................................... 53 TUAbbildung 5-5: Funktionsbaustein RFC_READ_TABLEUT .............................. 54 TUAbbildung 5-6: DataGrid mit Tabelleninhalt UT.................................................. 57 TUAbbildung 5-7: Datenbanktabellen UT ............................................................... 59 TUAbbildung 6-1: mainIOBJ.aspx; Front-EndUT ................................................... 69 TUAbbildung 6-2: Generierung von HTML- Dokumentationen UT ......................... 70 TUAbbildung 6-3: RSD1, Anzeige des InfoObject sUT.......................................... 75 TUAbbildung 7-1: Aktivitätsdiagramm UT............................................................... 80 TUAbbildung 7-2: TreeviewUT .............................................................................. 90 TUAbbildung 7-3: Inhalt von T_Node und T_PageUT .......................................... 92 TUAbbildung 7-4: vollständige URL mit IFramesUT .............................................. 93 TUAbbildung 7-5: IFrame in der Dokumenationsverwaltung UT............................. 93
Seite 127
V. Begriffserklärungen erstellter Programmteile Oracle-Tabellen
Tabellenname Inhalt/
T_CHARACTE
RISTIC Alle Characteristics (Ausprägungen) des InfoObjects (z.B.
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
STEM alle Quellsystene (Sourcesystems), aus denen das
InfoObject Daten bezieht (Kredis, Leasis und SAS)
T_STATUS Status, in dem sich ein InfoObject befindet, z.B. von wem
es bereits freigegeben wurde und ob sich die
Dokumentation schon im SAP BW-System befindet
Seite 128
Oracle-Procedures und Functions Procedure/ Function Aufgabe
F_Check_create_iobj Überprüft vor Anlage des InfoObjects im SAP BW-
System, 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 des Trigger
Tr_iobj_language_insert ausgelöst, fügt die
Procedure für jede Sprache einen neuen Datensatz
in T_LANGUAGE ein
P_Create_Xmldocs Erstellt aus den Oracle-Tabellen T_IOBJ,
T_IOBJKYF/CHA, 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 129
einer Kennzahl (Keyfigure) nötig sind
Oracle-Triggers Trigger Aufgabe
Tr_[Tabellenname]
z.B. Tr_IOBJ
Wird vor Einfügen eines Datensatzes ausgelöst. Holt
den aktuellen Wert aus der Sequenz S_DB_Autowert
und fügt ihn in den Primary Key der Tabelle ein
Tr_IOBJ_Language_I
nsert_Rows
Wird nach Einfügen eines Datensatzes in T_IOBJ
ausgelöst. Für jede Sprache wird eine Datensatz in
T_LANGUAGE eingefügt.
SAP- Funktionsbausteine Funktionsbaustein Aufgabe
BAPI_RFC_IOBJ_C
REATE legt ein InfoObject im SAP BW-System an
RSOD_DOC_META_
CHANGE legt eine Dokumentation zu dem angegebenen BW-
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
