Sie sind auf Seite 1von 34
Studienbereich Wirtschaft Studiengang Wirtschaftsinformatik XML-Export im SAP Data Warehouse Entwicklung eines XML Exports

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 Betreuers / der betrieblichen Betreuerin:

Funktion des betrieblichen Betreuers / der betrieblichen Betreuerin:

Unterschrift des betrieblichen Betreuers / der betrieblichen Betreuerin:

Thomas Brandt

Senior Develper

XML-Export im SAP DataWarehouse

Eidesstattliche Erklärung:

25. August 2008

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.

marco.hammel@sap.com

X

Marco Hammel Student der Wirtschaftsinformatik

1

1

XML-Export im SAP DataWarehouse

Inhaltsverzeichnis:

25. August 2008

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

marco.hammel@sap.com

2

2

XML-Export im SAP DataWarehouse

Abbildungsverzeichnis:

25. August 2008

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

marco.hammel@sap.com

3

3

XML-Export im SAP DataWarehouse

1. Erläuterung der Problemstellung

25. August 2008

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 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- 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

marco.hammel@sap.com

4

4

XML-Export im SAP DataWarehouse

25. August 2008

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 Netweaver 4 -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:eine XML erzeugen. Das bedeutet jedoch Mehraufwand für: o Z.B. bei Eigenentwicklungen, o Oder das Pflegen

o

Z.B. bei Eigenentwicklungen,

o

Oder das Pflegen von neuen Format-Standards

Die Systemressourcen,o Oder das Pflegen von neuen Format-Standards o Da die Prozesskette einen weiteren Schritt umfasst und

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

marco.hammel@sap.com

5

5

XML-Export im SAP DataWarehouse

25. August 2008

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.

seine Datenmodellierung und Beschaffung mittels OLAP. Abb. 1 BI und dessen Komponenten im Kontext des SAP

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:

werden. Es hat die Aufgabe Daten in folgender Rheinfolge: aus verschiedenen Quellsystemen zu integrieren,

aus verschiedenen Quellsystemen zu integrieren,

marco.hammel@sap.com

6

6

XML-Export im SAP DataWarehouse

in konsistente Formate zu transformieren,XML-Export im SAP DataWarehouse zu konsolidieren, zu bereinigen, physikalisch zu speichern, zu verteilen, 25. August 2008

zu konsolidieren,SAP DataWarehouse in konsistente Formate zu transformieren, zu bereinigen, physikalisch zu speichern, zu verteilen, 25.

zu bereinigen,in konsistente Formate zu transformieren, zu konsolidieren, physikalisch zu speichern, zu verteilen, 25. August 2008 den

physikalisch zu speichern,Formate zu transformieren, zu konsolidieren, zu bereinigen, zu verteilen, 25. August 2008 den Werkzeugen der BI-Suite

zu verteilen,zu konsolidieren, zu bereinigen, physikalisch zu speichern, 25. August 2008 den Werkzeugen der BI-Suite zur Verfügung

25. August 2008

den Werkzeugen der BI-Suite zur Verfügung zu stellen.physikalisch zu speichern, zu verteilen, 25. August 2008 Grundsätzlich beruht die Funktion eines DWH auf der

Grundsätzlich beruht die Funktion eines DWH auf der in der folgenden Abbildung dargestellten

klassischen Schichten-Architektur der BI:

dargestellten klassischen Schichten-Architektur der BI: Abb. 2 Schichten-Architektur eines Business Intelligence

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 Marts 10 , 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

marco.hammel@sap.com

7

7

XML-Export im SAP DataWarehouse

25. August 2008

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 11 zur 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

marco.hammel@sap.com

8

8

XML-Export im SAP DataWarehouse

25. August 2008

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) 1 2 , die dem BI in Folge die Daten bereits als betriebswirtschaftliche Einheit zur 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) 1 3 :, das ein unverändertes Abbild der Quelldaten im BI in einer transparenten relationalen 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

marco.hammel@sap.com

9

9

XML-Export im SAP DataWarehouse

25. August 2008

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,an dieses Werkzeug können wie folgt formuliert werden: Bei niedrigem Ressourcenverbrauch Geringer Fehlerrate Und

