Aufbau von Data Warehouse-Lösungen auf Basis von SAP R/3

Aufbau von Data Warehouse-Lösungen auf Basis von SAP R/3 Von Carsten Bange und Heiko D. Schinzer Moderne Standardanwendungssysteme wie R/3 bauen auf einer integrierten (relationalen) Datenbasis auf und bieten den Anwendern eine Fülle bereits integrierter Berichte. Dies wirft die Frage auf, warum dann viele Unternehmen dennoch nicht auf den Einsatz zusätzlicher Werkzeuge zur Entscheidungsunterstützung verzichten. Die wichtigsten Gründe für den Einsatz von Data Warehouse und Business Intelligence Lösungen im R/3-Umfeld sind: Systembelastung. Analytische Anfragen und Berichtsgenerierungen können operative Systeme so stark belasten, daß es zu einer spürbaren Beeinträchtigung der Transaktionskapazität kommt. Neben unkalkulierbar hohen Rechenzeiten durch komplexe join- Operationen sind auch die Zeitpunkte der Belastung nicht vorhersagbar, was dem Ziel einer möglichst gleichmäßigen Systembeanspruchung der operativen Systeme widerspricht. Flexibilität. Werden zusätzliche Informationen benötigt, die in den Standard-Berichten nicht enthalten sind, erfordert dies die Entwicklung neuer Berichte mit Hilfe der SAPspezifischen Programmiersprache ABAP/4. Ad-Hoc-Anforderungen können daher nicht bewältigt werden. Benutzerführung. Die Berichtsmöglichkeiten von SAP R/3 können nicht allen Benutzern entscheidungsorientierter Informationssysteme angeboten werden. Insbesondere sollten Anwender, die nicht täglich mit dem R/3 System arbeiten, mit intuitiveren Oberflächen arbeiten können. Funktionalität. Entscheidungsunterstützende Systeme bieten zahlreiche Funktionen, die in reinen Reporting Lösungen nicht verfügbar sind. Beispiele sind flexible Navigationsinstrumente, betriebswirtschaftliche Analysemethoden wie Prognosen, Abweichungsanalysen etc. oder komplexere Data Mining Verfahren. Zusätzliche Datenquellen. Schätzungen zufolge können in Unternehmen durchschnittlich nur 60-80% der entscheidungsrelevanten Daten aus operativen Transaktionssystemen wie R/3 gewonnen werden. Besondere Stärke des Data Warehouse ist die Integration von Daten aus verschiedensten internen und externen Quellen in einem einheitlichen Modell.

Zugriff auf eine SAP R/3-Datenbasis Das SAP R/3-System basiert auf einer 3 Tier-Client/Server-Architektur, die sich in Datenbank-, Applikations- und Präsentationsserver aufteilt. Diese Architektur gewährleistet eine hohe Flexibilität und Skalierbarkeit bei der Wahl der Betriebs- und Datenbanksysteme. Dem Datenbankserver obliegt dabei die Verwaltung aller Datenbestände im SAP-System. Allerdings werden nicht alle Daten so in der Datenbank abgespeichert, daß sie via SQL abrufbar sind. Neben den transparenten Tabellen existieren bei R/3 auch sogenannte Pool- und Cluster-Tabellen, die nicht immer exakt den physikalischen Tabellen entsprchen, wie sie im Datenbank-Server abgelegt sind. Oft werden mehrere logische SAP-Tabellen physikalisch in einer Tabelle komprimiert und nicht streng normalisiert abgespeichert. Dies erfolgt vor allem aus Platz- und teilweise Performance- Gründen und betrifft auch Bereiche, die beim Aufbau eines Data Warehouse betroffen sind. Beim direkten Zugriff auf Pool- und Clustertabellen können somit Informationsverluste auftreten, die einen direkten Zugriff auf den Datenbankserver vereiteln. Noch weitergehende Restriktionen gelten für die intransparenten Tabellen, die beispielsweise für das Human Resources (HR)-Modul benutzt werden. Daten werden aus Sicherheitsgründen verschlüsselt abgelegt und können nur durch besondere ABAP/4 Routinen wieder extrahiert werden. Weitere Schwierigkeit bereiten Hierarchien wie Kostenstellen oder Produktgruppen, die erst zur Laufzeit aufgebaut werden. Je nach Anforderungen der Analysewerkzeuge müssen diese hierarchischen Strukturen stark umgeformt werden, um sinnvolle Datenstrukturen im Data Warehouse zu ermöglichen. Die flexible Architektur des SAP-Systems erlaubt den Zugriff mehrerer Applikations- Server auf eine Datenbank. Jedes R/3-Modul basiert auf der Programmiersprache ABAP/4 (Advanced Business Application Programming 4GL) und wird über einen Applikations-Server gestartet. ABAP/4-Programme greifen aber über das R/3 Data Dictionary, das Teil des Applikationsservers ist, auf die Daten zu. Für die Funktionen ist es dabei unerheblich, ob der Zugriff auf transparente (relationale) oder Pool- und Clustertabellen erfolgt. Für die Datenextraktion, ergeben sich nun drei Möglichkeiten für einen Zugriff auf die Datenbasis von R/3: 1. Entwicklung von ABAP/4 Programmen. Abgesehen von der Knappheit an ABAP/4-Programmierern ist die Eigenentwicklungen der Datenextraktions- und Transformationsroutinen zeitraubend und teuer sowohl bei der Erstellung als auch S. 2

