Referenzbericht sub-tract - bit

Dieter Mayer
Ralf Tossenberger
Fellbach / Schorndorf, Oktober 2010
Referenz-Projekt SAP Adapter, aruba informatik GmbH
Die aruba informatik GmbH, Softwarehersteller mit Sitz in Fellbach
(Stuttgart), liefert mittelstandsgerechte Produkte für die Bereiche
Business Intelligence und Performance Management. Die Produkte
decken die Felder Datenextraktion, Reporting, multi-dimensionale
Analysen, bis hin zu Scorecards und Unternehmens-Cockpits ab.
Ausgangspunkt der Zusammenarbeit waren vermehrte Anfragen
von SAP R/3 und SAP NetWeaver Kunden, die aruba-Produkte in
Verbindung mit SAP einzusetzen. Dies war bis dato aufgrund
technischer Restriktionen nur eingeschränkt möglich.
Die modular aufgebauten Komponenten der aruba-Software
erlauben grundsätzlich die Einbindung verschiedener QuellSysteme, genauer deren Datenbasen, sofern diese auf relationalen
Datenbanken beruhen und per SQL zugegriffen werden kann.
Verdichtete Darstellung von Informationen bei gleichzeitiger
Möglichkeit, per Drill-Down in die Details verzweigen zu können,
machen es erforderlich, einen großen Umfang an Stamm- und
Bewegungsdaten bereitzustellen. Es gilt also ein beachtliches
Datenvolumen in einem überschaubaren Zeitfenster aus SAP heraus
zu übertragen.
Unabhängig davon, auf welcher Datenbank ein konkretes SAPSystem basiert, wären durch Zugriff direkt über den zugehörigen
Datenbankadapter diese Anforderungen erfüllt. Diese Methodik ist
aber im SAP-Umfeld eher untypisch, weil in aller Regel
unerwünscht. Der Hintergrund dieser Restriktion liegt im
Datenbank-Berechtigungskonzept der SAP. Dieses ist, um die
verschiedensten Datenbanken unterstützten zu können, sehr
generisch. Das Thema Berechtigungen wird bei SAP daher
konsequent innerhalb der Applikation selbst abgebildet. Da der
Datenbankbenutzer Zugriff auf alle Tabellen und alle Mandanten,
auch schreibend, hat, wird ein Zugriff über einen Datenbankadapter
in aller Regel nicht gewährt.
Die SAP stellt viele, insbesondere auch moderne, auf XML- und
Web-Services basierende Zugriffe auf ihre Daten zur Verfügung.
Diese Zugriffe sind zwar recht komfortabel zu implementieren und
für Online-Abfragen ein geeignetes Mittel, jedoch für den Transfer
von Millionen Stamm- und Bewegungsdaten aufgrund der sich
ergebenden Laufzeiten ungeeignet.
SAP stellt auf einer relativ unteren Ebene einen RFC-Baustein für
den Zugriff auf die Daten einer Tabelle, inklusive der SAP-eigenen
Berechtigungsprüfungen bereit. Der RFC-Baustein RFC READ TABLE
ist in jedem SAP System vorhanden. Besonders gerne sieht SAP die
Verwendung dieses, über Rechnergrenzen hinweg aufrufbaren, RFCBausteines nicht und das hat auch seine Berechtigung. Aufgrund
des Konzeptes, dass RFC-Bausteine nur eine gewisse Datenmenge
innerhalb eines Aufrufes transportieren können und weitere RFCAufrufe nicht auf den Status des vorgehenden Aufrufes aufsetzen
können (zum Beispiel auf den Cursor eines SQL Result Sets), ist
dieser Baustein ausschließlich für den Abruf kleinerer Datenmengen
geeignet. Große Datenmengen erzeugen einen enormen Overhead,
sind sehr „langatmig“ und strapazieren die Ressourcen des Server
übermäßig.
Für den Zugriff auf SAP-Daten
wurde daher in diesem Projekt
ein
neuer
RFC-Baustein
erstellt,
der
die
diese
Restriktionen, unter anderem
durch
Cache-Mechanismen
und
einer
parallelen
Verarbeitung, umgeht. Das
Ergebnis konnte sich sehen
lassen, die Übertragung einer
dreiviertel
Million
Sätze
konnte von (unakzeptablen)
1½ Stunden! auf 2½ Minuten
verkürzt werden.
Ein solcher in ABAP geschriebener RFC-Baustein versteht aber leider
keine SQL-Anweisungen, sondern wird über vielfältige Parameter
mit den variablen Werten zu einer Abfrage versorgt. Für einen SQLbasierenden Ansatz wie aruba ihn betreibt und wie er grundsätzlich
auch richtig ist, galt es noch eine weitere Hürde zu nehmen.
Ein neu geschaffener RFC-Client-Adapter stellt daher neben dem
komfortablen Zugriff auf das SAP-System, auch einen „SQL nach
RFC Wrapper“ bereit. Das bedeutet, dieser Adapter kann ähnlich wie
ein typischer Datenbankadapter verwendet werden und kapselt die
ganze Komplexität der dahinterliegende RFC-Aufrufe völlig
transparent.
aruba entwickelt ihre Lösungen auf Basis der Microsoft .NET
Architektur. Der neue Adapter wurde unter Umgehung aller von SAP
bereitgestellter Frameworks (welche die Arbeit komfortabler
machen, aber ihren Tribut an die Laufzeit zollen) in der nativen
RFC-Umgebung, also in C implementiert. Über bekannte WrapperMechanismen wurden die APIs des Adapters in .NET eingebunden.
Die aruba informatik GmbH wurde mit meinen Beratungsleistungen
während des gesamten Projektes begleitet. Diese begann mit einer
Studie über die möglichen Zugriffmöglichkeiten, die bereits einen
Prototypen zu Performance-Aussagen enthielt. Es folgte eine
Unterstützung beim Aufbau und der Einrichtung eines SAPEntwicklungssystems. Der RFC-Client-Adapter wurde von mir, in
Kontakt und permanenter Rücksprache mit dem Kunden, entworfen,
implementiert und nach Fertigstellung an die aruba-Entwicklung
übergeben.
Die aruba-Entwickler selbst hatten parallel dazu ihre Komponenten
auf den neuen „Datenbankadapter“ anzupassen und ihn zu
erweitern, konnten sich damit also ganz auf diesen Teil des
Projektes konzentrieren. Zudem hatten sie durch die externe
Unterstützung die notwendige Zeit, sich mit dem SAP-System selbst
weiter vertraut zu machen.
Das Projekt hatte eine Durchlaufzeit von etwa 5 Monaten bis die
neue Lösung bei einem ersten Pilotkunden zum Einsatz gebracht
werden konnte.