Bei niedrigem Ressourcenverbrauchwerden: Hohe Performance des Extraktionsprozesses, Geringer Fehlerrate Und hoher Fehleridentifikationsrate

Geringer Fehlerratedes Extraktionsprozesses, Bei niedrigem Ressourcenverbrauch Und hoher Fehleridentifikationsrate Variabler

Und hoher FehleridentifikationsrateBei niedrigem Ressourcenverbrauch Geringer Fehlerrate Variabler Konfigurationsfähigkeit Mit Fähigkeit zur

Variabler KonfigurationsfähigkeitGeringer Fehlerrate Und hoher Fehleridentifikationsrate Mit Fähigkeit zur Stapelverarbeitung Der

Mit Fähigkeit zur StapelverarbeitungFehleridentifikationsrate Variabler Konfigurationsfähigkeit Der Konvertierungsfähigkeit von Daten und Datenobjekten in

Der Konvertierungsfähigkeit von Daten und Datenobjekten in unterschiedliche FormateMit Fähigkeit zur Stapelverarbeitung Sie unterstützt dabei den Export in Datenbanken, Dateien

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

marco.hammel@sap.com

10

10

XML-Export im SAP DataWarehouse

25. August 2008

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 Dateienvon BI-Daten in Dateien stehen bis dato die Datei- Formate: Als ASCII Codierung in txt Dateien

Als ASCII Codierung in txt Dateiendie Datei- Formate: Als Kommaseparierte Werte in csv Dateien Zur Verfügung. Um semantische Informationen in diesen

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.Dieser soll in 2 Varianten angeboten werden, als: binary ABAP Serialization XML (basXML ): ist eine

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.SAP- und Fremdsystemen in beide Richtungen optimiert ist. Weiter Informationen zu den SAP XML Varianten werden

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.alle Zielsysteme 2 unterschiedliche Extraktionsmodi. Den Deltaextraktionsmodus: führt nur eine Aktualisierung

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.für kleine Datenbestände mit hoher Volatilität geeignet. Typisch für eine Deltaextraktion sind z.B.

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.

marco.hammel@sap.com

11

11

XML-Export im SAP DataWarehouse

25. August 2008

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:

an selber Position der Schichten Architektur des DWH ein: Abb. 3 Die OHD als Schnittstelle zu

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 DatenXML-Anwendungen, hier ein paar der bekanntesten Anwendungen: SyncML (Synchronisation Markup Language): verwendet für die

SyncML (Synchronisation Markup Language): verwendet für die Gerätesynchronisationand Presence Protocol): zum Austausch von Messaging Daten XHTML (eXtensible HyperText Markup Language):

XHTML (eXtensible HyperText Markup Language): Erweiterungsfähiger HTML-NachfolgerMarkup Language): verwendet für die Gerätesynchronisation (Reibold, 2003, S. 20/21) XML ist: mit seinem generischen

(Reibold, 2003, S. 20/21)

XML ist:

mit seinem generischen Datenmodel, die sich in Elemente und Attribute in einer Baumstruktur aufgeteilt repräsentiert.HTML-Nachfolger (Reibold, 2003, S. 20/21) XML ist: Mit seiner generischen Syntax als Markierungssprache Ein

Mit seiner generischen Syntax als MarkierungsspracheAttribute in einer Baumstruktur aufgeteilt repräsentiert. Ein generisches Datenstrukturkonzept für

Ein generisches Datenstrukturkonzept für Programmiersprachen z.B. mit dem Document Object Model (DOM), das als „ platform- and language-neutral interface that will allow (DOM), das als „platform- and language-neutral interface that will allow

marco.hammel@sap.com

12

12

XML-Export im SAP DataWarehouse

25. August 2008

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:

Parsenweitverbreitet offene Basis für Standards und Tools zum: Typisieren und Validieren Abfragen und Transformieren Von

Typisieren und Validierenoffene Basis für Standards und Tools zum: Parsen Abfragen und Transformieren Von Dokumenten und Protokollen.

Abfragen und TransformierenStandards und Tools zum: Parsen Typisieren und Validieren Von Dokumenten und Protokollen. Aus diesen Eigenschaften

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 persistentdurch die Nutzung von XML folgende Vorteile. XML ist: Kombiniert heterogene Daten aus Framework und Anwendung

