SAP OpenHub XML Export

Studienbereich Wirtschaft
Studiengang Wirtschaftsinformatik
XML-Export im SAP Data Warehouse

Entwicklung eines XML Exports in der OpenHub Destination
des SAP Data Warehouse
1. Projektarbeit
Im Rahmen der Prüfung zum Bachelor of Science
Verfasser: Marco Hammel
Kurs: WWI07B1
Ausbildungsbetrieb: SAP AG
Abgabedatum: 25.08.2008
Name der betrieblichen Funktion des betrieblichen Unterschrift des

Betreuers / der betrieblichen Betreuers / der betrieblichen betrieblichen Betreuers / der
Betreuerin: Betreuerin: betrieblichen Betreuerin:
Thomas Brandt Senior Develper

XML-Export im SAP DataWarehouse 25. August 2008
Eidesstattliche Erklärung:
Ich erkläre hiermit eidesstattlich, dass ich die vorliegende Arbeit selbstständig und
ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe. Aus den
benutzten Quellen direkt oder indirekt übernommene Gedanken habe ich als solche
kenntlich gemacht.
Diese Arbeit wurde bisher in gleicher oder ähnlicher Form oder auszugsweise noch
keiner anderen Prüfungsbehörde vorgelegt und auch nicht veröffentlicht.
X
Marco Hammel
Student der Wirtschaftsinformatik
marco.hammel@sap.com
1
Inhaltsverzeichnis:
Eidesstattliche Erklärung: ........................................................................................................................ 1
1. Erläuterung der Problemstellung .................................................................................................... 4
2. Allgemeine Informationen in SAP Business Intelligence und Data Warehouse.............................. 6
2.1. InfoProvider des Data Warehouse .......................................................................................... 8
2.2. Persistente Datenspeicherung im Data Warehouse ............................................................... 9
2.3. Der Datentransfer innerhalb des Data Warehouse............................................................... 10
2.4. Aufbau der OpenHub Destination im Data Warehouse ........................................................ 10
3. Extensible Markup Language in Business Applikationen .............................................................. 12
4. Entwicklung der XML-Export-Funktionalität in der OpenHub Destination ................................... 13
4.1. Analyse der Programmlogik .................................................................................................. 14
4.1.1. Analyse der Paketstruktur ............................................................................................. 14
4.1.2. Analyse von Programmablauflogik und Klassendesign ................................................. 16
4.2. Spezifikation der XML-Struktur für BI-Datenobjekte ............................................................ 18
4.3. Erstellen des Erweiterungsdesigns ........................................................................................ 18
4.4. Klassenstruktur der Klasse CL_RSB_FILE_TYPE_XML ............................................................ 19
4.5. Logik der CONVERT Methode ................................................................................................ 20
4.6. Design der grafischen Benutzeroberfläche ........................................................................... 21
4.7. Erweiterung der Benutzeroberfläche und der Menüführung ............................................... 22
5. Ausblick über die Entwicklung von Business Intelligence und Data Warehousing ....................... 22
5.1. BI in Services? ........................................................................................................................ 23
5.2. Was bringt die Zukunft den persistenten Datenobjekten? ................................................... 23
5.3. Erweiterung der XML-Export-Funktionalität in der OpenHub Destination ........................... 23
Anhang .................................................................................................................................................. 24
1. asXML-Beispiel für BI-Objekt: .................................................................................................... 24
2. Konvertierungsmethode der Klasse CL_RSB_FILE_TYPE_XML: ................................................. 27
3. Konstruktor der Klasse CL_RSB_FILE_TYPE_XML: ..................................................................... 29
4. Verwendungsdokumentation der Klasse CL_RSH_FILE_TYPE_XML:......................................... 29
Glossar: .................................................................................................................................................. 30
Literaturverzeichnis: .............................................................................................................................. 33
2
Abbildungsverzeichnis:
Abb. 1 BI und dessen Komponenten im Kontext des SAP NetWeaver (SAP AG, 2004) .......................... 6
Abb. 3 Schichten-Architektur eines Business Intelligence Systems (SAP AG, 2004) ............................... 7
Abb. 4 Die OHD als Schnittstelle zu nachgelagerten System (SAP AG, 2004) ....................................... 12
Abb. 5 Paketstruktur in SAP Netweaver ................................................................................................ 15
Abb. 6 Ausschnitt der Schnittstellenhierarchie des SXML Pakets ......................................................... 15
Abb. 7 Komprimiertes UML-Klassendiagramm Destinationsklassen, Darstellung der Lokalen
Schreibklasse ......................................................................................................................................... 16
Abb. 8 Auschnitt UML-Sequenzdiagramm ............................................................................................ 17
Abb. 9 Komprimiertes UML-Klassendiagramm der XML Konvertierungsklasse ................................... 19
Abb. 10 Methoden der Klasse CL_RSB_FILE_TYPE_XML in Darstellung der ABAP Workbench ............ 19
Abb. 11Attribute der Klasse CL_RSB_FILE_TYPE_XML in Darstellung der ABAP Workbench ............... 20
Abb. 12 Benutzeroberfläche der OHD für den Datenexport im CSV-Format........................................ 21
Abb. 13 Benutzeroberfläche der OHD für den Datenexport im XML-Format ....................................... 22
3
1. Erläuterung der Problemstellung

Betriebswirtschaftliche Entscheidungen werden schon sei geraumer Zeit nicht mehr allein dem
Instinkt, oder der persönlichen Erfahrung weniger Spezialisten überlassen. Vielmehr wird der
Entscheidungsfindungsprozess in immer stärkerer Weise mit informationstechnologischen Mitteln
auf eine möglichst starke deterministische Grundlage überführt, um eine möglichst hohe
Entscheidungsqualität zu erzielen. IT Systeme, die den damit verbundenen
Entscheidungsfindungsprozess unterstützen werden durch zwei unterschiedliche technische
Philosophien, der Datenbeschaffung unterstützt. Dem:
Online Transaction Processing (OLTP):1 Das der traditionellen Dokumentation und

Abwicklung von Geschäftsprozessen z.B. Fakturierung, Lagerbestandsverwaltung dient, diese
weisen deshalb viele relationale Beziehungen von Tabellen auf, um die benötigten Daten zu
beschaffen. Typisch ist diese Art der Datenbeschaffung in den klassischen SAP R/3 Systemen.
Online Analytical Processing (OLAP):2 ist im Gegensatz zu OLTP in seiner Datenstruktur

Multidimensional und damit für intelligente Analyse- und Reporting-Zwecke optimal. Die
Multi-Dimensionalität erlaub t die Anforderung deterministischer Analysen, “große
Datenbestände mit unterschiedlichen Fragestellungen und unterschiedlichen Blickwinkeln zu
durchleuchten, innerhalb akzeptabler Antwortzeiten [zu] erfüllen“ (Lehmann, 2001)
Die Qualität, der Auswertungen von Business Intelligence (BI)3-Systemen bekommt eine, für den
Erfolg von Unternehmen, abhängig von Produkt, Marktposition und Expansionsbestrebungen immer
größerer Bedeutung. Ein Unternehmen, das qualifiziertere, schnellere und kontrollierbarere
Entscheidungen trifft ist gegenüber seinen Mitkonkurrent im Vorteil. Bei i.d.R. immer kürzeren
Produktzyklen in vielen Märkten, kann eine Entscheidung für die Erschließung neuer Märkte vor der
Konkurrenz zu einer früheren oder besser vorbereiteten Marktpräsenz führt und einem u.U. damit
verbundenem besserem Ergebnis.
Viele Unternehmen bevorzugen es Analysen und Reports von BI-System als Dienstleistung
einzukaufen. Gründe dafür könnten eine unzureichende IT-Infrastruktur, z.B. ein ungenügender
Bestand an auswertungsfähigen Daten, das Fehlen von Experten zur Interpretation der Ergebnisse
eines BI-Systems, oder die kostenrechnerische Entscheidung, dass sich ein eigenes BI-System als für
das Unternehmen unrentabel erweist. Um dennoch nicht auf die Vorteile von BI verzichten zu
1
Siehe Glossar
2
Siehe Glossar
3
Siehe Glossar
4
müssen hat sich in diesem Bereich ein vielfältiger Dienstleistungsmarkt entwickelt, von umfassenden
Unternehmensberatung bis zum Vertrieb und der Erstellung von Betriebs- und marktwirtschaftlichen
Daten und Auswertungen. Dadurch entsteht Neben dem Wettbewerb der BI-Systeme im Bereich der
Auswertungs-Qualität und Performance auch ein anspruchsvolles Anforderungsprofil im Bereich der
Schnittstellenkompatibilität. Weshalb die Hersteller von BI-Software fortlaufend ihre Produkte an
neue Datenbank- und Formatstandards bezüglich Datenimport und Export anpassen müssen. Mit
dem kommenden SAP Netweaver4-Release 7.2, des Walldorfer Softwarehauses SAP AG soll deshalb
dem Kunden die Fähigkeit des Datenexports von BI-Daten auch im Extensible-Markup –Language
(XML)5 Format bereitgestellt werden. Bisher unterstützt das System auf Dateiebene den Export als
Comma-Separated-Value (CSV) 6-Format und als TEXT-Datei im American Standard Code for
Information Interchange (ASCII)7 kodiert. Diese Formate haben gegenüber XML den Nachteil
technische, oder semantische Informationen zu den Daten nicht in der gleichen Datei mitführen zu
können, da in diesen Formaten nur flache Daten-Hierarchien abgebildet werden können. Deshalb
besteht ein Datei-Export um Metadaten mitführen zu können in diesen Formaten aus 2 Dateien. Der
Kunde kann zwar mittels SAP fremder Anwendungen aus den beiden Dateien, von denen eine die
Attribute und die andere die zugehörigen semantischen Informationen trägt bereits eine XML
erzeugen. Das bedeutet jedoch Mehraufwand für:
Die Wartung des Fremdprogramms:
o Z.B. bei Eigenentwicklungen,
o Oder das Pflegen von neuen Format-Standards
Die Systemressourcen,
o Da die Prozesskette einen weiteren Schritt umfasst und
o Die Prozesskette systemübergreifend konfiguriert werden muss.
Ein ebenfalls wichtiger Aspekt ist der Marketingmehrwert, der durch die erweiterte
Exportfunktionalität entsteht und das Produkt für Neukunden interessanter machen könnte.
Aufgabe war es die Funktionalität der OpenHub Destination (OHD)8, einem Werkzeug des SAP Data
Warehouse (DWH)9-Systems, um die Funktionalität des XML-Exports auf Dateiebene zu erweitern.
4
Siehe Glossar
5
Siehe Glossar
6
Siehe Glossar
7
Siehe Glossar
8
Siehe Glossar
9
Siehe Glossar
5
Dafür musste ein Entwicklungszyklus zur Erweiterung der Back- und Frontendfunktionalität der OHD
durchgeführt werden, mit dem Ziel dem Kunden die Funktionalität auf UserInterface (UI) -Ebene in
vertrautem Umfeld und möglichst einfacher und klarer Nutzerführung zur Verfügung zu stellen. Das
Backend soll dabei die im Kapitel 2.4. beschriebenen technischen Anforderungen der OHD erfüllen.
2. Allgemeine Informationen in SAP Business Intelligence und Data