bei der Wartung. Ständig wechselnde Anforderungen sind in lebenden Data Warehouse-Lösungen Normalität. 2. Direkter Zugriff auf die Datenbank. SQL-basierte Reporting-Werkzeuge können direkt oder über ODBC auf den Datenbankserver zugreifen und Tabellen auslesen. Hauptnachteil dieser Vorgehensweise ist die Tatsache, daß wichtige Tabellen in Form von Pool- und Clustertabellen vorliegen, die nicht durch SQL gelesen werden können. Weiterhin wird aufgrund der angestrebten Datenbankunabhängigkeit von R/3 ein Teil der Datenbankverwaltung wie das Sperren von Datensätzen bei Änderungsläufen im Applikations-Server überwacht. Auch wenn moderne Datenbankmanagementsysteme den gleichzeitigen Zugriff verschiedener Anwendungen beherrschen, können trotzdem Inkonsistenzen entstehen, wenn Datensätze verarbeitet werden, die noch in offenen Transaktionen involviert sind. 3. Extraktionswerkzeuge. Die hier vorgestellten Extraktionswerkzeuge generieren in der Regel ABAP/4 Code, der auf den Applikationsserver übertragen und ausgeführt wird. Der Zugriff erfolgt dabei in der Regel über Remote Function Calls (RFC), mit denen die Extraktionswerkzeuge die Prozesse auf dem Applikationsserver anstoßen. So können sämtliche Tabellen ausgelesen werden, ohne das der Anwender selbst ABAP/4 Programme schreiben muß. Die Integration des R/3 Data Dictionary bietet den weiteren Vorteil, daß der Benutzer unabhängig von Änderungen an der R/3 Datenstruktur z. B. bei Releasewechsel wird. Dieser grobe Überblick über die Architektur des R/3-Systems und den davon abhängigen Anbindungsmöglichkeiten zeigt, daß der vermeintlich leichte Zugriff auf die operative Datenbasis nicht ganz unproblematisch ist. Gerade der entscheidende Schritt, das Mapping der R/3-Daten in ein Data Warehouse stellt viele Unternehmen vor immense Probleme. Datenselektion in R/3 oder wie finde ich meine Tabellen? Die Komplexität dieses Prozesses sollte nicht unterschätzt werden: Das für den Vergleich verschiedener ETL-Werkzeuge extrahierte Repository eines produktiven R/3- Systems Release 4.0B umfaßte trotz Beschränkung auf die Tabellen der Systemsprache Deutsch über 300 MB. Enthalten waren die Metadaten von ca. S. 3

