ETL-Prozess zum Datenaustausch zwischen SAP BW und relationalen Datenbanken

Inhaltsverzeichnis

Abstract

1. Einleitung
1.1 Zielsetzung und Abgrenzung
1.2 Aufbau der Arbeit
1.3 Überblick

2. Grundlegende Technologien
2.1 Relationale Datenbanksysteme (RDBS)
2.2 Data Warehouse
2.2.1 Definition
2.2.2 Nutzen
2.2.3 Abgrenzung des Begriffs Business Intelligence
2.3 Extract, Transform & Load (ETL)
2.3.1 Extraktion
2.3.2 Transformation
2.3.3 Laden
2.4 SAP Business Warehouse
2.4.1 Extraktionsschicht
2.4.2 Data-Warehouse-Schicht

3. SAP BW Standardschnittstellen
3.1 DB Connect
3.2 XML-Schnittstelle
3.3 Universal Data Integration (UDI)
3.3.1 UD Connect
3.3.2 BI Java Software Development Kit (BI Java SDK)
3.4 File-Schnittstelle
3.5 Business Application Programming Interface (BAPI)
3.5.1 Remote Function Call (RFC)
3.5.2 BW Service Application Programming Interface (SAPI)
3.6 SAP Java Connector
3.6.1 SAP Java Resource Adapter
3.7 SAP Business Connector
3.7.1 Internet Communication Framework (ICF)
3.8 Open Hub Services
3.9 Eignung der Schnittstellen für die Umsetzung
3.9.1 Import
3.9.2 Export

4. Evaluierung von 3rd-party-ETL-Tools
4.1 Xtract IS
4.2 Palo Suite
4.3 Pentaho Data Integration
4.4 Talend Open Studio
4.5 Sonstige
4.6 Fazit

5. Export der Daten aus SAP BW
5.1 Vorbereitung in SAP BW
5.1.1 InfoCube anlegen
5.1.2 Data Store Objekt anlegen
5.2 Vorbereitung in Palo ETL
5.2.1 Variablen
5.2.2 Verbindungen
5.3 Extraktion der Daten
5.4 Aufbereiten der Daten für die Berechnung

6. Berechnung der Prognosen
6.1 Java
6.2 Anforderungen an die Anwendung
6.3 Entwicklung der Anwendung
6.4 Funktionalität der Anwendung
6.4.1 Funktionen und Erweiterungen im Überblick

7. Import der Prognosen in SAP BW
7.1 Export der Prognosewerte in ein Flat File
7.2 Erstellen eines neuen InfoCubes in SAP BW
7.3 Erstellung einer DataSource für die Flat File
7.4 Import der berechneten Daten

8. Zusammenfassung
8.1 Fazit
8.2 Erweiterungsmöglichkeiten
8.2.1 Dynamischer Exportprozess
8.2.2 Automatisierung des Reimports
8.2.3 ETL-Controller Update

Abkürzungsverzeichnis

Abstract

Abbildung in dieser Leseprobe nicht enthalten

Diese Bachelorarbeit zeigt den Entwurf und die Realisierung eines ETL-Prozesses, worüber ein automatisierter Datenexport aus SAP BW in eine relationale Datenbank durchgeführt wird

Zu Beginn werden verschiedene ETL-Tools aus dem SAP- und NON-SAP Umfeld gegenübergestellt und bewertet. Die Realisierung des ETL-Prozesses wird beispielhaft mit einem der evaluierten ETL-Tools durchgeführt. Desweiteren wird ein Prototyp einer Software zur Berechnung von Prognosen erstellt. Die berechneten Prognosen werden im Anschluss über eine File-Schnittstelle aus der Datenbank zurück in das SAP Business Warehouse geladen

Neben den Extraktionsmöglichkeiten werden wichtige grundlegende Technologien aus dem SAP und NON-SAP Umfeld vorgestellt, die bei der Umsetzung zum Einsatz kommen. Die Extraktion, Transformation und das Loading findet zwischen dem SAP BW System und einer relationalen Datenbank statt. Bei der Beschreibung der Umsetzung geht der Autor hauptsächlich auf die Möglichkeiten der Extraktion von Daten aus dem SAP BW System ein

Die letztliche Betrachtung der Arbeit bringt das Ergebnis, dass die Anforderungen an den ETL-Prozess erfüllt und die Datenlieferung aus dem BW mit Hilfe des 3rd-Party-Tools Palo ETL automatisiert werden kann

Kapitel 1 Einleitung

In SAP BW werden Daten aus verschiedenen Quellsystemen gesammelt, strukturiert und ausgewertet. Der Import von Daten in das SAP BW stellt aufgrund der von SAP bereitgestellten Schnittstellen keine große Schwierigkeit dar. Diese Importschnittstellen ermöglichen ohne weiteren Programmieraufwand eine direkte Anbindung von Fremdsystemen und relationalen Datenbanken an das SAP BW System. Ein Import von Daten kann dadurch sehr einfach durchgeführt werden.