Warehouse
Der SAP Netweaver, die Integrations- und Anwendungsplattform für SAP-Lösungen beinhaltet im
Bereich der Information Integration die SAP Business Intelligence (BI) Lösung. Diese ist eine
komplette BI-Plattform mit Data Warehousing Funktionalität. Das SAP BI betreibt seine
Datenmodellierung und Beschaffung mittels OLAP.
Abb. 1 BI und dessen Komponenten im Kontext des SAP NetWeaver (SAP AG, 2004)
Das Data Warehouse (DWH) kann als Datenverwaltungssystem, bzw. Datenlager des BI-System
bezeichnet werden. Es hat die Aufgabe Daten in folgender Rheinfolge:
aus verschiedenen Quellsystemen zu integrieren,
6
in konsistente Formate zu transformieren,
zu konsolidieren,
zu bereinigen,
physikalisch zu speichern,
zu verteilen,
den Werkzeugen der BI-Suite zur Verfügung zu stellen.
Grundsätzlich beruht die Funktion eines DWH auf der in der folgenden Abbildung dargestellten
klassischen Schichten-Architektur der BI:
Abb. 2 Schichten-Architektur eines Business Intelligence Systems (SAP AG, 2004)
In dieser allgemeinen Darstellung ist das DWH als integrierter Bestandteil der Business Intelligence zu
betrachten. Der Datenfluss ist hier von unten nach oben nachzuvollziehen.
1. Aus einer Datenquelle, z.B. den Daten eines Produktivsystems werden Daten in persistente
Speicher kopiert.
2. Diese persistent gehaltenen Daten können in ein DWH übergeben und dort OLAP spezifisch
aufbereitet werden, oder an den Operational Data Store überführt werden. Dort bleiben sie
weiter in Form flacher transparenter Tabellen. Dieser wiederum kann seine Daten ebenfalls
in das DWH laden, oder Queries auf seiner Tabelle ausführen lassen und das Ergebnis
ausgeben.
3. Der Data Marts10, der in dieser Darstellung die eigentlichen BI-Logik zur Verfügung stellt,
erlaubt die im DWH modellierten Daten mittels mathematisch aufwendiger Berechnungen
10
Siehe Glossar
7
auf unterschiedliche Probleme und Fragestellungen hin zu untersuchen und die Ergebnisse
auszugeben.
Der hier beschriebene Aufbau entspricht dabei nicht in Gänze der Architektur des SAP Netweaver BI.
So übernimmt das SAP BW, was dem DWH entspricht alleinig, die Verwaltung von persistenten
Datenobjekten, bzw. der Export aus dem BI.
2.1. InfoProvider des Data Warehouse

Der BI-Suite werden die Daten des DWH-Systems in Form von InfoProvidern 11zur Verfügung gestellt.
Infoprovider sind die BI Objekttypen, in die aus persistenten Speichersystemen Daten geladen
werden können bzw. die Sichten auf diese Daten repräsentieren. Die dem BI zugrundeliegenden
OLAP Beschaffung erlaubt diesbezüglich eine mehrdimensionale Datenmodellierung, die
hierarchisch, oder z.B. im Sternschema aufgebaut sein kann. Das DWH stellt für die
Datenmodellierung folgende Objektetypen zur Verfügung, diese lassen sich technisch, durch die
Eigenschaft differenzieren, ob sie eine physische Datenablage repräsentieren, oder eine virtuelle
Datensicht.
Zu den Vertretern, die eine physische Datenablage darstellen zählen:
- InfoCube: stellt einen geschlossenen Datenbestand eines betriebswirtschaftlichen Bereichs

dar. Er ergibt sich aus einer zu modellierenden Menge von relationalen Tabellen, die nach
Sternschema mehrdimensional zusammengestellt werden können. Dies wird durch die
Verwendung einer Faktentabelle realisiert, die alle Kennzahlen z.B. Umsatz enthält, sowie
mehrere kleiner Dimensionstabellen, in denen die entsprechenden Merkmale z.B.
Hauswährung abgelegt sind. Diese Tabellen sind über Schlüssel miteinander verbunden. Bei
einer Selektion bestimmter Werte einer Faktentabelle, stehen somit direkt, die benötigten
Merkmale zur Verfügung.
- DataStore-Objekt: beschreibt einen konsolidierten Datenbestand aus mindestens einer

InfoSource, also einer DataSource oder PSA. Im Gegensatz zum InfoCube repräsentiert das
DataStore-Objekt seine Daten als flache, transparente Datenbanktabelle, die mit
Schlüsselfeldern versehen werden kann.
- InfoObject (Attribute oder Texte): sind betriebswirtschaftliche Auswertungsobjekte, die aus

technischen Merkmalen wie z.B. einer Requestnummer und betriebswirtschaftlichen
Merkmalen, wie Kennzahlen, Einheiten und Zeitmerkmalen aufgebaut werden (z.B.
Kundennummer). Sie können als die im betriebswirtschaftlichen Sinne am stärksten
atomisierte Sicht auf Daten eines DWH-Systems bezeichnet werden, da sie genau ein
11
Siehe Glossar
8
betriebswirtschaftliches Merkmal repräsentieren. Typische InfoObject´s repräsentieren z.B.

Merkmale wie „Kunde“, oder „Umsatz.
Virtuelle Datensichten können durch
- InfoSet: repräsentiert eine semantische Schicht über den oben genannten Infoprovidern, um
Berichte auf diesen Objekten zu erstellen bzw. auf deren Joins. InfoSets sind die
Infoprovider, die vom Query Designer, einem Werkzeug der BI-Suite verwendet werden
können um Queries aus BI-spezifischer Datensicht erstellen zu können.
- Multiprovider: repräsentieren eine Report-spezifische Sicht auf andere Infoprovider, die

durch eine Union-Operation zusammengefasst werden.
- Virtualprovider: repräsentiert, wie der Multiprovider eine Report-spezifische Sicht auf in

diesem Fall genau einen Infoprovider. Der Virtualprovider verfügt dabei über die Fähigkeit
auch auf Daten außerhalb des BI-Systems zugreifen zu können. Grundsätzlich erfolgt der
Zugriff nur in lesender Form, mit einem Direktzugriff auf die Quelldaten.
dargestellt werden.
2.2. Persistente Datenspeicherung im Data Warehouse

Als typisches Merkmal eines BI-Systems fungiert das DWH neben seiner Datenmodellierung auch als
redundanter Speicher BI-relevanter Daten aus den Produktiv-, oder Fremdsystemen, die zu einem
definierten Zeitpunkt geladen werden. Dies ist üblich um einen für die Auswertungen im BI technisch
und betriebswirtschaftlich konsistenten Datenbestand verwenden zu können. Nach dem Laden eines
Datenbestandes aus einer beliebigen Quelle, stehen im DWH zwei Speichertypen zur Verfügung:
Die Data Source (DS)12, die dem BI in Folge die Daten bereits als betriebswirtschaftliche
Einheit zur Verfügung stellt z.B. selektiert in Bewegungs-, oder Stammdaten. Die
Analysewerkzeuge der BI-Suite erlauben es als Besonderheit der DS bereits bestimmte
Sichten auf ein DS-Objekt anzulegen und auszuführen. Dies erlaubt es weniger komplexe
Entscheidungsprozesse schneller mit Metadaten zu unterstützen, ohne das eine
aufwendigere Modellierung notwendig würde
Oder in ein Persistent Staging Area (PSA)13:, das ein unverändertes Abbild der Quelldaten im
BI in einer transparenten relationalen Datenbank anlegt, aber keine betriebswirtschaftliche
Logik pflegt.
12
Siehe Glossar
13
Siehe Glossar
9
Diese Datenobjekte sind Ausgangpunkt für die Modellierung von Infoprovidern des DWH.
2.3. Der Datentransfer innerhalb des Data Warehouse