Kombiniert heterogene Daten aus Framework und AnwendungXML ist: Leicht zu erweitern, flexibel und dabei persistent Plattformunabhängig Ein offenes Kommunikationsformat

PlattformunabhängigKombiniert heterogene Daten aus Framework und Anwendung Ein offenes Kommunikationsformat Insbesondere die

Ein offenes KommunikationsformatDaten aus Framework und Anwendung Plattformunabhängig Insbesondere die Plattformunabhängigkeit und die leichte

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.Zu berücksichtigen sind hierbei folgende technischen-: Sie soll in einer XML-Datei Metadaten und BI-Daten

Sie soll in einer XML-Datei Metadaten und BI-Daten strukturiert darstellen.technischen-: Die Funktion muss alle BI-Datenobjekte unterstützen, die auch die ODH unterstützt. marco.hammel@sap.com 13

marco.hammel@sap.com

13

13

XML-Export im SAP DataWarehouse

25. August 2008

Sie soll möglichst in den meisten Fällen Performancevorteile gegenüber den bisherigen Dateiexporten bringen, mindestens jedoch keine Nachteile.XML-Export im SAP DataWarehouse 25. August 2008 Die Funktionalität soll dabei im technischen Sinne möglichst einfach

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.Dateiexporten bringen, mindestens jedoch keine Nachteile. Die Implementierung soll sich dabei in das bestehende Design

Die Implementierung soll sich dabei in das bestehende Design der OHD möglichst harmonisch integrieren. (Architekturneutral)zu verwendeten Standardformate asXML und basXML bedürfen. und Benutzeraspekte: Die Bedienung über das User Interface

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.integrieren. (Architekturneutral) und Benutzeraspekte: Die Menüführung soll sich dabei möglichst eindeutig und

Die Menüführung soll sich dabei möglichst eindeutig und unmissverständlich präsentieren. Also einen hohen Grad an Useability aufweisen.Informationen kontextabhängig zu Verfügung stellen. 4.1. Analyse der Programmlogik Aus den technischen

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.

marco.hammel@sap.com

14

14

XML-Export im SAP DataWarehouse

25. August 2008

XML-Export im SAP DataWarehouse 25. August 2008 Abb. 4 Paketstruktur in SAP Netweaver Über die Paketschnittstelle

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:

des SXML Pakets wie folgt angesiedelt: Abb. 5 Ausschnitt der Schnittstellenhierarchie des SXML

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.

marco.hammel@sap.com

15

15

XML-Export im SAP DataWarehouse

25. August 2008

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:

verantwortlichen Klassen zur Verfügung stellen: Abb. 6 Komprimiertes UML-Klassendiagramm

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

marco.hammel@sap.com

16

16

XML-Export im SAP DataWarehouse

25. August 2008

XML-Export im SAP DataWarehouse 25. August 2008 Abb. 7 Auschnitt UML-Sequenzdiagramm Daraufhin werden die Daten der

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

marco.hammel@sap.com

17

17

XML-Export im SAP DataWarehouse

25. August 2008

ü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.und Implementierungsaufwand. Gründe hierfür sind: Ein aufwendiges Mapping der Metadaten und BI-Datentabelle zu

Ein aufwendiges Mapping der Metadaten und BI-Datentabelle zu einem konsistenten Datenobjekt.mindestens eine Ebene tiefer zu schachtelnde XML-Struktur. Die bei mehrmaligen vorkommen eines BI-Datenobjekts gleichen

Die bei mehrmaligen vorkommen eines BI-Datenobjekts gleichen Typs auftretende Redundanz von Metadateninformation.und BI-Datentabelle zu einem konsistenten Datenobjekt. 4.3. Erstellen des Erweiterungsdesigns Aufgrund der an das

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:

marco.hammel@sap.com

18

18

XML-Export im SAP DataWarehouse

25. August 2008

XML-Export im SAP DataWarehouse 25. August 2008 Abb. 8 Komprimiertes UML-Klassendiagramm der XML Konvertierungsklasse

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:

der Klasse hat hierbei folgendes Erscheinungsbild: Abb. 9 Methoden der Klasse CL_RSB_FILE_TYPE_XML in

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:

marco.hammel@sap.com

19

19

XML-Export im SAP DataWarehouse