Deutlich anspruchsvoller ist dagegen der Export von Daten aus dem SAP BW, da der Hersteller SAP keine fertigen Exportschnittstellen für die direkte Anbindung von Fremdsystemen bereitstellt. Um dennoch direkte Schnittstellen für Fremdsysteme zu schaffen, müssen diese manuell programmiert werden. Bei der Entwicklung ist man auf die offengelegten Bausteine der BAPI-Schnittstelle angewiesen, für die neben einem guten technischen Wissen auch umfassende Programmierkenntnisse erforderlich sind. Nicht jedes Unternehmen besitzt ausreichend qualifizierte, personelle Ressourcen, um solch eine Schnittstelle selbständig zu entwickeln.

Im Zuge dieser Arbeit soll eine möglichst einfache Variante für eine Datenextraktion aus SAP BW über 3rd-party-ETL-Tools gefunden werden. Anhand eines Beispielprozesses wird praxisnah dargestellt, wie ein automatisierter Datenexport aus SAP BW ohne zusätzlichen Programmieraufwand realisiert werden kann. In dem Beispielprozess werden Daten aus einem SAP BW System via 3rd-party-ETL-Tool exportiert und in einer relationalen Datenbank abgespeichert.

Um einen wirtschaftlichen Nutzen in diesem Beispiel erkennen zu können, soll beispielhaft eine zusätzliche Software entwickelt werden, die aus den exportierten Daten Prognosen berechnet und diese dem SAP BW in Form von Flat Files für den Reimport bereitstellt.

1.1 Zielsetzung und Abgrenzung

Das Ziel dieser Bachelorarbeit ist die Evaluierung von ETL-Tools und die anschließende prototypische Entwicklung eines ETL-Prozesses.

Bei der Evaluierung soll ein Vergleich und eine Bewertung zwischen SAP-Data Retrieval Tools und NON-SAP ETL-Tools durchgeführt werden. Bei der Bewertung der Tools wird hauptsächlich auf die möglichen Schnittstellen zu SAP BW eingegangen.

Der ETL-Prozess, welcher eine Faktentabelle aus dem SAP Business Warehouse extrahiert, transformiert und danach in einer relationalen Datenbank abspeichert, soll beispielhaft mit einem der evaluierten Tools umgesetzt werden. Inhalt und Struktur der Faktentabelle sollen durch eine oder mehrere Transformationen so aufbereitet werden, dass anhand der Werte eine Berechnung der Umsatzprognose problemlos durchgeführt werden kann.

Desweiteren soll beispielhaft eine prototypische Anwendung entwickelt werden, die eine einfache Berechnung einer Umsatzprognose aus den vorliegenden Daten ermöglicht. Die berechneten Zukunftswerte sollen in eine Flat File exportiert und von dort aus weiter in das SAP BW System geladen werden. Die Berechnung der Prognose wird in dieser Arbeit nur beispielhaft für den Umsatz durchgeführt.

Das Zurückschreiben der berechneten Zukunftswerte von der DB in das BW wird aus benutzerrechtlichen Gründen über Flat Files realisiert. Die Daten sollen dabei in einen separaten InfoCube geladen werden, welcher ausschließlich für die berechneten Prognose- werte bestimmt ist.

1.2 Aufbau der Arbeit

In Kapitel 2 werden zunächst die grundlegenden Technologien beschrieben, die für den Entwurf und die Realisierung des ETL-Prozesses relevant sind.

Bevor auf die genaue Umsetzung des Prozesses eingegangen wird, werden in Kapitel 3 und 4 die für die Realisierung zur Auswahl stehenden ETL-Tools evaluiert. Dabei werden SAPeigene ETL-Werkzeuge und 3rd-party-ETL-Tools vorgestellt und bewertet.

Die Umsetzung des Datenexports aus SAP BW mit Hilfe eines geeigneten ETL-Tools wird in Kapitel 5 beschrieben.

In dem darauf folgenden Kapitel 6 wird auf die Entwicklung der Anwendung eingegangen, die anhand der exportierten Daten eine Berechnung von Umsatzprognosen durchführt.

Kapitel 7 beschreibt mit dem Zurückschreiben der berechneten Prognosewerte in das SAP BW, die letzte Phase des ETL-Prozesses.

Eine abschließende Zusammenfassung und Bewertung der Ergebnisse findet in Kapitel 8 statt.

1.3 Überblick