Für den Datentransport in das DWH, innerhalb von Datenobjekten und aus dem DWH, wird ein
Standardisierter Prozess, der Daten-Transfer-Prozess (DTP)14 verwendet. Dieser Transportiert die BI-
Daten von beliebigen Quell- in Zielobjekt des BI, wobei ein Infoprovider grundsätzlich beides
repräsentieren kann. Um einen DTP durchzuführen muss eine Transformation definiert werden, die
Mapping und Konvertierung als Regel für den DTP deklariert.
Ein DTP kann sowohl manuell, oder in Prozessketten ausgeführt werden. So können Infoprovidern
erzeugten und in Zusammenspiel mit den Analyse Werkzeugen der BI-Suite, Analysen durchgeführt
und Reports erstellt, bzw. neu-, oder remodelliert werden, oder die Daten in unterschiedlichen
Darstellung mittels in Nachgelagerte Systeme exportiert werden. Den Export übernimmt dabei die
OpenHub Destination (OHD), die als Bestandteil des DWH die Daten des BI-Systems auf
unterschiedliche Zielsysteme verteilen kann.
2.4. Aufbau der OpenHub Destination im Data Warehouse

Die OHD bietet dem Kunden die Möglichkeit eine Schnittstelle auf beliebige Zielsysteme zu
konfigurieren. Technische Anforderungen an dieses Werkzeug können wie folgt formuliert werden:
Hohe Performance des Extraktionsprozesses,
Bei niedrigem Ressourcenverbrauch
Geringer Fehlerrate
Und hoher Fehleridentifikationsrate
Variabler Konfigurationsfähigkeit
Mit Fähigkeit zur Stapelverarbeitung
Der Konvertierungsfähigkeit von Daten und Datenobjekten in unterschiedliche Formate
Sie unterstützt dabei den Export in Datenbanken, Dateien und in Fremdanwendungen, z.B. ist die
Integration in Anwendungen des BI-Spezialisten Business Objects geplant. Die sich daraus
ergebenden möglichen technischen Zielsysteme sind Datenbankserver, Applikationsserver und
Workstations. Die OHD beherrscht dabei die Extraktion aller BI-Objekttypen, mit Ausnahme von
DataSources, die in Berücksichtigung der Schichten-Architektur und der stark eingeschränkten
14
Siehe Glossar
10
Modellierungsfähigkeit auch nicht als wertige BI-Objekt bezeichnet werden können (siehe Abb. 3).
Für die Extraktion von BI-Daten in Dateien stehen bis dato die Datei- Formate:
Als Kommaseparierte Werte in csv Dateien
Als ASCII Codierung in txt Dateien
Zur Verfügung.
Um semantische Informationen in diesen flachen Dateiformaten mitführen zu können, wird eine

weitere Datei erzeugt, die die Metainformationen enthält. Syntaktisch werden die Informationen
beider Dateien durch den technischen Namen der jeweilig enthaltenen InfoObjecte verbunden. Als
neue Funktionalität wird es wie in Kapitel 4 beschrieben im Netweaver 7.2 Release die Möglichkeit
zum XML Export von Bi-Objekten. Dieser soll in 2 Varianten angeboten werden, als:
ABAP Serialization XML (asXML ): ist das standardmäßig verwendete SAP XML-Format, das für
den Datenaustausch zwischen SAP- und Fremdsystemen in beide Richtungen optimiert ist.
binary ABAP Serialization XML (basXML ): ist eine SAP interne Binär-Variante der asXML. Sie
kann nur innerhalb des SAP-System-Umfeldes verwendet werden, bringt aber durch Binär-
und Strukturkomprimierung, enorme Performance- und Speichervorteile gegenüber anderen
XML Darstellungen.
Weiter Informationen zu den SAP XML Varianten werden in Kapitel 3.1. näher erlautert.
Die OHD unterstützt für alle Zielsysteme 2 unterschiedliche Extraktionsmodi. Den
Fullextraktionsmodus: der den gesamten Datenbestand aus dem DWH nach der Erst-
Extraktion erneut exportiert und die bestehenden Quelldaten im Zielsystem überschreibt. Er
ist insbesondere für kleine Datenbestände mit hoher Volatilität geeignet.
Deltaextraktionsmodus: führt nur eine Aktualisierung geänderter Daten durch. Er hat Vorteile
bezüglich Ressourcenverbrauch und Performance bei großen Datenbeständen mit niedriger
Volatilität.
Typisch für eine Deltaextraktion sind z.B. Kundenstammdaten, monatliche Umsatzauswertungen sind
i.d.R. typisch für eine Fullextraktion. Gewährleistet wird diese Funktionalität durch eine interne
Versionsverwaltung, die für jede durchgeführte Extraktion versionsspezifisch einen technischen
Request hinterlegt, der aus dem parallel zum Extraktionsprozess ablaufenden Monitoring erstellt
wird.
11
Die OHD löst im Kontext des DWH ältere Werkzeuge, wie den InfoSpoke ab. Da sie mehr
Möglichkeiten bietet und die oben erwähnten technischen Anforderungen besser erfüllt. Sie gliedert
sich in das DWH Funktional an selber Position der Schichten Architektur des DWH ein:
Abb. 3 Die OHD als Schnittstelle zu nachgelagerten System (SAP AG, 2004)
3. Extensible Markup Language in Business Applikationen

XML dient in ihren verschiedenen Anwendungen als Sprache, die zur Erstellung von Dokumenten und
Protokollen dient, die der Maschinenkommunikation dient. Die Aussage, „XML ist eine Metasprache,
die insbesondere der Entwicklung von spezifischen Markierungssprachen dient.“ (Reibold, 2003, S.
19) ist eine abstraktere Beschreibung im Bezug auf den Anwendungsbereich für XML. Mittlerweile
gibt es über 50 verschieden XML-Anwendungen, hier ein paar der bekanntesten Anwendungen:
IMPP (Instant Messaging and Presence Protocol): zum Austausch von Messaging Daten
SyncML (Synchronisation Markup Language): verwendet für die Gerätesynchronisation
XHTML (eXtensible HyperText Markup Language): Erweiterungsfähiger HTML-Nachfolger
(Reibold, 2003, S. 20/21)
XML ist:
mit seinem generischen Datenmodel, die sich in Elemente und Attribute in einer
Baumstruktur aufgeteilt repräsentiert.
Mit seiner generischen Syntax als Markierungssprache
Ein generisches Datenstrukturkonzept für Programmiersprachen z.B. mit dem Document

Object Model (DOM), das als „platform- and language-neutral interface that will allow
12
programs and scripts to dynamically access and update the content, structure and style of
documents“ (World Wide Web Consortium) definiert wurde.
Damit ist XML eine weitverbreitet offene Basis für Standards und Tools zum:
Parsen
Typisieren und Validieren
Abfragen und Transformieren
Von Dokumenten und Protokollen. Aus diesen Eigenschaften ergeben sich für Unternehmen durch
die Nutzung von XML folgende Vorteile. XML ist:
Leicht zu erweitern, flexibel und dabei persistent
Kombiniert heterogene Daten aus Framework und Anwendung
Plattformunabhängig
Ein offenes Kommunikationsformat
Insbesondere die Plattformunabhängigkeit und die leichte Erweiterbarkeit sind für Unternehmen
wichtige Aspekte. Während ein Privatperson für die Erstellung einer Webpräsenz i.d.R. mit
klassischer HTML-Funktionalität ausreichende Möglichkeiten zur Verfügung hat, wäre die Erstellung
und Verwaltung einer angemessenen Webpräsenz mit ECommerce-Funktionalität in HTML zu
aufwändig und im Ergebnis zu statisch. Mit diesem Anforderungsprofil, das an XML gestellt wird
ergeben sich auch Nachteile. So leiden viel in XML Dargestellt Daten bezüglich ihrer Lese- und
Schreibbereitschaft unter erheblichen Performanceproblemen, durch oft sehr tiefe
Verschachtelungen der Datenebene in der Dokumentstruktur. Auch hat sich ein gewisser Wildwuchs
an XML-Schemata entwickelt, weshalb in Business to Business Kommunikation über XML i.d.R.
geparst werden muss, um in unternehmensinternen Anwendungen verwendet werden zu können.
4. Entwicklung der XML-Export-Funktionalität in der OpenHub