25. August 2008

XML-Export im SAP DataWarehouse 25. August 2008 Abb. 10Attribute der Klasse CL_RSB_FILE_TYPE_XML in Darstellung der ABAP

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.CL_RSB_FILE_TYPE_XML in Darstellung der ABAP Workbench Das geschützte Attribut O_R_TABLEDESCR repräsentiert eine

Das geschützte Attribut O_R_TABLEDESCR repräsentiert eine Referenz auf spezielles ABAP Laufzeitanalyseobjekt, den sogenannten Run Time Type Service (RTTS) 1 6 . Die Implementierung dieses Attribut trägt dem in Kapitel 4.2 beschriebenen XML- Validitätsproblem 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.muss im Quellcode entsprechend generisch behandelt werden. Das private Attribut P_FILE_OPERATOR repräsentiert einen

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.über den Methodenaufruf hinaus zu referenzieren. Das private Attribut P_CALL_CONVERT_COUNT dient als

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.der erzeugten asXML Zeichenkette in basXML bewirkt. Das private Attribut P_TRANID bestimmt, welche Konvertierung

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.vollständig eingelesen wurde, und Konvertiert werden kann. 4.5. Logik der CONVERT Methode Bei der Implementierung der

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

marco.hammel@sap.com

20

20

XML-Export im SAP DataWarehouse

25. August 2008

ggf. in ein binäres Format umzuwandeln. Für diese Aufgabe wurde eine spezielle ABAP OO-Technik eingesetzt, Feldsymbole 17 . 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:

Menüführung. Diese präsentiert sich wie folgt: Abb. 11 Benutzeroberfläche der OHD für den Datenexport im

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

marco.hammel@sap.com

21

21

XML-Export im SAP DataWarehouse

25. August 2008

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:

eine Oberfläche für den XML-Export wie folgt konzipiert: Abb. 12 Benutzeroberfläche der OHD für den Datenexport

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.

marco.hammel@sap.com

22

22

XML-Export im SAP DataWarehouse

5.1. BI in Services?

25. August 2008

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

marco.hammel@sap.com

23

23

XML-Export im SAP DataWarehouse

Anhang

1. asXML-Beispiel für BI-Objekt:

<?xml version="1.0" encoding="utf-8" ?>

25. August 2008

- <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> <OHDEST>FIX_AP_CP</OHDEST> <OBJVERS>A</OBJVERS> <FIELDNM>/BIC/FIRMJAHR</FIELDNM>

<POSIT>0002</POSIT>

<TEMPIOBJNM>FIRMJAHR</TEMPIOBJNM> <KEYFLAG>X</KEYFLAG> <DATATYPE>NUMC</DATATYPE>

<INTLEN>000008</INTLEN>

<LENG>000004</LENG>

<OUTPUTLEN>000004</OUTPUTLEN>

<INTTYPE>N</INTTYPE> <CONVEXIT />

<DECIMALS>000000</DECIMALS>

<OUTFORMAT>E</OUTFORMAT> <EXT_DTYPE>CHAR</EXT_DTYPE>

<EXT_LENGHT>000004</EXT_LENGHT>

<UNIFIELDNM /> <DTELNM>/BIC/OIFIRMJAHR</DTELNM> </RSBOHFIELDS>

- <RSBOHFIELDS> <OHDEST>FIX_AP_CP</OHDEST> <OBJVERS>A</OBJVERS> <FIELDNM>/BIC/UMS_NORD</FIELDNM>

<POSIT>0003</POSIT>

<TEMPIOBJNM>UMS_NORD</TEMPIOBJNM> <KEYFLAG />

marco.hammel@sap.com

24

24

XML-Export im SAP DataWarehouse

<DATATYPE>CURR</DATATYPE>

<INTLEN>000009</INTLEN>

<LENG>000017</LENG>

<OUTPUTLEN>000023</OUTPUTLEN>

<INTTYPE>P</INTTYPE> <CONVEXIT />

<DECIMALS>000002</DECIMALS>

<OUTFORMAT /> <EXT_DTYPE />

<EXT_LENGHT>000000</EXT_LENGHT>

<UNIFIELDNM /> <DTELNM>/BIC/OIUMS_NORD</DTELNM> </RSBOHFIELDS>