Bevor in Kapitel 2 die grundlegenden Technologien beschrieben werden, wird in diesem Abschnitt ein beispielhafter Ablauf des ETL-Prozesses dargestellt. Wie man anhand der Abbildung 1-1 deutlich erkennen kann, dient das SAP BW System mit seinen InfoCubes und Data Store Objekten als Datenquelle für das ETL-Tool. Die Daten der Faktentabelle des InfoCubes sollen in diesem Beispiel via ETL-Tool aus dem SAP BW System exportiert und aufbereitet werden. Dazu müssen die Daten zuerst aus dem mehrdimensionalen InfoCube in ein Data Store Objekt mit flachen Tabellen geladen werden. Dieses Data Store Objekt befindet sich, wie der InfoCube auch, innerhalb des SAP BW Systems. Über eine geeignete Schnittstelle kann das ETL-Tool von außen auf die flache Tabelle des Data Store Objekts zugreifen und die benötigten Daten so aus dem SAP BW System extrahieren. Die extrahierten Daten werden daraufhin in mehreren Schritten transformiert und für die Berechnung der Prognosen aufbereitet. Die aufbereiteten Daten werden nach der Transformation durch den ETL-Prozess in eine relationale Datenbank geschrieben, von wo aus sie dann einer Anwendung zur Berechnung der Prognosen bereitgestellt werden. Die auf Java basierende Anwendung ermöglicht dem Benutzer die Eingabe verschiedener Kriterien, über die die Berechnung beliebig eingeschränkt werden kann.

Nach Berechnung der Prognosen legt die Anwendung die berechneten Daten erneut in der relationalen Datenbank ab. Um die Daten in das SAP BW Systemen zurückzuladen, bietet die Anwendung eine Exportfunktion an, welche die berechneten Daten in ein Flat File extrahiert. Über dieses Flat File können die Daten wieder problemlos über die File-Schnittstelle in das SAP BW System zurückgeführt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1-1 Prozessüberblick

Kapitel 2 Grundlegende Technologien

Um die Realisierung des ETL-Prozesses zu erläutern, bedarf es dem Verständnis einiger grundlegender Technologien aus dem Datenbankumfeld, die in diesem Kapitel beschrieben werden.

2.1 Relationale Datenbanksysteme (RDBS)

Datenbanksysteme werden heutzutage in fast allen größeren Unternehmen für die Informationsverwaltung eingesetzt. Ein relationales Datenbanksystem besteht aus einer relationalen Datenbank und einer zusätzlichen Systemkomponente, welche für die Verwaltung der Datenbasis zuständig ist. Nach der Auffassung von A. Kemper¹ werden diese zwei Komponenten oftmals nicht sonderlich getrennt voneinander betrachtet, so dass unter dem Begriff Datenbanksystem sowohl die Datenbasis, als auch die Verwaltung der Datenbasis zu verstehen ist. Beliebte Beispiele für relationale Datenbanksysteme sind Oracle Database Server, MySQL-Server, MSSQL-Server und DB2.

2.2 Data Warehouse

In den 60er Jahren wurden die ersten Systeme entwickelt, die das Management sowohl bei alltäglichen Geschäftsprozessen als auch bei wichtigen Entscheidungen unterstützen sollten. Diese Systeme wurden damals unter den Begriffen Management-Informationssysteme (MIS), Führungsinformationssysteme (FIS) oder Executive Information System (EIS) eingeführt. Nach der Auffassung des Autoren Bauer A. und Günzel H.², gelang den Systemen der Durchbruch zu diesem Zeitpunkt jedoch aufgrund technischer Defizite nicht.

Mitte der 90er Jahre wurde eine neue Generation von MIS eingeführt, die speziell für die Problematik der Entscheidungsunterstützung entwickelt wurde. Im Jahre 1992 stellte Inmon W. H. unter dem Namen Data Warehouse einen wichtigen Ansatz zu dieser Unterstützung vor. In der folgenden Abbildung ist die Architektur von entscheidungsorientierten Informationssystemen abgebildet:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-1 Architektur eines entscheidungsorientierten Informationssystems ³

Ende der 90er Jahre führte man für Systeme, die komplexe betriebswirtschaftliche Analysen durchführten, den Begriff Business Intelligence ein.

2.2.1 Definition

Eine allgemein offiziell gültige Standard-Definition für den Begriff Data Warehouse gibt es nicht. Die jedoch beliebteste Definition stammt von Inmon, aus dem Jahre 1996. Nach Inmon wird der Begriff Data Warehouse folgendermaßen definiert:

“ A data warehouse is a subject-orientated, integrated, time-varying, non-volatile collection of data that is used primarily in organizational decision making. “ ⁴

(Ein Data Warehouse ist eine themenorientierte, integrierte, zeitbezogene und dauerhafte Ansammlung von Informationen, die vor allem bei organisatorischen Entscheidungen verwendet wird.)