13.000 transparenten Tabellen, 2.000 Pool- und Clustertabellen, 12.000 Views und 25.000 intransparenten Tabellen. Auch wenn aus diesen insgesamt ca. 52.000 Tabellen mit 840.000 Feldern die Systemtabellen und andere nicht benutzte ausgeblendet werden, verbleibt doch ein riesiger Datenbestand, in dem die Kennzahlen und Dimensionen des Data Warehouse Modells gesucht werden müssen. Neben der reinen Datenfülle bereitet das undurchsichtige Datenschema und die nichtsprechenden Bezeichnungen der Tabellen und Spalten mit 4- oder 5-Ziffern-Kürzeln wie VBAK oder T001 zusätzliche Schwierigkeiten. Wichtig ist es daher, daß ein ETL- Produkt so viel Unterstützung bei der Datenselektion wie möglich bietet, um eine effiziente Identifizierung der Datenquellen zu erlauben. Ansatzpunkte sind hier eine Integration der Metadaten, die Navigationsunterstützung im Datenmodell und Data Mart- Templates. 1. Metadaten Im Repository des R/3-Systems findet sich in allen Systemsprachen sowohl ein kurzer Beschreibungstext zu den Tabellen, als auch zu den einzelnen Tabellenspalten. Angegeben ist eine Inhalts- bzw. Funktionsbeschreibung der Tabelle und der jeweiligen Tabellenspalte. Bei der Fülle der Tabellen sollten ETL- Werkzeuge für beide Beschreibungselemente leistungsfähige Suchmöglichkeiten vorhalten. Wichtig in diesem Zusammenhang ist, die R/3-Sprache zu beherrschen, d. h. auch betriebswirtschaftlich die gesuchten Daten mit den R/3-Begriffen belegen zu können. 2. Navigationsunterstützung im Datenmodell Statt einer Suche nach Begriffen in den Metadaten kann bei der Tabellensuche auch ein Einstieg über die modulare Struktur von R/3 erfolgen. Bietet das Werkzeug eine Zuordnung von bestimmten Funktionen innerhalb eines R/3-Moduls zu Tabellennamen, lassen sich die gesuchten Daten schneller einkreisen. Hilfreich sind hier graphische Übersicht des R/3- Datenschemas in Baumstruktur wie bei SAS (Abb. 1) mit einer Angabe der jeweils angesprochenen Tabellen. Eine weitere Möglichkeit ist die Verknüpfung von Tabellenspalten zu SAP Funktionen oder Bildschirmmasken, wie sie beispielsweise D2K bietet. Die Identifikation der Eingabemaske der gesuchten Daten führt so sehr schnell zu den entsprechenden Tabellen. Ist ein gesuchtes Datenfeld in einer Tabelle S. 4

identifiziert worden, ist es zum Verständnis des R/3-Datenschemas weiterhin wichtig zu wissen, mit welchen Tabellen die gefundene verknüpft ist und wo das Datenfeld noch auftaucht. Um dies zu verwirklichen, sollten ETL-Werkzeuge Funktionen wie die Verfolgung von Tabellenschlüsseln und eine Anzeige von gleichnamigen Datenfeldern in anderen Tabellen anbieten. S. 5 Abb. 1: Data Model Explorer von SAS/Access Interface to R/3 3. Data Mart Templates - Vorgefertigte Data Marts für abgegrenzte betriebliche Funktionsbereiche oder Aufgaben wie Marketing/Vertrieb, Controlling, Produktion/Logistik oder Einkauf (Procurement) bieten bedeutende Vorteile in Form von drastisch gesenkten Einführungszeiten des Data Warehouse. Ein Template besteht einerseits aus einem spezifischen Datenmodell und andererseits aus vordefinierten SAP R/3-Extraktions- und Transformationsprozessen. Da auf ein bewährtes Datenmodell zurückgegriffen werden kann, das bereits mit den R/3-Tabellen verknüpft ist, müssen nur Anpassungen an die unternehmensspezifischen Eigenheiten vorgenommen werden. Geht man davon aus, daß ca. 80% der Analysebedarfe von Unternehmen übereinstimmen, so können durch den Einsatz von Templates erhebliche Zeitund Kostenvorteile erzielt werden. Aufgrund ihrer besonderen Bedeutung für einen effizienten Data Warehouse Aufbau, wird auf Data Mart Templates in einem weiteren Artikel im nächsten is report ausführlich eingegangen. Lösung aus einer Hand Business Information Warehouse (BW) Das Thema Data Warehouse wird auch von der SAP selbst aufgegriffen, um das On- Line Transaction Processing (OLTP) System R/3 um ein On-Line Transaction Proces-