Destination
Wie in der Abteilung üblich wurde die Entwicklung nach dem Verfahren der Wasserfallmethode
durchgeführt. In den projektspezifischen Aufgabenbereich fielen dabei, Aspekte der Spezifikation, die
Erstellung eines Designs, die Implementierung der Programmlogik und des UI, sowie manuelle Tests.
Es wurde ein Anforderungsprofil vorgegeben, das sich wie folgt formulieren lässt. Die Entwicklung
soll im DWH dem Kunden erlauben eine OHD so zu konfigurieren, dass er BI-Daten im Rahmen der
technischen Einschränkungen einer OHD im asXML, basXML, mit der Option auf eine Erweiterung
zum Anwenden kundenspezifischer XSLTs auf die BI-Daten konfigurieren und den Export durchführen
kann. Zu berücksichtigen sind hierbei folgende technischen-:
Die Funktion muss alle BI-Datenobjekte unterstützen, die auch die ODH unterstützt.
Sie soll in einer XML-Datei Metadaten und BI-Daten strukturiert darstellen.
13
Sie soll möglichst in den meisten Fällen Performancevorteile gegenüber den bisherigen
Dateiexporten bringen, mindestens jedoch keine Nachteile.
Die Funktionalität soll dabei im technischen Sinne möglichst einfach zu erweitern sein und
geringer bis keiner Wartung bei Änderungen, oder Erweiterungen der zu verwendeten
Standardformate asXML und basXML bedürfen.
Die Implementierung soll sich dabei in das bestehende Design der OHD möglichst harmonisch
integrieren. (Architekturneutral)
und Benutzeraspekte:
Die Bedienung über das User Interface soll in das bestehende Design integriert werden und
dem Nutzer alle notwendigen Informationen kontextabhängig zu Verfügung stellen.
Die Menüführung soll sich dabei möglichst eindeutig und unmissverständlich präsentieren.
Also einen hohen Grad an Useability aufweisen.
4.1. Analyse der Programmlogik

Aus den technischen Anforderungen ergibt sich die Aufgabenstellung das Design und die bestehende
Implementierung für die Dateiextraktions-Funktionalität der OHD zu analysieren. Wie in Kapitel
beschrieben, werden für die Datenkonvertierung in asXML und basXML Klassen aus dem Paket SXML
in SAP Netweaver benötigt.
4.1.1. Analyse der Paketstruktur

Mit der Einführung objektorientierter Techniken in ABAP entstand auch ein neues Paketkonzept, das
die Ansprüche einer objektorientierten Programmmodellierung erfüllen sollte. Dem Entwickler
stehen nun Möglichkeiten der Paketkapselung und Paket-Schnittstelledefinition zu Verfügung, die in
einem hierarchischen Paketkonzept wie das Beispiel der OHD zeigt zu verwenden sind.
Die gesamte Backendfunktionalität der OHD ist in einem nicht gekapselten Paket untergebracht mit
der Bezeichnung RSB untergebracht, getrennt vom Frontend, das seinerseits im Paket RSB_GUI
implementiert ist. Um die beschriebene Funktionalität des XSLT-Prozessors im SAP Netweaver
verwenden zu können, muss eine bisher noch nicht implementierte Paketschnittstelle des schwach
gekapselten Basispaketes SXML zur Schnittstellenverwaltung von RSB hinzugefügt werden. Schwach
gekapselt meint, dass das Paket auch eine Schnittstelle zur Verfügung stellt, die den Zugriff auf alle
Klassen innerhalb des Paketes gestattet. Voraussetzung für die Übernahme der Basisschnittstelle ist
im ABAP Paketkonzept, dass das Schnittstellen nutzende und bereitstellende Paket hierarchisch auf
derselben Ebene in der Paketstruktur des SAP Netweaver gepflegt werden müssen. Die folgende
Abbildung beschreibt, dass beide Pakete eine Ebene unterhalb ihrer jeweiligen Strukturpakete zu
finden sind und somit die Schnittstelle implementiert werden kann.
14
Abb. 4 Paketstruktur in SAP Netweaver
Über die Paketschnittstelle kann nun entsprechend der Schnittstellenbeschränkung auf die Klassen
des SXML Pakets zugegriffen werden. Um die Funktionalität der Klasse CL_SXML_WRITER, die eine
Methode zum erstellen von basXML Dateien enthält verwenden zu können, musste die Schnittstelle
SXML_CORE verwendet werden. Diese Schnittstelle ist in der Schnittstellenhierarchie des SXML
Pakets wie folgt angesiedelt:
Abb. 5 Ausschnitt der Schnittstellenhierarchie des SXML Pakets
Die Schnittstellenimplementierung kann im SAP Netweaver nur von Personen durchgeführt werden,
die im Berechtigungskonzept die Rolle eines Architekten inne haben. Sie wurde nach Anfrage an den
Architekten der Abteilung von diesem in das RSB Paket implementiert.
15
4.1.2. Analyse von Programmablauflogik und Klassendesign

Nach der Erweiterung der Paketschnittstelle waren nun das Design und die Implementierung der
bestehenden Dateiextraktionsprozesse für die CSV und ASCII zu betrachten. Als Entwicklung neuerer
Generation mit Netweaver Release 7.1 ist die OHD durchgehend objektorientiert designed und
implementiert worden. Somit kann Ablauf und Struktur des Programms mit der Hilfe der Unified
Modelling Language (UML)15 Elemente Sequenz und Klassendiagramm anschaulich dargestellt
werden. Das Klassendiagramm soll einen Ausschnitt über die Klassenstruktur der für die
Dateierzeugung verantwortlichen Klassen zur Verfügung stellen:
Abb. 6 Komprimiertes UML-Klassendiagramm Destinationsklassen, Darstellung der Lokalen Schreibklasse
Wie im folgenden UML-Sequenzdiagramm ersichtlich, wird in der Methode Receive_Data, oder

received des Objekts einer jeweiligen Tochterklasse von CL_RSB_FILE_GENERAL eine Variable vom
Typ der abstrakten Klasse CL_RSB_FILE_TYPE deklariert. Die Tochterklasse, die zur Objekterzeugung
verwendet wird hängt dabei vom gewünschten Zielsystem, wie Workstation, Applikationsserver,
oder Fileserver der OHD ab. Diese Mutterklasse hat den Methodenrumpf der Methode CONVERT
implementiert, die in den jeweiligen Tochterklassen implementiert, die Fähigkeit der zeilenweisen
Konvertierung in die jeweilige Datenkodierung zur Verfügung stellt. Die in ABAP fehlende Eigenschaft
der Mehrfachvererbung erfordert hier einen größeren Implementierungsaufwand und zu
Coderedundanz. Mithilfe der deklarierten Referenzvariablen, wird nun je nach gewünschtem
Extraktionstyp ein Objekt der entsprechenden Tochterklasse erzeugt:
15
Siehe Glossar
16
Abb. 7 Auschnitt UML-Sequenzdiagramm
Daraufhin werden die Daten der BI-Datentabelle zeilenweise abhängig von der Tabellengröße 1 bis n
mal als Importparameter an die jeweilige CONVERT Methode übergeben. Diese exportiert die
jeweilige Tabellenzeile, entsprechend der im erzeugten Objekt vorliegenden Implementierung,
konvertiert in die jeweilige Datencodierung als Zeichenfolge vom Typ ABAP Datentyp CHAR
(Character). Diese Zeichenfolge wird im Anschluss mit dem Attribut des Objekts einer dem Zielsystem
entsprechenden Tochterklasse der Klasse CL_RSB_FILE_GENERAL konkludiert (siehe Anhang). Dieses
Attribut wird in Folge für den Schreibprozess in die Datei verwendet.
Im Unterschied zu den bisherigen Dateiexporten in CSV und ASCII soll für den XML-Export nur eine
Datei erzeugt werden, die sowohl Metadaten, als auch BI-Daten enthält. Somit darf der Prozess der
Metadaten-Datei-Erzeugung für den Fall des XML-Exports nicht durchgeführt werden. Stattdessen
müssen die benötigten Metadaten in den oben beschriebenen Programmablaufausschnitt integriert
und von der für die XML-Zeichenketten-Konvertierung zuständigen Methode verarbeitet werden
können. Die entsprechende Tabelle steht als Attribut des Objekts der Klasse CL_RSB_FILE_GENERAL
und somit deren Tochterklassen zu Verfügung.
Als Folge, der Anforderung für niedrigen Wartungsaufwand bezüglich Änderungen der Standard-
XML-Formate wurde deutlich, dass sich die Methodenlogik nicht konkludent zu der vorhandenen
Logik implementieren ließe. Zwar ließen sich die BI-Daten auch strukturweise in das asXML-Format
17
überführen, jedoch müsste die erzeugt Zeichenfolge noch editiert werden, da sonst um jede einzelne
Zeichenkette durch Dokumenten Anfangs- und Endtags gerahmt wäre. Die meisten XML-Reader
könnten in Folge dessen die Dokumentstruktur nicht mehr lesen, und würden die erzeugte Datei
nicht als valides XML akzeptieren.
4.2. Spezifikation der XML-Struktur für BI-Datenobjekte

Als weiter Überlegung, wie ein XML-Export von BI-Daten aus dem DWH realisiert werden kann muss
festgelegt werden, welche Eigenschaften, neben dem mitführen von Metadaten das XML Dokument
noch erfüllen soll. Grundsätzlich ist die Dokumentstruktur durch die Standard XSLT für die asXML-
Konvertierung vorgegeben. Zu überlegen ist jedoch, in welcher Form die Metadaten im Dokument
erscheinen sollen. Folgende Varianten kommen dabei in Frage:
1. Die Metadaten werden am Kopf, oder
2. Am Fuß des XML Dokuments logisch separiert.
3. Direkt in die Darstellung der jeweiligen BI-Datenobjekte integriert.
Als Ergebnis dieser Überlegung wurde Variante eins gewählt (siehe Anhang). Im Gegensatz zur
Variante 2 bietet sie den Vorteil, das bei der lesenden Auswertung eines solchen Dokuments i.d.R.
Nach dem Top-Down Verfahren vorgegangen wird. Es ist in vielen Fällen für die Datenkonsistenz,
Performance und Anwendungssicherheit entscheidend, erst die technischen Eigenschaften der BI-
Objekte zu kennen, bevor diese z.B. in Fremdanwendungen geladen werden. Gründe dafür sind eine
effizientere Speichernutzung und die Vermeidung von teilweise aufwendigen Datenanalyse
verfahren.
Variante 3 würde diesen Überlegungen zwar auch Rechnung tragen. Hat aber gegenüber Variante 1
entscheidenden Nachteile bezüglich Speichereffizienz, Schreibperformance und
Implementierungsaufwand. Gründe hierfür sind:
Die um mindestens eine Ebene tiefer zu schachtelnde XML-Struktur.
Ein aufwendiges Mapping der Metadaten und BI-Datentabelle zu einem konsistenten