Die Autoren A. Bauer und H. Günzel des Buches Data Warehouse Systeme⁵ sind der Ansicht, dass die Definition von Inmon nicht aussagekräftig genug ist und sie daher in der Praxis keine Verwendung finden kann. Die folgende Definition der Autoren Bauer und Günzel richtet sich speziell nach dem Aspekt der Analysefunktion:

“ Ein Data-Warehouse ist eine physische Datenbank, die eine integrierte Sicht auf beliebige Daten darstellt, um Analysen zu ermöglichen “ ⁶

2.2.2 Nutzen

In vielen operativen Systemen findet man enorme Datenmengen, die sich aufgrund ihrer Eigenschaften nicht für eine direkte Datenanalyse eignen. Durch den Einsatz eines Data Warehouse Systems können die Daten aus dem operativen System in das Data Warehouse geladen, redundant abgespeichert, aufbereitet und ausgewertet werden. Die operativen Systeme können so performant weiterarbeiten und werden durch die Analysen keineswegs in ihrer Leistung beeinträchtigt. Diese Fähigkeit erzeugt einen enormen Mehrwert für den Anwender und zeichnet so den Hauptnutzen des Data Warehousings aus.

Ein DWHS fügt fragmentierte Informationen aus den wichtigsten Systemen der Wertschöpfungskette zusammen und ermöglicht es, auf allen Unternehmensebenen schnelle und gezielte Entscheidungen zu treffen.⁷

2.2.3 Abgrenzung des Begriffs Business Intelligence

Business Intelligence stellt eine Ergänzung zum Data Warehousing dar. Insbesondere sind damit die Anwendungsebene und die anwendungsseitigen Prozesse gemeint. Im BI-Umfeld existieren bereits einige Definitionen wie z.B. die Definition laut Kemper⁸, der den Begriff Business Intelligence wie folgt definiert:

„ Unter Business Intelligence (BI) wird ein integrierter, unternehmensspezifischer, IT-basierter Gesamtansatz zur betrieblichen Entscheidungsunterstützung verstanden. “

Bei BI wird das Thema Integration erweitert, da neben der Datenintegration zusätzlich Strategien, Anwendungen, Technologien und Prozesse integriert werden. Ebenso wird die reine Datenanalyse um die Erhebung von Prognosen, Potenziale und Perspektiven im Geschäftsumfeld erweitert.⁹

2.3 Extract, Transform & Load (ETL)

Die Überführung von Daten aus internen und externen Quellsystemen in ein Data Warehouse wird unter dem Begriff ETL zusammengefasst. Der ETL-Prozess setzt sich aus den in Abbildung 2-2 dargestellten drei Phasen zusammen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-2 ETL-Prozess¹⁰

2.3.1 Extraktion

Bei der Extraktion werden Daten aus den angebundenen Datenquellen selektiert und in einen Zwischenspeicher überführt. In diesem als Staging Area bezeichneten Zwischenspeicher werden anschließend die Transformationsaufgaben ausgeführt.

Zuerst werden alle Datensätze und Tabellen, die aus den angebundenen Quellsystemen geladen werden sollen, selektiert. Dafür muss eine Anbindung der Quellsysteme über eine geeignete Schnittstelle gewährleistet sein. Die selektierten Daten werden aus den Quellsystemen in die Staging Area überführt und dort wie nachfolgend beschrieben transformiert.¹¹

2.3.2 Transformation

Die aus den Quellsystemen extrahierten Daten werden während des Transformationsprozesses so aufbereitet, dass sie in der nächsten Phase nur noch in das Data Warehouse geladen werden müssen. Bei der Aufbereitung wird zunächst eine Filterung der Daten durchgeführt, um die richtigen Daten zu validieren und falsche Daten zu identifizieren. Die gefilterten Daten werden auf inhaltliche und technische Standards harmonisiert und so an die vorgegebenen Schema- und Qualitätsanforderungen angepasst.

Zusätzlich können die Daten mit betriebswirtschaftlichen Kennzahlen angereichert werden, die nicht direkt in den Basisdaten enthalten sind.¹²

2.3.3 Laden

Nach einer erfolgreichen Transformation lädt der Ladeprozess die transformierten Daten periodisch in das Data Warehouse. Der Ladeprozess kann je nach Anforderung wöchentlich, täglich oder in Echtzeit (Real-Time) erfolgen. Im Falle von Real-Time wird das Quellsystem ständig auf neue Daten geprüft. Sind neue Daten vorhanden, wird automatisch ein Ladeprozess eingeleitet, der diese Daten in das Data Warehouse lädt. Das zeitgesteuerte Laden von Daten kann auch als Schedule bezeichnet werden. ¹³

2.4 SAP Business Warehouse

Das Business Information Warehouse (BW) stellt die Data-Warehouse-Lösung der SAP® AG dar und folgt dabei mit seiner Architektur dem klassischen Data-Warehouse-Schichtenmodell. In Abbilung 2-3 ist die Architektur des SAP BW in folgende drei Schichten aufgeteilt:

- Extraktionsschicht
- Data Warehouse (SAP BW Server)
- Decision Support Systeme (Enterprise Portal)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-3 SAP BW Architektur¹⁴

Da in dieser Arbeit eine Evaluation von Extraktionsmöglichkeiten aus dem Data Warehouse SAP BW durchgeführt werden soll, beschränkt sich der Autor bei der genaueren Erläuterung auf die Schichten Extraktion und Data Warehouse.¹⁵

2.4.1 Extraktionsschicht

Wie schon in Kapitel 2.3 beschrieben, ist für die regelmäßige Aktualisierung der Daten im Data Warehouse ein ETL-Prozess zuständig. Dieser extrahiert die Daten aus den verschiedenen Quellsystemen und legt sie dann unverändert in der Eingangsschicht des Data Warehouse, der Persistent Staging Area (PSA), ab. Die folgende Abbildung zeigt die verschiedenen Arten von operativen Quellsystemen, die an ein SAP BW System angebunden werden können:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-4 SAP BW Extraktionsschicht¹⁶

Auf die einzelnen Kommunikationsschnittstellen wird in Kapitel 3 noch genauer eingegangen.¹⁷

2.4.2 Data-Warehouse-Schicht

Die im PSA abgelegten und unbereinigten Daten werden über einen Datentransferprozess (DTP) transformiert, bereinigt und danach auf Grundlage von drei konzeptionellen Schichten des Data-Warehousing applikationsneutral abgelegt:

- Das Data Warehouse ist aufgrund der Bereitstellung von integrierten, granularen, historischen und stabilen Daten, die zentrale Komponente eines Data Warehouse - Systems. Diese Schicht ermöglicht den Aufbau von konsistenten Reporting- Strukturen.
- Architected Data Marts hingegen sind zwar eng mit dem Data Warehouse verknüpft, häufig aber für OLAP-Analysen optimiert. Diese Schicht ist daher für die Erstellung von multidimensionalen Reporting-Strukturen geeignet.
- Für das operative, zeitnahe und sehr detaillierte Reporting wird häufig der Operational Data Store (ODS) als Speicheroption eingesetzt.

Seit SAP BI 7 wurde das Operational Data Storage (ODS) Objekt durch das Data Store Objekt (DSO) ersetzt. Beide Objekte können fortwährend bzw. in kurzen Zeitabständen Daten aufnehmen und diese dem operativen Reporting zur Verfügung stellen. Die aufgenommenen Daten werden in flachen Tabellen abgespeichert, um so eine einfachere Datenanalyse bzw. ein einfacheres Reporting zu ermöglichen. In DSO/ODS-Objekten existieren deshalb keine Dimensionen und keine Faktentabellen.¹⁸

Kapitel 3 SAP BW Standardschnittstellen

In diesem Kapitel werden die wichtigsten Import- und Exportschnittstellen des SAP BW vorgestellt und bewertet. Zuerst werden die Importschnittstellen, der in Kapitel 2.4.1 angeschnittenen Extraktionsschicht vorgestellt. Die Schnittstellen der Extraktionsschicht dienen hauptsächlich der einfachen Datenextraktion aus Quellsystemen und dem anschließenden Import der Daten in das SAP BW.

Die Extraktion von Daten aus dem SAP BW stellt für den Anwender eine Herausforderung dar. Aufgrund der teilweise nur aus einer API bestehenden Exportschnittstellen, ist ein Datenexport ohne zusätzlichen Programmieraufwand nicht möglich. Im letzten Abschnitt werden die Schnittstellen gegenübergestellt und nach Eignung für die Umsetzung des ETL- Prozesses ausgewertet.

3.1 DB Connect

Nach der Auffassung von Mehrwald¹⁹, ermöglicht DB Connect eine direkte Anbindung von Datenbanken an das SAP BW System und somit auch eine direkte Extraktion der Daten aus den Tabellen oder Views in das System. Das BW greift dabei als Datenbank-Client direkt auf das angebundene Datenbanksystem zu, was zu einem äußerst performanten Zugriff führt. Diese Schnittstelle dient rein dem Import der Daten in das BW.

Um SAP BW an ein fremdes Datenbanksystem über DB Connect anzubinden, muss zuvor ein datenbankspezifischer Client und eine Datenbankbibliothek für den SAP-Kernel, auch Database Shared Library (DBSL) genannt, auf dem SAP Web Applikationsserver installiert werden. Die DBSL unterstützt nur die Datenbanksysteme, die auch SAP BW zur Speicherung der eigenen Daten nutzt. Deshalb werden ausschließlich die Datenbanksysteme Oracle, Microsoft SQL Server, Informix und DB2 bei der Anbindung unterstützt. Für die Installation des Clients und der DBSL auf dem SAP Web Applikationsserver werden zwingend Administrationsrechte benötig. Die Architektur von DB Connect wird in Abbildung 3-1 verdeutlicht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-1 Architektur von DB-Connect²⁰