- <RSBOHFIELDS> <OHDEST>FIX_AP_CP</OHDEST> <OBJVERS>A</OBJVERS> <FIELDNM>/BIC/UMS_WEST</FIELDNM>

<POSIT>0004</POSIT>

<TEMPIOBJNM>UMS_WEST</TEMPIOBJNM> <KEYFLAG /> <DATATYPE>CURR</DATATYPE>

<INTLEN>000009</INTLEN>

<LENG>000017</LENG>

<OUTPUTLEN>000023</OUTPUTLEN>

<INTTYPE>P</INTTYPE> <CONVEXIT />

<DECIMALS>000002</DECIMALS>

<OUTFORMAT /> <EXT_DTYPE />

<EXT_LENGHT>000000</EXT_LENGHT>

<UNIFIELDNM /> <DTELNM>/BIC/OIUMS_WEST</DTELNM> </RSBOHFIELDS>

- <RSBOHFIELDS> <OHDEST>FIX_AP_CP</OHDEST> <OBJVERS>A</OBJVERS> <FIELDNM>/BIC/UMS_OST</FIELDNM>

<POSIT>0005</POSIT>

<TEMPIOBJNM>UMS_OST</TEMPIOBJNM> <KEYFLAG /> <DATATYPE>CURR</DATATYPE>

<INTLEN>000009</INTLEN>

<LENG>000017</LENG>

<OUTPUTLEN>000023</OUTPUTLEN>

<INTTYPE>P</INTTYPE> <CONVEXIT />

<DECIMALS>000002</DECIMALS>

<OUTFORMAT /> <EXT_DTYPE />

<EXT_LENGHT>000000</EXT_LENGHT>

<UNIFIELDNM /> <DTELNM>/BIC/OIUMS_OST</DTELNM> </RSBOHFIELDS>

- <RSBOHFIELDS>

marco.hammel@sap.com

25. August 2008

25

25

XML-Export im SAP DataWarehouse

<OHDEST>FIX_AP_CP</OHDEST> <OBJVERS>A</OBJVERS> <FIELDNM>/BIC/UMS_SUED</FIELDNM>

<POSIT>0006</POSIT>

<TEMPIOBJNM>UMS_SUED</TEMPIOBJNM> <KEYFLAG /> <DATATYPE>CURR</DATATYPE>

<INTLEN>000009</INTLEN>

<LENG>000017</LENG>

<OUTPUTLEN>000023</OUTPUTLEN>

<INTTYPE>P</INTTYPE> <CONVEXIT />

<DECIMALS>000002</DECIMALS>

<OUTFORMAT /> <EXT_DTYPE />

<EXT_LENGHT>000000</EXT_LENGHT>

<UNIFIELDNM /> <DTELNM>/BIC/OIUMS_SUED</DTELNM> </RSBOHFIELDS>

- <RSBOHFIELDS> <OHDEST>FIX_AP_CP</OHDEST> <OBJVERS>A</OBJVERS> <FIELDNM>RECORDMODE</FIELDNM>

25. August 2008

<POSIT>0007</POSIT>

<TEMPIOBJNM>0RECORDMODE</TEMPIOBJNM>

<KEYFLAG /> <DATATYPE>CHAR</DATATYPE>

<INTLEN>000002</INTLEN>

<LENG>000001</LENG>

<OUTPUTLEN>000001</OUTPUTLEN>

<INTTYPE>C</INTTYPE> <CONVEXIT />

<DECIMALS>000000</DECIMALS>

<OUTFORMAT /> <EXT_DTYPE />

<EXT_LENGHT>000000</EXT_LENGHT>

<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>

<_-BIC_-FIRMJAHR>2007</_-BIC_-FIRMJAHR>

<_-BIC_-UMS_NORD>200000.0</_-BIC_-UMS_NORD>

marco.hammel@sap.com

26

26

XML-Export im SAP DataWarehouse

25. August 2008

<_-BIC_-UMS_WEST>100000.0</_-BIC_-UMS_WEST>

<_-BIC_-UMS_OST>300000.0</_-BIC_-UMS_OST>

<_-BIC_-UMS_SUED>500000.0</_-BIC_-UMS_SUED>

<RECORDMODE /> </item>

