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

Funktion des betrieblichen Betreuers / der betrieblichen Betreuerin: Senior Develper

Unterschrift des betrieblichen Betreuers / der betrieblichen Betreuerin:

XML-Export im SAP DataWarehouse 25. August 2008

[email protected]

1

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.

XMarco Hammel

Student der Wirtschaftsinformatik


[email protected]

2

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


[email protected]

3

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


[email protected]

4

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


[email protected]

5

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


[email protected]

6

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,


[email protected]

7

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


[email protected]

8

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


[email protected]

9

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


[email protected]

10

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


[email protected]

11

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.


[email protected]

12

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


[email protected]

13

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.


[email protected]

14

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.


[email protected]

15

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.


[email protected]

16

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


[email protected]

17

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


[email protected]

18

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


[email protected]

19

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:


[email protected]

20

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


[email protected]

21

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


[email protected]

22

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.


[email protected]

23

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


[email protected]

24

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


[email protected]

25

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


[email protected]

26



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




[email protected]

27




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


[email protected]

28

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


[email protected]

29

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


[email protected]

30

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.


[email protected]

31

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


[email protected]

32

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)


[email protected]

33

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/

SAP OpenHub XML Export

Documents

Transcript of SAP OpenHub XML Export