3.2 XML-Schnittstelle

Hinter der XML-Schnittstelle steckt ein Webservice, der sogenannte SOAP-Service. Über diesen Service kann das BW mit XML-Dokumenten, die mit Daten gefüllt sind, beliefert werden. Der SOAP-Service nutzt bei der Übertragung der XML-Dateien nicht das Standard- SOAP, sondern ein von SAP modifiziertes SOAP-Protokoll. Dieses Protokoll basiert auf der SAP-eigenen XI-Technologie, welche extra für den Datenaustausch zwischen heterogenen Systemen entwickelt wurde. Nach Mehrwald²¹ ist es daher nur dann sinnvoll eine Extraktion über diese Schnittstelle durchzuführen, wenn ein XI-System zwischen Quellsystem und SOAP-Service geschaltet ist. Andernfalls wäre der Aufwand sich an die Vorgaben des Protokolls zu halten so enorm groß, dass die Nutzung der Schnittstelle in Frage gestellt werden muss.

3.3 Universal Data Integration (UDI)

Unter dem Begriff Universal Data Integration versteht man den Ansatz des Kombinierens von Daten aus heterogenen Quellsystemen noch während der Extraktion. Für die Extraktion der Daten sind unterschiedliche BI Java Konnektoren zuständig, die von SAP BW zur Verfügung gestellt werden.

Folgende vier Java Konnektoren stehen für die Extraktion zur Auswahl:

Abbildung in dieser Leseprobe nicht enthalten²²

Tabelle 3-1 Java Konnektoren von UD Connect

Um die extrahierten Daten an das BW zu übergeben, wird von SAP die Schnittstellenkomponente UD Connect bereitgestellt. Über UD Connect werden die Daten in das BW integriert und schlussendlich im SAP Enterprise Portal bereitgestellt. Desweiteren bietet UDI mit der Entwicklungsumgebung BI Java SDK die Möglichkeit, eine eigene Anwendung zu entwickeln, über die dann - sofern gewünscht - die Daten auch im SAP Enterprise Portal bereitgestellt werden können.²³

In der folgenden Abbildung wird die Architektur von UDI dargestellt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-2 Universal Data Integration²⁴

3.3.1 UD Connect

Die Schnittstelle UD Connect (Universal Data Connect) ist Bestandteil des J2EE-Connection Frameworks, welches wiederum der neuen Applikationsplattform, dem J2EE-Server, angehört. Mit Hilfe der Applikationsserver J2EE-Konnektivität ermöglicht UD Connect eine Anbindung von so gut wie jeder relationalen als auch multidimensionalen Datenquelle an das BW System. Die über Java-Konnektoren extrahierten Daten werden von UD Connect in einem flachen Format an das BW übergeben. Daten aus multidimensionalen OLAP- Datenquellen müssen vor der Übertragung in das BW zuerst in ein flaches Datenformat überführt werden.

Die Schnittstelle UD Connect zeichnet sich darin aus, dass im Gegensatz zu DB Connect neben den relationalen auch noch multidimensionale Quellen angebunden werden können.²⁵

3.3.2 BI Java Software Development Kit (BI Java SDK)

Die Einführung des BI Java SDK brachte nicht nur die einfachere Programmierung durch eine Java-Umgebung mit sich, sondern ermöglichte zudem die Nutzung der APIs zur Anbindung von Datenquellen.

Mit Hilfe des objektorientierten Frameworks können analytische Anwendungen entwickelt werden, die einen direkten Zugriff auf BW-fremde und sogar OLAP-fremde Datenquellen, wie relationale JDBC-Datenquellen, über die BI Java SDK-eigenen APIs ermöglichen.

3.4 File-Schnittstelle

Die File-Schnittstelle stellt in heterogenen Systemwelten die älteste gemeinsame Schnittstelle für den Datenaustausch dar. SAP-R/3 Systeme vor dem Release 3 konnten nur über diese Schnittstelle mit anderen Systemen kommunizieren.

Im Fall von SAP BW wird die File-Schnittstelle hauptsächlich für den Datenaustausch mit NON-SAP-Systemen eingesetzt. Dafür werden ausschließlich CSV- oder ASCII-Dateien mit einer flachen Struktur, auch Flat Files genannt, verwendet. Ein Beispiel für eine Comma Seperated Values (CSV) Datei zeigt die folgende Abbildung.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-3 Beispiel für ein CSV-Flat File

Durch den flachen Aufbau der Dateistruktur ist gewährleistet, dass jeder Datensatz in der Datei gleichermaßen aufgebaut ist.