sing (OLAP) System zu ergänzen. Kernelement des SAP BW, das inzwischen in Version 1.2 verfügbar ist, bildet der Information Warehouse-Server mit einer integrierten OLAP-Engine. Vorkonfigurierte Modelle, wie beispielsweise Marktsegmentanalyse, Finanzmanagement etc., unterstützen die multidimensionale Analyse und erlauben eine schnelle Einführung und Verwendbarkeit, müssen aber im Einzelfall auf die Bedürfnisse hin angepaßt werden. Zur Sicherstellung einer hohen Performance verwendet das SAP BW einen dedizierten Server. Die durch die OLAP-Engine aufgebauten InfoCubes bieten mit dem Summary Level die Möglichkeit, bestimmte Aggregationen vorzuhalten, die das Laufzeitverhalten typischer Anfragen enorm verkürzen. Die Integration anderer Datenquellen in das BW überläßt SAP externen ETL-Tool Anbietern. Zertifizierte Partner, die über die BAPI-Schnittstelle Daten in das BW laden, sind z. B. ETI, Prism (kürzlich von Ardent aufgekauft), TSI und Informatica. Die anderen hier vorgestellten Lösungsanbieter besitzen jedoch die gleiche oder ähnliche Funktionalität. Externe Lösungsanbieter Inzwischen bieten viele Hersteller von ETL- oder Data Warehouse- und Business Intelligence-Lösungen eine SAP-Anbindung an. Neben allgemeinen Gesichtspunkten wie Plattform- und Herstellerunterstützung (Wartung/Support) oder Kosten sollte bei der Auswahl eines Anbieters insbesondere die Systemarchitektur berücksichtigt werden. Bedeutende Faktoren sind hierbei Anzahl der unterstützten Datenquellen, Art der Datenanbindung / Datentransport, Offenheit der Metadaten, Möglichkeiten zur Transformation und Benutzerfreundlichkeit. Auf dem Markt können drei Arten von Lösungen unterschieden werden. Entwicklungswerkzeuge bieten zum einen bereits eine Integration von SAP R/3, die für den Extraktionsprozeß genutzt werden kann. Inprise verfügt beispielsweise mit dem Delphi/Connect for SAP über eine leistungsfähige Entwicklungsumgebung für Unternehmen, die individuelle Applikationen in R/3 integrieren wollen. Die Funktionalität kann auch gut zum Aufbau einer Data Warehouse-Lösung eingesetzt werden. Die Unterstützung bei Transformationsprozessen o. ä. ist dabei natürlich eher eingeschränkt und Anwender sind weitgehend auf eigene Programmierleistungen angewiesen. S. 6

Mit deutlich besserer Unterstützung des gesamten Prozesses zum Befüllen von Data Warehouses präsentieren sich ETL-Tools mit SAP-Schnittstelle und Data Warehouse / Business Intelligence Tools, die eine R/3-Anbindung bieten. Die Vorgehensweise und Systemarchitektur der meisten Anbieter am Markt ist dabei auf den ersten Blick häufig sehr ähnlich. Unterschiede offenbaren sich erst beim genaueren Hinsehen, weshalb im folgenden nach einer Beschreibung des generellen Ablaufs einer Integration der R/3- Umgebung einige interessante Ansätze exemplarisch vorgestellt werden sollen. Für die Verbindung zum R/3-System wählen die meisten Werkzeuge heute eine Strategie der online-anbindung mit Remote Function Calls, die eine dynamische und bilaterale Kommunikation zwischen ETL-Werkzeug und SAP-System zulassen (vgl. Abb. 2). Die Alternative sind Dateiextrakte mit Hilfe von IDocs (SAP Interchange Documents) oder anderen Formaten, die generiert und in das ETL-Werkzeug überführt werden. Diese offline -Methode über Dateien bietet sich nur an, wenn eine sehr langsame oder schlechte Netzwerkverbindung zum R/3-System vorliegt oder andere Gesichtspunkte wie Daten- und Zugriffssicherheit oder Datenmenge für diese Vorgehensweise sprechen. S. 7 SAP R/3 ETL-Tool Data Warehouse Applikations-Server R/3 Metadaten RFC ETL Metadaten DW Metadaten ABAP/4 Funktionsmodul RFC ETL-Server Extrakt RDBMS Staging Area MDBMS Datenbank- Server ODBC/ direkter Zugriff Extrakt Abb. 2: Exemplarische Architektur einer SAP-Anbindung Der erste Schritt bei einer SAP-Anbindung ist die Integration der Metadaten des R/3- Systems. Nur so können auf Tabellen- und Feldbeschreibungen zugegriffen und Änderungen des R/3-Datenmodells z. B. bei Releasewechsel oder Erweiterungen nachvollzogen werden. Einige Hersteller nehmen hierfür einen kompletten Export der Metadaten in