Datenobjekt.
Die bei mehrmaligen vorkommen eines BI-Datenobjekts gleichen Typs auftretende

Redundanz von Metadateninformation.
4.3. Erstellen des Erweiterungsdesigns

Aufgrund der an das Design gerichteten Anforderungen und den Ergebnissen der Programm- und
Designanalyse der OHD, wurde entschieden eine neue Klasse im Paket RSB mit der Bezeichnung
CL_RSB_FILE_TYPE_XML zu implementieren. Diese sollte wie die Klassen CL_RSB_FILE_TYPE_ASCII
und CL_RSB_FILE_TYPE_CSV aus der abstrakten Klasse CL_RSB_FILE_TYPE erben:
18
Abb. 8 Komprimiertes UML-Klassendiagramm der XML Konvertierungsklasse
Diese Entscheidung bedeutet einen minimal invasiven Eingriff in den bestehenden Quellecode. So
kann in der Methode Receive_Data der Methodenaufruf für Konvertierung unverändert bestehen
bleiben. Es muss lediglich fallabhängig der Konstruktor der neuen Klasse aufgerufen werden. Sonstige
Eingriffe in die bestehende Programmlogik beschränken sich auf das Erweitern eines Datentyps
(siehe Anhang), der zur Programmsteuerung notwendige Daten aus dem UI transportiert und einer
Fallklausulierung für den Methodenaufruf der AFTER_EXTRACTION, die die Metadatendatei schreibt,
welche beim XML-Export wie beschrieben obsolet wird.
4.4. Klassenstruktur der Klasse CL_RSB_FILE_TYPE_XML

Die UML-Darstellung der Klasse hat hierbei folgendes Erscheinungsbild:
Abb. 9 Methoden der Klasse CL_RSB_FILE_TYPE_XML in Darstellung der ABAP Workbench
Neben, der für die eigentliche Konvertierung zuständige CONVERT Methode und dem Konstruktor,
der für die Wertübergabe der aufgeführten Attribute zuständig ist, wird die Behandlung, oder die
Weiterleitung möglicher Ausnahmen der Transformation durch die Methode HANDLE_TRAN_EXC
durchgeführt. Ansonsten sind noch einige GET und SET Methoden implementiert, die einer möglichst
sauberen Kapselung und dem damit verbundenen Einschränkung der Sichtbarkeit der Attribute
führen soll. Die Attribute der Klasse sind folgendermaßen implementiert:
19
Abb. 10Attribute der Klasse CL_RSB_FILE_TYPE_XML in Darstellung der ABAP Workbench
Das private Attribut P_T_FIELD repräsentiert als interne Tabelle die Metainformationen der
BI-Objekte, es ist bereits in der Oberklasse CL_RSB_FILE_TYPE implementiert.
Das geschützte Attribut O_R_TABLEDESCR repräsentiert eine Referenz auf spezielles ABAP
Laufzeitanalyseobjekt, den sogenannten Run Time Type Service (RTTS)16. Die
Implementierung dieses Attribut trägt dem in Kapitel 4.2 beschriebenen XML-
Validitätsproblem Rechnung. Um dieses Problem zu lösen, müssen die in die CONVERT
Methode übergebenen, generisch zu behandelnden Strukturen zu einer Tabelle 1 bis n mal
zusammengeführt werden. Diese kann von der Konvertierungstransformation in valides,
zusammenhängend strukturiertes asXML-Format konvertiert werde. Um eine Tabelle bei
Programmlaufzeit erzeugen zu können, muss der Typ ihrer Strukturzeilen und die Länge der
Tabelle bekannt sein. Diese Information kann mittels eines RTTS Objekts ermittelt werden
und damit bei Programmlaufzeit eine Tabelle korrekten Typs erzeugt werden. Diese Tabelle
muss im Quellcode entsprechend generisch behandelt werden.
Das geschützte Attribut O_R_DATATAB vom generischen Datentyp DATA erfüllt die Aufgabe
den Arbeitsspeicherbereich der internen Tabelle entsprechend über den Methodenaufruf
hinaus zu referenzieren.
Das private Attribut P_FILE_OPERATOR repräsentiert einen Selektionswert, der entsprechend

der gewünschten Eingabe die entsprechende Transformation, bzw. optional das Konvertieren
der erzeugten asXML Zeichenkette in basXML bewirkt.
Das private Attribut P_CALL_CONVERT_COUNT dient als Vergleichswert mit der aus dem
RTTS gewonnen Information über die Tabellenlänge der BI-Datentabelle. Mittels eines
booleschen Vergleichsoperators wird hiermit entschieden, ob die Tabelle vollständig
eingelesen wurde, und Konvertiert werden kann.
Das private Attribut P_TRANID bestimmt, welche Konvertierung beim Aufruf der
Transformation durchgeführt werden soll. Die Transformation ist dabei in der Lage
unterschiedliche XSLTs für die Konvertierung anzuwenden.
4.5. Logik der CONVERT Methode

Bei der Implementierung der Logik der CONVERT Methode bestand die Herausforderung in Anspruch
eine möglichst generische Funktionalität bereitstellen zu wollen. Die Methode sollte in der Lage sein
aus jedem Strukturtyp, den sie übergeben bekommt eine Tabelle im Arbeitsspeicher zu referenzieren
und sobald alle Zeile eingelesen sind, diese an die Konvertierungstransformation zu übergeben und
16
Siehe Glossar
20
ggf. in ein binäres Format umzuwandeln. Für diese Aufgabe wurde eine spezielle ABAP OO-Technik
eingesetzt, Feldsymbole17. Sie sind ein „Symbolischer Name für ein Datenobjekt, dem zur Laufzeit
konkrete Speicherbereiche zugewiesen werden können. Ein Feldsymbol kann stellvertretend für
Datenobjekte an Operandenpositionen verwendet werden“. Die Fähigkeit, dass ihnen währen der
Programmlaufzeit Speicherbereiche zugwiesen werden können, und sie generisch deklariert werden
können.
Im Grundsatz lässt sich der Quellcode der Methode in zwei logische Bestandteile gliedern. Der Teil,
der ausgeführt wird um aus den importierten Strukturzeilen eine Tabelle zu erstellen (Zeile 13 bis 25)
und die eigentliche Konvertierung der Datentabelle in XML mit dem Export der Zeichenkette in die
Methode RECEIVE_DATA. Würde die zu exportierende Datenmenge nur ein BI-Datenobjekt
umfassen, wäre die Verzweigung der Methode obsolet.
Der Aufruf der Transformation erlaubt, mehr als einen Parameter zu übergeben, je nach Rheinfolge
werden die entsprechenden Daten durch Verwendung der übergebenen XSLT Konvertiert und das
Ergebnis im Datentyp der Zielvariable zurückgegeben (Zeile 52 bis 55).
4.6. Design der grafischen Benutzeroberfläche

Um die Anforderungen der Benutzbarkeit aus Kapitel … zu erfüllen, bedarf es einer Analyse der
bestehenden Menüführung. Diese präsentiert sich wie folgt:
Abb. 11 Benutzeroberfläche der OHD für den Datenexport im CSV-Format
Der Nutzer soll Top-Down durch das Menü geführt werden und dabei strukturiert gemäß der
vorhergehenden Entscheidung kontextabhängig und dynamisch die Informationen zu Verfügung
gestellt bekommen. Es sollen ausschließlich die als relevant zu erachten Einstellungen angezeigt
werden um programmkritisch und falsche Einstellungen des Nutzers im Voraus möglichst
auszuschließen und um eine Informationsüberflutung zu vermeiden. Dies erfordert, dass
Nutzereingaben soweit wie möglich vorgegeben sind bzw. initialisiert sind. Wie z.B. der Name des
Verzeichnisses, oder das zu verwendende Trennzeichen. Die verwendete Technik für das erstellen
der grafischen Benutzeroberfläche ist ABAP-Dynpro. Diese prozedurale Technik stellt dem Entwickler
vorgegebene Oberflächenelemente für die Modellierung seiner Benutzeroberfläche zur Verfügung,
die durch Verarbeitung von zugewiesen Benutzerinteraktionen in einer Ablauflogik gesteuert werden
können.
17
Siehe Glossar
21
4.7. Erweiterung der Benutzeroberfläche und der Menüführung