Flat Files eignen sich im Gegensatz zu vielen anderen Schnittstellen auch für den Austausch großer Datenmengen. Quellsysteme die große Datenmengen bereitstellen, nutzen daher oftmals die File-Schnittstelle als einfachste, performanteste und günstigste Lösung.²⁶

3.5 Business Application Programming Interface (BAPI)

Das Business Application Programming Interface (BAPI) ist eine Technologie, die für den Austausch von Daten zwischen SAP-konformen Systemen eingesetzt wird. Die BAPI bietet eine Reihe von Schnittstellen und Funktionen an, über die sowohl Drittanbieter als auch SAP selbst auf SAP-Systeme zugreifen können.

Beim Zugriff auf ein System über das BAPI, wird aus technischer Sicht ein Remote Function Call (RFC) ausgeführt.²⁷

3.5.1 Remote Function Call (RFC)

Ein entfernter Funktionsaufruf (Remote Function Call) bietet SAP-Systemen sowie Fremdsystemen die Möglichkeit, Funktionsbausteine auf einem entfernten SAP-System auszuführen. In Hinsicht auf den Datenaustausch zwischen Systemen ist der RFC nicht auf die offengelegten Funktionsbausteine der BAPI-Schnittstelle angewiesen. Ein RFC hat zusätzlich zu den BAPIs noch die Funktionalität, über seine eigene Schnittstelle undokumentierte und nicht-offengelegte Funktionsbausteine aufzurufen.

SAP-BW stellt dafür folgende Aufrufschnittstellen bereit:

- Aufrufschnittstelle für ABAP-Programme

Bei der Ausführung von RFCs zwischen SAP-Systemen muss der Funktionsaufruf lediglich durch die zusätzliche Angabe des Zielsystems erweitert werden. Beide Programme sprechen dieselbe Sprache und können daher problemlos miteinander kommunizieren.

Beispiel: CALL FUNCTION...DESTINATION

- Aufrufschnittstelle für Nicht-ABAP-Programme

Eine Ausführung von RFCs zwischen unterschiedlichen Systemen stellt für den Entwickler in Hinblick auf die Komplexität eine größere Herausforderung dar. Er hat das Nicht-ABAP-Programm so anzupassen, dass dieses die gewünschte Rolle in der RFC-Kommunikation übernehmen kann. Diese Anpassung ist aufgrund unterschiedlicher Technologien oftmals recht schwierig und meist nur durch weitere SAP Komponenten wie z. B. dem SAP Java Connector möglich.

Um einen Funktionsbaustein entfernt aufrufen zu können, muss dieser in dem entfernten System als „entfernt“ (remote) gekennzeichnet werden.

Systeme, die sich zum Beispiel aus Gründen der Zertifizierung auf die reine Nutzung der BAPIs einschränken müssen, sind gegenüber denjenigen, die die BAPI auch umgehen können, benachteiligt.²⁸

3.5.2 BW Service Application Programming Interface (SAPI)

Das BW Service API ist ein Technologie-Paket, welches ab Version 3.0 in allen SAP- Systemen existiert und das Ziel verfolgt, die Integration der Datenübertragung in das BW zu erhöhen. Bei einer Extraktion von Daten aus einem SAP-Quellsystem in das BW ermöglicht das quellseitige Service API eine generische Datenextraktion und darüber hinaus, über die mögliche RemoteCube-Unterstützung, auch einen direkten Zugriff auf das SAP-Quellsystem. Durch den zusätzlichen Einsatz von intelligenten Delta-Verfahren, die ebenfalls von der SAPI unterstützt werden, kann die Transportlast minimiert und so die Datenübertragung optimiert werden. Die Abbildung 3-4 zeigt die Extraktion der Daten aus den Quellsystemen mit Hilfe der Service API und die anschließende Weitergabe der Daten an das Data Warehouse über die BAPI-Schnittstelle.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-4 Übersicht Service API²⁹

3.6 SAP Java Connector

Der SAP Java Connector (SAP JCo) ist eine leistungsstarke, von SAP zertifizierte Middleware-Komponente, die von SAP für die Entwicklung SAP-kompatibler Java Komponenten und Java Anwendungen bereitgestellt wird. Die Komponente ermöglicht eine beidseitige Kommunikation mit dem ABAP Applikationsserver und so auch die Ausführung von in- und outbound-Funktionsaufrufen. Bei einer inbound-Kommunikation werden aus einer Java Anwendung heraus, über den SAP JCo, die gewünschten BAPIs oder RFCs im SAP-System aufgerufen. Bei der outbound-Kommunikation hingegen ruft das SAP-System bzw. das ABAP-Programm über den SAP JCo den Java Server auf.

Anhand folgender Abbildung wird die Kommunikation zwischen einer Java Anwendung und einem SAP-System verdeutlicht:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-5 Kommunikation SAP Java Connector³⁰