das ETL-Werkzeug vor. Bei den oben genannten Dimensionen des R/3-Repository nimmt dieser Vorgang auch bei einer schnellen Netzwerkverbindung mehrere Stunden in Anspruch und stellt natürlich nur ein statisches Abbild der Metadaten dar. Vorteile ergeben sich jedoch aus den schnelleren Zugriffsmöglichkeiten der lokal gehaltenen Daten. Bei vielen anderen Lösungen werden die Metadaten im R/3-System direkt durchsucht und erst bei Bedarf, d. h. bei Identifizierung durch den Benutzer als Datenquelle, in das ETL-Tool überführt. Diese Werkzeuge greifen bei jeder Suchanfrage direkt auf das aktuelle R/3-Repository zu, wobei sich vergleichsweise höhere Antwortzeiten ergeben können. Zur Extraktion der Daten sollte aus den oben bereits skizzierten Gründen auf den Applikationsserver des R/3-Systems zugegriffen werden. Benutzt werden hierfür ABAP/4- Funktionsmodule, die von außerhalb des R/3-Systems mit Hilfe von Remote Function Calls (RFC) in das System übertragen und angesprochen werden können. Um diese Form der Kommunikation zu nutzen, bedienen sich die ETL-Werkzeuge in der Regel eines RFC-Servers, der als Schnittstelle zwischen SAP-System und Warehouse dient und die Datenströme anstößt sowie weiterleitet. Grundsätzlich ergeben sich bei der Ausführung von ABAP Programmen zwei verschiedene Möglichkeiten. Zum einen können zur Laufzeit ABAP/4 Progamme vom ETL-Werkzeug erzeugt, auf das SAP-System übertragen, dort ausgeführt und danach wieder gelöscht werden. Das hierzu erforderliche RFC-Modul ist Bestandteil der R/3-Applikation und kann von verschiedenen externen Programmen benutzt werden. Der durch die ABAP/4-Abfrage generierte Datenstrom wird dann vom RFC-Server empfangen und weiterverarbeitet. Stehen die ABAP/4-Extraktionsroutinen (zumindest für eine gewisse Zeit) fest, so können sie auch komplett und dauerhaft in das R/3-System übertragen werden. Für eine Ausführung muß vom ETL-Tool jedoch ein zusätzliches Funktionsmodul auf dem R/3- Applikationsserver installiert werden, das die Ausführungssteuerung der Extraktionsskripten durch den ETL-Server erlaubt. Diese Vorgehensweise hat den Hauptvorteil, daß mehrere Extraktionsprozesse auch gleichzeitig durchgeführt und die teilweise sehr strengen Sicherheitsvorkehrungen des SAP RFC-Moduls umgangen werden können. Bei der Datenübertragung zwischen Applikationsserver und ETL-Werkzeug sind ebenfalls verschiedene Vorgehensweisen zu differenzieren. Wichtig ist häufig die Unterstützung des TCP/IP-Protokolls, die eine Komponente des ETL-Werkzeugs auf Seiten des Applikationsservers voraussetzt, der die RFCs dort abwickelt und über das Netzwerk S. 8

mit dem ETL-Tool kommuniziert. Weiterhin möglich ist die Datenübertragung via FTP oder in einer Windows NT-Umgebung auch mit gemeinsam verwalteten Verzeichnissen (shared directory). Letztere Methoden erlauben allerdings keine dynamische, d. h. interaktive Verbindung zum R/3. Änderungen können erst nach der Betrachtung des kompletten Ergebnis eines Extraktionsprozesses vorgenommen werden. Tab. 1: Überblick über die wichtigsten Werkzeuge zur SAP R/3-Anbindung S. 9 Werkzeugkategorie Entwicklungswerkzeug ETL-Werkzeuge Data Warehouse / Business Intelligence Tools Anbieter Produktbezeichnung WWW-Adresse Inprise Delphi/Connect for SAP www.inprise.de Acta Technology ActaWorks www.acta.com Ardent Software Prism Warehouse Executive interface www.ardentsoftware.com to SAP R/3 D2K Tapestry Dynamic Mapper for SAP www.d2k.com R/3 Evolutionary Technologies ETI EXTRACT Data System Library www.eti.com International for SAP R/3 Informatica SAP BW Integration Server/ PowerCenter www.informatica.com Systemfabrik Warehouse Workbench for SAP R/3 www.sf-europe.com Brio / Sqribe Sqribe Reporting for R/3 www.sqribe.com Cognos Cognos Accelerator for SAP www.cognos.de Information Builders SNAPpack Data Migrator for SAP R/3 www.ibi.com Oracle Warhouse Toolkit for SAP www.oracle.de Platinum Technology Decision Base www.platinum.com SAS SAS/Access Interface to R/3 www.sas.com SAS bietet mit dem SAS/Warehouse Administrator eine leistungsfähige Steuerungskomponente für den gesamten Extraktions-, Transformations- und Ladeprozeß an. Zur Anbindung wird das Modul SAS/Access benutzt, das über Schnittstellen zu einer Vielzahl von Datenquellen inkl. einem Interface zu SAP R/3 verfügt. Nach einem vollständigem Export der R/3-Metadaten wird die Datenselektion durch Suchfunktionen und dem Datamodel Explorer unterstützt. Innerhalb des SAS/Warehouse Administrators muß der Anwender lediglich die identifizierten Datenquelle mit der Data Warehouse Zieltabelle im SAS System verbinden - die Generierung der ABAP/4 Skripts, ihre Übertragung zu einem SAS RFC-Server auf dem R/3 Host und die Ausführung der Abfrage übernimmt dann das System. Innerhalb des R/3-Systems benutzt SAS anders als die meisten anderen Anbieter einen CPIC-User, was zu höheren Datenübertragungsraten beim Aufruf der ABAP/4-Datenbankabfragen innerhalb des Applikationsservers führen soll.