Unter der Berücksichtigung der Einschränkungen die mit der Nutzung dieser Technik z.B. im Bezug
auf Kaskadierung, Elementmodellierung, Interaktivität und Animierung als prozedurale
Oberflächentechnik verbunden sind, wurde eine Oberfläche für den XML-Export wie folgt konzipiert:
Abb. 12 Benutzeroberfläche der OHD für den Datenexport im XML-Format
Unter der Verwendung von Radiobuttonelementen, die logisch für eine Einfach-Selektierung
implementiert wurden kann der Nutzer nach Auswahl in der ihm bekannten Listboxanzeige
„Datenformat“ aus den beiden Exportvarianten wählen.
Bisher wurden Radiobuttons in der Benutzeroberfläche der OHD noch nicht verwendet. Es kann
jedoch davon ausgegangen werden, dass die meisten Nutzer deren Bedienung aus andern SAP
Anwendungen, oder Fremdanwendungen z.B. in Weboberflächen bereits kennen. Wie alle
Dynproelemente erfüllen auch Radiobuttons den SAP Accessibility-Standard, was die Nutzbarkeit der
Oberfläche für Sehbehinderte gewährleisten könnte, sobald die Anforderung der Accessibility auch
an die Bedienungsoberflächen des BW gestellt werden würde. Aus der Benutzeroberfläche, die im
Paket RSB_GUI implementiert ist werden die relevanten Daten mittels einer Struktur übergeben, die
entsprechend der neuen Funktionalität um 4 Datenelemente erweitert wurde. 3 Davon als boolesche
Datentypen, die ein jeweiliges Binärkennzeichen entsprechend ihres Übergabe-Wertes aus der
Benutzeroberfläche zugewiesen bekommen und einem String der Werte aus einem Texteingabefeld
mit Wertehilfe übernimmt. Derzeit werden nur 2 boolesche Datenelemente gefüllt. Die übrigen
Elemente dienen einer möglichen Erweiterung der XML-Export-Funktionalität nähere Informationen
sind in Kapitel … aufgeführt. Diese Erweiterung wird benötigt, um in der Programmlogik
entsprechend bei der Erzeugung eines Objekts der Klasse CL_RSB_FILE_TYPE_XML benötigte Objekt-
Attribute zu füllen.
5. Ausblick über die Entwicklung von Business Intelligence und

Data Warehousing
Die Weiterentwicklung des SAP BI findet in enger Abstimmung mit den Kunden statt. Netweaver ist
ein SAP-Produkt, das für Unternehmen konzipiert wurde, die, mehr als 10.000 Mitarbeiter
beschäftigen. Diese Klientel äußert oft sehr spezielle Anforderungen an ein BI-System. Ob sich die
geäußerten Anforderungen als nützliche Erweiterung für die Standardsoftware darstellen könnten,
oder eher in den Bereich eines speziellen Customizings fällt muss meist individuell entschieden
werden.
22
5.1. BI in Services?
BI Software-Hersteller sehen sich oft mit konträren Anforderungen einmal des Kunden und der
wissenschaftlichen Definition von OLAP konfrontiert. Im Zuge der aufkommenden Enterprise Service
Oriented Architekture (eSOA)18 Technologie will der Kunde mehr als nur bestimmte Queries als
Services verwenden zu können. Er wünscht sich für die Zukunft wahrscheinlich eine immer
vollständigere BI-Funktionalität in Service gepackt. Das bedeutet das der serviceorientierte Ansatz,
der auf fest zu definierende Schnittstelle beruht nicht optimal für die Bereitstellung von OLAP-
Diensten ist. BI in Zusammenhangmit OLAP zeichnet sich durch seine Fähigkeit aus beliebigen, oft im
Vorhinein nicht zu definierende Quellen Daten aufzunehmen und zu verarbeiten. Die Ausführung
bestimmter Querys in einer eSOA-Umwelt lässt sich dagegen problemlos realisisieren, da
Schnittstellen dabei exakt bestimmt werden können. Doch die Modellierungsfunktionalitäten eines
DWH sind können so nicht zur Verfügung gestellt werden.
5.2. Was bringt die Zukunft den persistenten Datenobjekten?

Als Konflikt zwischen Kundenwunsch und der vorherrschenden Lehrmeinung kristallisiert sich die
Anforderung des Kunden heraus in Zukunft auf Datenpersistensen verzichten zu wollen. Der von
Seiten der Wissenschaft begründete Ansatz eines zum Produktivsystem zeitpunktabhängigen
redundanten Speichers, erfüllt bis Weilen nicht immer im gewünschten Maße die Vorstellungen des
Kunden, bezüglich Flexibilität und Performance. Er wünscht den direkten Auswertungsabhängigen
Input aus dem Produktivsystem. Es müssten z.B. nicht mehr Auswertungen auf zeitabhängige
Datenmodellierungen durchgeführt werden, sondern Auswertungen der Vergangenheit, mit einer
Analyse der Modellierung des aktuellen Datenbestandes aus dem Produktivsystem. Der Verzicht auf
den bisherigen redundanten und weitestgehend konsistenten Datenbestsand in persistenten
Datenobjekten würde eine grundsätzliche Neustrukturierung des Data Warehousing in BI erfordern,
da das Anforderungsprofil an ein solches Systems stark von bisherigen technischen Eigenschaften
unterscheiden würde. Die verlorene Redundanz würde in Folge auch zu einer geringeren Sicherheit
des Datenbestandes führen und könnte damit die Auswertungsqualität eines BI-Systems mindern.
Die Behandlung fehlender Daten, oder inkonsistent gewordener Datensätze erweist sich hier als
grundlegendes Problem.
5.3. Erweiterung der XML-Export-Funktionalität in der OpenHub

Destination
Neben der bisher zu verwendeten SAP Standard XSLT für die Konvertierung in das kanonisierte
asXML-Format wurde bereits sowohl in der Programmlogik und Benutzeroberfläche die
Funktionalität für den Nutzer implementiert eigene XML-Formate mittels des XSLT-Repositorys
anlegen und verwenden zu können. Dies würde dem Kunden ein höhere Flexibilität und u.U. eine
besserer Kundenorientierung ermöglichen, abhängig von seiner Marktposition auf dem Markt für BI-
Daten. Vom praktischen Nutzen für den Kunden ist eine solche Funktionalität in seinem
Marketingwert meiner Meinung nach nicht zu unterschätzen. Die Fähigkeit in einem System eigene
XSLTs zu erstellen, zu verwalten und u.a. auf BI-Daten anwenden zu können ist bei
Konkurrenzproduktion so nicht anzutreffen.
18
Siehe Glossar
23
Anhang
1. asXML-Beispiel für BI-Objekt:

<?xml version="1.0" encoding="utf-8" ?>
- <asx:abap xmlns:asx="http://www.sap.com/abapxml" version="1.0">
- <asx:values>
- <META>
- <RSBOHFIELDS>
<OHDEST>FIX_AP_CP</OHDEST>
<OBJVERS>A</OBJVERS>
<FIELDNM>/BIC/ZDOM_FIRM</FIELDNM>
<POSIT>0001</POSIT>
<TEMPIOBJNM>ZDOM_FIRM</TEMPIOBJNM>
<KEYFLAG>X</KEYFLAG>
<DATATYPE>CHAR</DATATYPE>
<INTLEN>000060</INTLEN>
<LENG>000030</LENG>
<OUTPUTLEN>000030</OUTPUTLEN>
<INTTYPE>C</INTTYPE>
<CONVEXIT>ALPHA</CONVEXIT>
<DECIMALS>000000</DECIMALS>
<OUTFORMAT>E</OUTFORMAT>
<EXT_DTYPE>CHAR</EXT_DTYPE>
<EXT_LENGHT>000030</EXT_LENGHT>
<UNIFIELDNM />
<DTELNM>/BIC/OIZDOM_FIRM</DTELNM>
</RSBOHFIELDS>
- <RSBOHFIELDS>
<FIELDNM>/BIC/FIRMJAHR</FIELDNM>
<POSIT>0002</POSIT>
<TEMPIOBJNM>FIRMJAHR</TEMPIOBJNM>
<KEYFLAG>X</KEYFLAG>
<DATATYPE>NUMC</DATATYPE>
<LENG>000004</LENG>
<INTTYPE>N</INTTYPE>
<CONVEXIT />
<OUTFORMAT>E</OUTFORMAT>
<EXT_DTYPE>CHAR</EXT_DTYPE>
<UNIFIELDNM />
<DTELNM>/BIC/OIFIRMJAHR</DTELNM>
</RSBOHFIELDS>
- <RSBOHFIELDS>
<FIELDNM>/BIC/UMS_NORD</FIELDNM>
<POSIT>0003</POSIT>
<TEMPIOBJNM>UMS_NORD</TEMPIOBJNM>
<KEYFLAG />
24
<DATATYPE>CURR</DATATYPE>
<LENG>000017</LENG>
<INTTYPE>P</INTTYPE>
<CONVEXIT />
<OUTFORMAT />
<EXT_DTYPE />
<UNIFIELDNM />
<DTELNM>/BIC/OIUMS_NORD</DTELNM>
</RSBOHFIELDS>
- <RSBOHFIELDS>
<FIELDNM>/BIC/UMS_WEST</FIELDNM>
<POSIT>0004</POSIT>
<TEMPIOBJNM>UMS_WEST</TEMPIOBJNM>
<KEYFLAG />
<LENG>000017</LENG>
<CONVEXIT />
<OUTFORMAT />
<EXT_DTYPE />
<UNIFIELDNM />
<DTELNM>/BIC/OIUMS_WEST</DTELNM>
</RSBOHFIELDS>
- <RSBOHFIELDS>
<FIELDNM>/BIC/UMS_OST</FIELDNM>
<POSIT>0005</POSIT>
<TEMPIOBJNM>UMS_OST</TEMPIOBJNM>
<KEYFLAG />
<LENG>000017</LENG>
<CONVEXIT />
<OUTFORMAT />
<EXT_DTYPE />
<UNIFIELDNM />
<DTELNM>/BIC/OIUMS_OST</DTELNM>
</RSBOHFIELDS>
- <RSBOHFIELDS>
25
<FIELDNM>/BIC/UMS_SUED</FIELDNM>
<POSIT>0006</POSIT>
<TEMPIOBJNM>UMS_SUED</TEMPIOBJNM>
<KEYFLAG />
<LENG>000017</LENG>
<CONVEXIT />
<OUTFORMAT />
<EXT_DTYPE />
<UNIFIELDNM />
<DTELNM>/BIC/OIUMS_SUED</DTELNM>
</RSBOHFIELDS>
- <RSBOHFIELDS>
<FIELDNM>RECORDMODE</FIELDNM>
<POSIT>0007</POSIT>
<TEMPIOBJNM>0RECORDMODE</TEMPIOBJNM>
<KEYFLAG />
<DATATYPE>CHAR</DATATYPE>
<LENG>000001</LENG>
<INTTYPE>C</INTTYPE>
<CONVEXIT />
<OUTFORMAT />
<EXT_DTYPE />
<UNIFIELDNM />
<DTELNM>RODMUPDMOD</DTELNM>
</RSBOHFIELDS>
</META>
- <DATA>
- <item>
<_-BIC_-ZDOM_FIRM>Fahrradladen Peter</_-BIC_-ZDOM_FIRM>
<_-BIC_-FIRMJAHR>2006</_-BIC_-FIRMJAHR>
<_-BIC_-UMS_NORD>150000.0</_-BIC_-UMS_NORD>
<_-BIC_-UMS_WEST>50000.0</_-BIC_-UMS_WEST>
<_-BIC_-UMS_OST>200000.0</_-BIC_-UMS_OST>
<_-BIC_-UMS_SUED>200000.0</_-BIC_-UMS_SUED>
<RECORDMODE />
</item>
- <item>
<_-BIC_-ZDOM_FIRM>Fahrradladen Peter</_-BIC_-ZDOM_FIRM>
26
<RECORDMODE />
</item>
- <item>
<_-BIC_-ZDOM_FIRM>Spielwaren Klaus</_-BIC_-ZDOM_FIRM>
<RECORDMODE />
</item>
- <item>
<_-BIC_-ZDOM_FIRM>Spielwaren Klaus</_-BIC_-ZDOM_FIRM>
<RECORDMODE />
</item>
- <item>
<_-BIC_-ZDOM_FIRM>Suessigkeiten Mueller</_-BIC_-ZDOM_FIRM>
<RECORDMODE />
</item>
- <item>
<_-BIC_-ZDOM_FIRM>Suessigkeiten Mueller</_-BIC_-ZDOM_FIRM>
<RECORDMODE />
</item>
</DATA>
</asx:values>
</asx:abap>
2. Konvertierungsmethode der Klasse CL_RSB_FILE_TYPE_XML:

METHOD convert.
DATA: l_v_tranid TYPE cXSLTdesc,

l_v_result TYPE string,
l_v_fopt TYPE rsb_foption,
l_v_count TYPE int4,
l_same_cp TYPE rs_bool,
l_r_ifbwriter TYPE REF TO if_sxml_writer,
27
l_r_exc TYPE REF TO cx_root,

l_r_clbwriter TYPE REF TO cl_sxml_string_writer.
* l_r_tabdescr TYPE REF TO cl_abap_datadescr.
IF me-
>get_p_callconvert_count( ) > 3. "table_ lenght for get the structure of th
e datas
FIELD-SYMBOLS <l_r_dtab> TYPE STANDARD TABLE.

*save tableobject in field-symbol
ASSIGN o_r_datatab->* TO <l_r_dtab>.
*append imported structure into field-symbol
APPEND i_s_data TO <l_r_dtab>.
*shot refernce of object attribute to memory of field-symbol
GET REFERENCE OF <l_r_dtab> INTO o_r_datatab.
*countdown
me->set_p_callconvert_count( ).
ELSE. "Transform the hole datatable
*save tableobject in field-symbol

ASSIGN o_r_datatab->* TO <l_r_dtab>.
*append imported structure into field-symbol
APPEND i_s_data TO <l_r_dtab>.
*shot refernce of object attribute to memory of field-symbol
GET REFERENCE OF <l_r_dtab> INTO o_r_datatab.
FIELD-SYMBOLS <l_t_dtab> TYPE ANY TABLE.

*the field-symbol get filled with the dataobject
ASSIGN o_r_datatab->* TO <l_t_dtab>.
l_v_fopt = me-
>get_p_file_operator( ). " get kind of choosen transformation
*defines the right Transformationtype //customer choice

CASE l_v_fopt.
WHEN '2'. "customer specific
l_v_tranid = me->get_p_tranid( ).
WHEN '1'. "basXML (SAP specific Format)
l_r_ifbwriter = cl_sxml_string_writer=>create( type = if_sxml=>co_x
t_binary ).
l_v_tranid = 'ID'.
WHEN OTHERS. "asXML canonical
l_v_tranid = 'ID'.
ENDCASE.
TRY .
CALL TRANSFORMATION (l_v_tranid) "Transformation in specific format
SOURCE META = me->p_t_field "Meatdatas
DATA = <l_t_dtab> "Datas
RESULT XML l_v_result."XML-String
*Catch xsl or Simple-Transformation Exception

CATCH cx_root INTO l_r_exc.
me->handle_tran_exc( EXPORTING i_r_exc = l_r_exc ).
28
ENDTRY.
*if basXML was choosen convert Transformationresult in binary-Format

IF l_v_fopt = '1'.
l_r_clbwriter ?= l_r_ifbwriter.
l_r_ifbwriter->write_value( EXPORTING value = l_v_result ).
l_v_result = l_r_clbwriter->get_output( ).
ENDIF.
*For Testing
* cl_abap_browser=>show_xml( EXPORTING xml_string = l_v_result ).
*Export as String
e_line_csv = l_v_result.
ENDIF.
ENDMETHOD.
3. Konstruktor der Klasse CL_RSB_FILE_TYPE_XML:

method CONSTRUCTOR.
super->constructor( ).
*Metadatatable
P_T_FIELD = I_T_FIELD.
*Customer Ttansformation (optional)
P_TRANID = I_V_TRANID.
*Set Fileoptionvalue(0|1|2)
P_FILE_OPERATOR = I_V_FOPT.
*Set number of tablines
P_CallConvert_count = I_R_TABLEDESCR->Length.
*Set Referenz to cl_abap_tabledescr
O_R_TABLEDESCR = I_R_TABLEDESCR.
*Get Type of Datatable
CREATE DATA o_r_datatab TYPE HANDLE me->O_R_TABLEDESCR.
endmethod.
4. Verwendungsdokumentation der Klasse CL_RSH_FILE_TYPE_XML:

CL CL_RSB_FILE_TYPE_XML
____________________________________________________
Kurztext
Typkonvertierungsdienst
Funktionalität
Diese finale Klasse dient zur Konvertierung und Extrahierung generischer Daten internen Typs des BI-Systems
im XML-Format als lokales Fileobjekt. Es werden dabei das kanonisierte asXML Format, die komprimierte
basXML und das Anwenden einer kundenspezifischen XSLT unterstützt.
Beziehungen
# CL CL_RSB_FILE_TYPE
29
 CL CL_RSB_FILE_TYPE_ASCII
CL CL_RSB_FILE_TYPE_CSV
CL CL_RSB_FILE_TYPE_XML
Hinweise
Im Paket RSB wurde ein Paketschnittstelle zum Paketinterface SXML_Core implementiert.
Weiterführende Informationen
Klassen:
CL_RSB_FILE_TYPE
CL_SXML_Writer
Glossar:
1. Online Transaction Processing (OLTP): „die zentralisierte Transaktionsverarbeitung, bei der
eine Folge von Aufträgen nacheinander auf einem Computer verarbeitet wird, wobei alle
Benutzer den Eindruck haben, als arbeite das System in Echtzeit“ (Lutz J. Heinrich, 2004)
2. Online Analytical Processing (OLAP): OLAP-Systeme strukturieren Daten in einem

multidimensionalen Modell, das der Entscheidungsfindung dient. OLAP ist die analytische
Entsprechung von OLTP
3. Business Intelligence (BI): umfasst alle informationstechnischen Instrumente für die