Beim Aufruf einer Java Methode wird diese über das JCo Java API und das Middleware Interface an die RFC-Middleware übergeben. Dort findet mit Hilfe des Java Native Interface (JNI) die Konvertierung der Java Methode in einen ABAP-Aufruf (RFC) statt. Dieser wird über die RFC-Library an das SAP-System übergeben und ausgeführt. Der umgekehrte Weg sieht ähnlich aus. Die RFCs werden hier in Java Methoden umgewandelt und an die Java Applikation übergeben.

Die Installation des SAP JCo ist sehr einfach und kann ohne großen Aufwand in Anwendungen von Drittanbietern implementiert werden.³¹

3.6.1 SAP Java Resource Adapter

Der SAP Java Resource Adapter (SAP JRA) stellt eine Schnittstellenerweiterung zu dem gewöhnlichen SAP Java Connector dar. Bei dem SAP JRA sind zusätzlich Java EE Standard- Schnittstellen auf dem SAP JCo implementiert, die eine Integration von SAP-Systemen (ABAP) mit entfernten SAP Java EE Applikationsservern zulassen. SAP JRA ist durch die zusätzlichen Schnittstellen Java EE-kompatibel, was die Kommunikation zwischen heterogenen, verteilten SAP Java Anwendungen und ABAP Applikationsservern vereinfacht.³²

3.7 SAP Business Connector

Der SAP Business Connector ermöglicht eine Kommunikation zwischen SAP-Systemen und Fremdsystemen über das HTTP-Protokoll. Dabei wird das SAP-eigene RFC-Format in ein plattformunabhängiges Format (XML oder HTML) umgewandelt, um so auch den unterschiedlichsten Systemen eine Kommunikation mit dem SAP-System zu ermöglichen. Der SAP BC ist eine eigenständige Software-Komponente, die ihren eigenen RFC-Client und RFC-Server mit sich bringt. Dank dieser Client/Server-Architektur ist eine bidirektionale Echtzeitkommunikation mit SAP-Systemen möglich.³³

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-6 SAP BC Kommunikation

3.7.1 Internet Communication Framework (ICF)

Seit der Einführung des Internet Communication Framework (ICF) ist der SAP Business Connector für die Umsetzung einfacher Anbindungsszenarien überflüssig geworden. Die Anbindung von Fremdsystemen an ein SAP-System via HTTP/XML kann nun standardmäßig über die ICF-Komponente des SAP Web Applikationsservers durchgeführt werden. So können über die im SAP-System verfügbaren HTTP-Ports, ohne weitere Unterstützung einer Middleware, RFC’s (Remote Function Call) via HTTP im XML-Format aufgerufen werden. Das ICF wird hauptsächlich für Web-Anwendungen mit Business Server Pages, die ein Request-Response Muster aufweisen, eingesetzt. Um eine HTTP-Request-Response Kommu- nikation zwischen Client und Server herzustellen, muss zusätzlich ein HTTP-Request-Handler im SAP-System angelegt werden.³⁴

[...]

---

¹ vgl. A. Kemper (1999), S. 15

² vgl. A. Bauer (2009), S. 11ff 4

³ vgl. C. Bange (2003), S. 08

⁴ vgl. A. Bauer (2009) S. 07

⁵ vgl. A. Bauer (2009)

⁶ vgl. A. Bauer (2009), S. 08

⁷ vgl. Egger (2006), S. 22

⁸ vgl. Kemper (2007), S. 01

⁹ vgl. Kemper (2007)

¹⁰ vgl. Bange C. (2003), S. 04

¹¹ vgl. Bange C. (2003)

¹² vgl. Bange C. (2003)

¹³ vgl. Bange C. (2003), S. 05

¹⁴ vgl. SAPa (2008)

¹⁵ vgl. Mehrwald (2007), S. 07 8

¹⁶ vgl. SAPb (2005)

¹⁷ vgl. Egger (2006) S. 25ff

¹⁸ vgl. Utech (2011)

¹⁹ vgl. Mehrwald (2007), S. 09f

²⁰ vgl. SAPe (2005)

²¹ vgl. Mehrwald (2007), S. 10

²² vgl. SAPd (2008)

²³ vgl. Egger (2006), S. 160

²⁴ vgl. Egger (2006), S. 160

²⁵ vgl. SAPf

²⁶ vgl. Mehrwald (2007), S. 09, S. 21

²⁷ vgl. Mehrwald (2007), S. 22

²⁸ vgl. SAPg (2008)

²⁹ vgl. Mehrwald (2007), S. 554

³⁰ vgl. SAPh (2011)

³¹ vgl. SAPi (2009)

³² vgl. SAPj (2009)

³³ vgl. SAPk (2009)

³⁴ vgl. Mehrwald (2007), S. 24f