S. 10 D2K bietet in seinem Produkt Tapestry Dynamic Mapper for SAP R/3 technologisch weitentwickelte Funktionen für den Datentransport an. Die aus dem SAP-System extrahierten Daten werden sowohl komprimiert als auch verschlüsselt übertragen, was zu schnelleren und sichereren Extraktionen führt. Ebenfalls sehr fortschrittlich sind Lösungen wie die Warehouse Workbench von Systemfabrik, die zwischen einem Zugriff auf Tabellen unterscheiden, die über ABAP/4-Code im Applikationsserver angesprochen werden müssen und transparenten Tabellen, die direkt aus dem Datenbankserver gelesen werden können. Durch die Benutzung proprietärer Kommunikationsprotokolle zum Datenbankserver ergeben sich durch diesen hybriden Ansatz deutlich schnellere Extraktionen transparenter Tabellen, wobei die oben angesprochenen Probleme bezüglich nicht abgeschlossener Transaktionen natürlich bestehen bleiben. Auf der Applikationsseite wird bei der Warehouse Workbench ein RFC- Listener installiert, so daß SQL- und ABAP-Anfragen über TCP/IP-Protokoll vom ETL- Server übermittelt werden können. Abb.3: Definition des Extraktionsprozesses mit Systemfabrik Warehouse Workbench Eine andere Lösung stellt ActaWorks vom Silicon Valley Startup Acta Technology dar. ActaWorks ist ein spezifisches Extraktions- und Transformationswerkzeug zum Aufbau von Data Warehouses und Data Marts auf Basis von R/3 und anderen ERP-Systemen. Schwerpunkt ist die Extraktion der gewünschten Daten mit Hilfe von optimierten ABAP/4-Programmen. Eine gute Benutzerunterstützung bietet der ActaWorks Designer (siehe Abb. 4), der die Entwickler mit einer visuellen Benutzerführung bei der Definition der Mapping- und Transformationslogik unterstützt. Dies erfolgt mit graphisch dargestellten Workflows, in denen alle Stufen dieses Prozesses enthalten und dokumentiert

S. 11 sind. Die so erstellten Regeln werden in einem offen zugänglichem Metadaten Repository abgespeichert. Ebenfalls hinterlegt sind hier Beschreibungen der extrahierten Datenquellen. Der eigentliche Extraktionsprozeß wird durch den ActaWorks Server gesteuert, wobei auf eine Staging Area verzichtet wurde. Sämtliche Transformationen werden auf dem Applikationsserver durchgeführt und die Daten direkt in das Data Warehouse überspielt. Während des Entwicklungsprozesses können ABAP/4-Skripts bei Bedarf generiert, auf den Applikationsserver übertragen und dort ausgeführt werden. In einer produktiven Umgebung werden die Extraktionsroutinen dann komplett auf den R/3-Server geladen und nur noch durch den ActaWorks Server angestoßen. Abb. 4: Definition der Extraktion und Transformation bei ActaWorks Fazit Die große Zahl der installierten R/3-Systeme und die hier skizzierten Probleme beim Aufbau eines darauf aufsetzenden Data Warehouse haben inzwischen viele ETL- Anbieter als Chance begriffen. Innerhalb des letzten Jahres sind dabei leistungsfähige und stabile Produkte entstanden, die für viele Unternehmen bereits jetzt einen hohen Nutzeffekt erzielen. Als Wachstumschance sehen jetzt viele der ETL-Anbieter die Option, den Unternehmen auf Basis dieser Anbindung rasch eine vorkonfigurierte Data Mart-Anwendung zu realisieren.