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.