- <item> <_-BIC_-ZDOM_FIRM>Spielwaren Klaus</_-BIC_-ZDOM_FIRM>

<_-BIC_-FIRMJAHR>2006</_-BIC_-FIRMJAHR>

<_-BIC_-UMS_NORD>9000.0</_-BIC_-UMS_NORD>

<_-BIC_-UMS_WEST>10000.0</_-BIC_-UMS_WEST>

<_-BIC_-UMS_OST>6000.0</_-BIC_-UMS_OST>

<_-BIC_-UMS_SUED>6000.0</_-BIC_-UMS_SUED>

<RECORDMODE /> </item>

- <item> <_-BIC_-ZDOM_FIRM>Spielwaren Klaus</_-BIC_-ZDOM_FIRM>

<_-BIC_-FIRMJAHR>2007</_-BIC_-FIRMJAHR>

<_-BIC_-UMS_NORD>10000.0</_-BIC_-UMS_NORD>

<_-BIC_-UMS_WEST>12000.0</_-BIC_-UMS_WEST>

<_-BIC_-UMS_OST>7000.0</_-BIC_-UMS_OST>

<_-BIC_-UMS_SUED>8000.0</_-BIC_-UMS_SUED>

<RECORDMODE /> </item>

- <item> <_-BIC_-ZDOM_FIRM>Suessigkeiten Mueller</_-BIC_-ZDOM_FIRM>

<_-BIC_-FIRMJAHR>2006</_-BIC_-FIRMJAHR>

<_-BIC_-UMS_NORD>2600000.0</_-BIC_-UMS_NORD>

<_-BIC_-UMS_WEST>9000000.0</_-BIC_-UMS_WEST>

<_-BIC_-UMS_OST>510000.0</_-BIC_-UMS_OST>

<_-BIC_-UMS_SUED>22000000.0</_-BIC_-UMS_SUED>

<RECORDMODE /> </item>

- <item> <_-BIC_-ZDOM_FIRM>Suessigkeiten Mueller</_-BIC_-ZDOM_FIRM>

<_-BIC_-FIRMJAHR>2007</_-BIC_-FIRMJAHR>

<_-BIC_-UMS_NORD>800000.0</_-BIC_-UMS_NORD>

<_-BIC_-UMS_WEST>1000000.0</_-BIC_-UMS_WEST>

<_-BIC_-UMS_OST>500000.0</_-BIC_-UMS_OST>

<_-BIC_-UMS_SUED>20000000.0</_-BIC_-UMS_SUED>

<RECORDMODE /> </item> </DATA> </asx:values> </asx:abap>

2. Konvertierungsmethode der Klasse CL_RSB_FILE_TYPE_XML:

METHOD convert.

DATA: l_v_tranid l_v_result l_v_fopt l_v_count l_same_cp l_r_ifbwriter

marco.hammel@sap.com

TYPE cXSLTdesc, TYPE string, TYPE rsb_foption, TYPE int4, TYPE rs_bool, TYPE REF TO if_sxml_writer,

27

27

XML-Export im SAP DataWarehouse

25. August 2008

 

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'. l_v_tranid = me->get_p_tranid( ). WHEN '1'.

"customer specific

"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 ).

marco.hammel@sap.com

28

28

XML-Export im SAP DataWarehouse

ENDTRY.

25. August 2008

*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

marco.hammel@sap.com

29

29

XML-Export im SAP DataWarehouse

CL CL_RSB_FILE_TYPE_ASCII

CL

CL_RSB_FILE_TYPE_CSV

CL

CL_RSB_FILE_TYPE_XML

Hinweise

25. August 2008

Im Paket RSB wurde ein Paketschnittstelle zum Paketinterface SXML_Core implementiert.

Weiterführende Informationen

Klassen:

implementiert. Weiterführende Informationen Klassen: CL_RSB_FILE_TYPE CL_SXML_Writer Glossar: 1. Online

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.

marco.hammel@sap.com

30

30

XML-Export im SAP DataWarehouse

25. August 2008

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

marco.hammel@sap.com

31

31

XML-Export im SAP DataWarehouse

25. August 2008

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)

marco.hammel@sap.com

32

32

XML-Export im SAP DataWarehouse

19.

25. August 2008

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/

marco.hammel@sap.com

33

33