Auswertung von unternehmensweit verfügbarem Wissen. 2. Zugriff, Analyse und Bereitstellen
von Unternehmensdaten für Anwender im Unternehmen.
4. SAP Netweaver: Eine offene Integrations- und Anwendungsplattform für alle SAP-Lösungen
und bestimmte Lösungen von SAP-Partnern.
5. Extensible-Markup –Language (XML): Eine für die Anwendung im World Wide Web
entwickelte Teilmenge der Standard Generalized Markup Language (SGML). eXtensible
Markup Language- oder XML-Dokumente bestehen aus Entitäten, die entweder analysierte
(parsed) oder nicht analysierte (unparsed) Daten enthalten. Die Spezifikation XML 1.0 wurde
von der XML-Arbeitsgruppe des W3C (World Wide Web Consortium) entworfen und 1998
vom W3C als Empfehlung angenommen. Sie finden diese Spezifikation unter www.w3.org.
Auf der Grundlage von XML wurden (und werden) zahlreiche Standards für spezielle
Aufgaben entwickelt. Dazu zählen XLink, XPointer, XSL, XSLT, und DOM.
6. Comma-Separated-Value (CSV): Ein flaches Datenformat, deren Werte wird einen Seperator,
meist ein Komma getrennt werden
7. American Standard Code for Information Interchange (ASCII): Abkürzung für American
Standard Code for Information Interchange. Nach ISO-646 genormter 7-Bit-Zeichensatz.
Durch ISO-8859 auf 8-Bit-Zeichensätze erweitert.
30
8. Open Hub-Destination OHD: Die Open Hub Destination ist eine Entität des OpenHub Service.
Ein Objekt ermöglicht es, Daten aus einem BI-System in nicht-SAP Data Marts, Analytical
Applications und andere Anwendungen zu verteilen. Damit wird die kontrollierte Verteilung
über mehrere Systeme hinweg gewährleistet. Durch die Open Hub Destination wird definiert,
in welches Ziel die Daten weitergeleitet werden.
9. Data Warehouse (DWH): Die Open Hub Destination ist das Objekt, das ermöglicht, Daten aus
einem BI-System in nicht-SAP Data Marts, Analytical Applications und andere Anwendungen
zu verteilen. Damit wird die kontrollierte Verteilung über mehrere Systeme hinweg
gewährleistet.
10. Data Mart: stellt die eigentliche BI-Logik zur Verfügung.
11. InfoProvidern: Oberbegriff für BI-Objekte, in die Daten geladen werden oder die Sichten auf
Daten darstellen.
12. Die Data Source (DS): liefert die Beschreibung der Quelldaten. Sie werden für die
Datenextraktion aus einem Quellsystem und Übertragung der Daten ins BI, oder für den
direkten Zugriff auf Quelldaten aus dem BI heraus verwendet. Sie ist somit das Gegenstück
der OpenHub Destination, also für das Mapping der Quelldatan in das Zielsystem eines PSA
Objekts zuständig.
13. Persistent Staging Area (PSA): Transparente Datenbanktabelle, in der Requestdaten im

Format der Transferstruktur abgelegt werden. Ein PSA wird pro DataSource und Quellsystem
angelegt. Es stellt eine Eingangsablage im BI dar, in der die angeforderten Daten unverändert
zum Quellsystem gespeichert werden.
14. Daten-Transfer-Prozess (DTP): Ein DTP dient der Übertragung von Daten zwischen
persistenten Datenobjekten innerhalb des BI. Hierbei werden Transformationen und Filter
auf die Daten angewendet, die eine konsistente Datenübertragung gewährleisten sollen.
Deshalb ist die Definition einer Transformation für einen DTP obligatorisch und muss für
dessen Durchführung in aktiver Version vorliegen.
15. Unified Modelling Language (UML): ist die von der Object Management Group (OMG)
anerkannte Standard- Sprache für die semantische Analyse von Objekten und für das Design
von objektorientierten Modellen mit Hilfe von graphischen Werkzeugen.
16. Run Time Type Service (RTTS): Die Methoden der RTTS beschaffen Informationenzu
Datentypen oder Klassen von Objekten oder erzeugen neue Datentypen in der Form von
Typobjekten. Die RTTS sind als Hierarchie von Typklassen implementiert, aus denen
Typobjekte erzeugt werden können.
17. Feldsymbole: Symbolischer Name für ein Datenobjekt, dem zur Programmlaufzeit konkrete
Speicherbereiche zugewiesen werden können. Ein Feldsymbol kann stellvertretend für
Datenobjekte an Operandenpositionen verwendet werden. Ein Feldsymbol ist entweder
generisch oder vollständig typisiert. Feldsymbole werden mit der Anweisung FIELD-
SYMBOLS deklariert und bekommen mit ASSIGN Speicherbereiche zugewiesen.
18. Enterprise Service Oriented Architekture (eSOA): „*…]open architecture for adaptive business
solutions. Enterprise SOA creates a gradual path to flexible, service-centric system
31
landscapes and allows a non-disruptive transition of existing applications and architecture for
more flexibility and value. The fundamental premise of Enterprise SOA is the abstraction of
business activities or events, modelled as enterprise services“ (SAP AG, 2004)
32
19.
Literaturverzeichnis:
Lehmann, S. -S. (2001). SAP Business Information Warehouse. SAP PRESS.
Reibold. (2003). XML kompakt. BoD.
SAP AG. (3. Januar 2004). help.sap.com. Abgerufen am 12. August 2008 von
http://help.sap.com/saphelp_nw2004s/helpdata/de/e3/e60138fede083de10000009b38f8cf/frames
et.htm
Thielen, E. -F.-S.-S. (2003). SAP BW Datenbeschaffung. SAP PRESS.
Weber, E. -F.-K.-S.-S. (2006). SAP Business Intelligence. SAP PRESS.
World Wide Web Consortium. (n.d.). www.w3.org. Retrieved August 8, 2008, from
http://www.w3.org/DOM/
33

SAP OpenHub XML Export

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAP OpenHub XML Export

Uploaded by

Copyright:

Available Formats

Studienbereich Wirtschaft

XML-Export im SAP Data Warehouse

Verfasser: Marco Hammel

Name der betrieblichen Funktion des betrieblichen Unterschrift des

Thomas Brandt Senior Develper

keiner anderen Prüfungsbehörde vorgelegt und auch nicht veröffentlicht.

1. Erläuterung der Problemstellung

Online Transaction Processing (OLTP):1 Das der traditionellen Dokumentation und

Online Analytical Processing (OLAP):2 ist im Gegensatz zu OLTP in seiner Datenstruktur

Die Wartung des Fremdprogramms:

o Z.B. bei Eigenentwicklungen,

o Oder das Pflegen von neuen Format-Standards

o Da die Prozesskette einen weiteren Schritt umfasst und

o Die Prozesskette systemübergreifend konfiguriert werden muss.

2. Allgemeine Informationen in SAP Business Intelligence und Data

aus verschiedenen Quellsystemen zu integrieren,

in konsistente Formate zu transformieren,

den Werkzeugen der BI-Suite zur Verfügung zu stellen.

Abb. 2 Schichten-Architektur eines Business Intelligence Systems (SAP AG, 2004)

2.1. InfoProvider des Data Warehouse

Zu den Vertretern, die eine physische Datenablage darstellen zählen:

- InfoCube: stellt einen geschlossenen Datenbestand eines betriebswirtschaftlichen Bereichs

- DataStore-Objekt: beschreibt einen konsolidierten Datenbestand aus mindestens einer

- InfoObject (Attribute oder Texte): sind betriebswirtschaftliche Auswertungsobjekte, die aus

betriebswirtschaftliches Merkmal repräsentieren. Typische InfoObject´s repräsentieren z.B.

Virtuelle Datensichten können durch

- Multiprovider: repräsentieren eine Report-spezifische Sicht auf andere Infoprovider, die

- Virtualprovider: repräsentiert, wie der Multiprovider eine Report-spezifische Sicht auf in

2.2. Persistente Datenspeicherung im Data Warehouse

2.3. Der Datentransfer innerhalb des Data Warehouse

2.4. Aufbau der OpenHub Destination im Data Warehouse

Hohe Performance des Extraktionsprozesses,

Bei niedrigem Ressourcenverbrauch

Und hoher Fehleridentifikationsrate

Mit Fähigkeit zur Stapelverarbeitung

Der Konvertierungsfähigkeit von Daten und Datenobjekten in unterschiedliche Formate

Als Kommaseparierte Werte in csv Dateien

Als ASCII Codierung in txt Dateien

Um semantische Informationen in diesen flachen Dateiformaten mitführen zu können, wird eine

Die OHD unterstützt für alle Zielsysteme 2 unterschiedliche Extraktionsmodi. Den

3. Extensible Markup Language in Business Applikationen

SyncML (Synchronisation Markup Language): verwendet für die Gerätesynchronisation

XHTML (eXtensible HyperText Markup Language): Erweiterungsfähiger HTML-Nachfolger

(Reibold, 2003, S. 20/21)

Mit seiner generischen Syntax als Markierungssprache

Ein generisches Datenstrukturkonzept für Programmiersprachen z.B. mit dem Document

Typisieren und Validieren

Abfragen und Transformieren

Leicht zu erweitern, flexibel und dabei persistent

Kombiniert heterogene Daten aus Framework und Anwendung

Ein offenes Kommunikationsformat

4. Entwicklung der XML-Export-Funktionalität in der OpenHub

Sie soll in einer XML-Datei Metadaten und BI-Daten strukturiert darstellen.

4.1. Analyse der Programmlogik

4.1.1. Analyse der Paketstruktur

Abb. 4 Paketstruktur in SAP Netweaver

Abb. 5 Ausschnitt der Schnittstellenhierarchie des SXML Pakets

4.1.2. Analyse von Programmablauflogik und Klassendesign

Abb. 6 Komprimiertes UML-Klassendiagramm Destinationsklassen, Darstellung der Lokalen Schreibklasse

Wie im folgenden UML-Sequenzdiagramm ersichtlich, wird in der Methode Receive_Data, oder

Abb. 7 Auschnitt UML-Sequenzdiagramm

4.2. Spezifikation der XML-Struktur für BI-Datenobjekte

1. Die Metadaten werden am Kopf, oder

2. Am Fuß des XML Dokuments logisch separiert.