Effizientere Analysen

ABAP-Tuning für SAPs Business Warehouse

08.04.2013
Von Jürgen Noe
Durch den gezielten ABAP-Einsatz lässt sich mehr aus dem Business Warehouse (BW) von SAP herausholen. Lesen Sie, in welchen 26 Fällen das Sinn gibt und wie es funktioniert.
Überblick über die Einsatzgebiete von ABAP.
Überblick über die Einsatzgebiete von ABAP.
Foto: Kheto Consulting

In SAPs Business Warehouse (BW), ab Version 7, werden viele Aufgaben grafisch unransferstützt und benötigen deshalb keine Programmierkenntnisse. Dennoch gibt es insgesamt 26 Anwendungsfälle, in denen Anwender durch den gezielten Einsatz von ABAP mehr aus einem SAP-BW-Projekt herausholen können. Erfahrene ABAP-Entwickler mit zusätzlichem SAP BW Know-how bilden daher unverzichtbare Ressourcen für jedes Vorhaben in diesem Umfeld. In folgenden fünf Bereichen lässt sich mit Hilfe von ABAP mehr aus dem SAP BW machen:

  • Extract, Transform, Load (ETL)

  • Query & Reporting

  • Integrierte Planung

  • Enterprise Information Management (EIM)

  • Data Mining

Anwendungsfälle im ETL-Prozess

1. Für den täglichen Projekteinsatz lassen sich "SAP BW Extraktoren" aus dem Business-Content in aller Regel ohne weitere Programmierung sofort einsetzen. Eine Vielzahl dieser Standard-Extraktoren finden Anwender bereits im SAP ERP. Diese ermöglichen so eine einfache und unkomplizierte Übernahme von ERP-Daten in ein SAP BW. Allerdings sind viele ERP-Systeme an individuelle Anforderungen im Unternehmen angepasst und damit meist um zusätzliche Felder, Tabellen und Programme erweitert. Um Daten aus diesen kundenspezifischen Erweiterungen ins SAP BW extrahieren zu können, gibt es die Möglichkeit, bestehende Extraktoren zu erweitern oder kundeneigene Extraktoren zu entwickeln. Für Erweiterungen von kundeneigenen Extraktoren sieht SAP vordefinierte "User Exits" vor. Das gilt für

  • Bewegungsdaten (EXIT_SAPLRSAP_001),

  • Stammdatenattribute (EXIT_SAPLRSAP_002),

  • Stammdatentexte (EXIT_SAPLRSAP_003) und

  • Hierarchien (EXIT_SAPLRSAP_001).

Diese Exits benötigen Anwender darüber hinaus auch für ein Stammdaten-Staging innerhalb eines SAP BW. Dabei werden Stammdaten eines Info-Objekts aus einem anderen Info-Objekt gefüllt. Für den Fall, dass Hierarchien aus verschiedenen Quellsystemen in eine einheitliche Hierarchie zusammengeführt werden müssen, lässt sich speziell der Exit für Hierarchien im SAP BW nutzen.

2. Für den zweiten Anwendungsfall, dass kundeneigene Tabellen oder Ergebnisse von kundeneigenen Programmen ins SAP BW extrahiert werden sollen, sieht SAP so genannte generische Extraktoren vor. Für einfache Tabellen- oder View-Extraktionen lässt sich meist ein einfacher Tabellen-Extraktor auch ohne Programmierung anlegen. In der Praxis müssen die Daten aber oft über einen "Join" aus mehreren Tabellen mit Ein- und Ausschlusskritierien für einzelne Ergebniszeilen bereitgestellt und anschließend ins BW übertragen werden. Für diese Fälle gibt es die Möglichkeit, generische Extraktoren auf Basis eines Funktionsbausteins anzulegen.

3. Der dritte Anwendungsfall ergibt sich für den Fall einer rein technischen Migration von einem SAP-BW-3.x- auf ein SAP-BW-7.x-System. In diesem Fall wurde das bestehende Staging basierend auf Übertragungs- und Fortschreibungsregeln übernommen. Da sich die Anforderungen der Fachabteilungen im Laufe der Zeit jedoch ändern, müssen Anwender Übertragungs- und Fortschreibungsregeln prüfen und an die geänderten Anforderungen anpassen. Hierbei kommen mitunter komplizierte Logiken zur Berechnung von Kennzahlen, Status oder Merkmalsableitungen zum Einsatz. Zwar kann die Migration von Fortschreibungsregeln auf Transformationen teilweise automatisiert erfolgen. Allerdings empfiehlt sich nach erfolgter Migration eine Kontrolle durch einen ABAP-Entwickler.

4. In den Fortschreibungsregeln lassen sich eine Startroutine für jedes Merkmal beziehungsweise eine Kennzahl oder Feldroutinen zur Berechnung des Zielwerts definieren. Bei Übertragungsregeln bestehen dieselben Möglichkeiten für einen Eingriff.

Transformation.
Transformation.
Foto: Kheto Consulting

5. Nachdem die Daten über die Extraktoren ins BW geladen sind, wird im Weiteren ein Datenfluss aufgebaut, mit dem den Anforderungen des Fachbereichs an Funktionsumfang und letztlich den Ergebnisberichten Rechnung getragen wird. Mit BW 7.x empfiehlt es sich, den Datenfluss über Transformationen abzubilden. Im Release BW 7.3 wird die Datenflussmodellierung grafisch gestützt, was die BW-Entwickler entlastet. Über ein GUI lassen sich Infoprovider mit Transformationen verbinden. Neu in BW 7.3 ist, dass der Datenfluss ausgehend von einer Datenquelle automatisch in einen Ziel-Infoprovider generiert werden kann. In den Transformationen können Anwender mit einer einfach gehaltenen grafischen Oberfläche, Quell- und Zielobjekte per "Drag&Relate" miteinander verbinden. Hierbei gibt es die Möglichkeit, wie in Fortschreibungsregeln, Start- und Feldroutinen zur Merkmals- beziehungsweise Kennzahlberechnung zu definieren. Mit BW 7.x können Nutzer zusätzlich Endroutinen definieren, in denen sich einzelne Ergebniszeilen oder die gesamte Ergebnismenge manipulieren lassen. Endroutinen ersetzen die in BW 3.x genutzte Option der Rückgabe von Ergebnistabellen in den Fortschreibungsregeln. Im Fall einer komplizierten Logik zur Berechnung von Merkmalswerten oder Kennzahlen, die nicht mit Start-, Feld- oder Endroutine gelöst werden kann, gibt es im BW 7.x die Möglichkeit, mit einer so genannten Expertenroutine die Transformationen selbst zu programmieren. Falls Stammdaten ins Infoobjekt geladen werden, besteht manchmal die Anforderung, die geladenen Schlüsselwerte zu prüfen beziehungsweise neu zu erzeugen. Auch an dieser Stelle können Anwender über eine Startroutine eingreifen.

6. In der täglichen Praxis muss oft zwischen verschiedenen Währungen konvertiert werden, um das Ergebnis in der gewünschten Währung zu einem bestimmten Tag nach einem bestimmten Verfahren ermitteln zu können. Dazu bieten die SAP-Systeme zahlreiche vordefinierte Funktionsbausteine, um Währungen und Einheiten umzurechnen. Allerdings taucht bei den Anwendern auch immer wieder die Anforderung auf, eine kundeneigene Währungs- oder Einheitenumrechnung in den Funktionsbausteinen abzubilden. Dieser Anwendungsfall lässt sich mit Hilfe von ABAP umsetzen.

7. Nachdem der Datenfluss erstellt ist, besteht der nächste Schritt im Vorgehensmodell darin, Daten in die Infoprovider zu laden. Dies kann über so genannte Infopackages erfolgen. Darüber hinaus müssen die Daten in der Praxis weiter bearbeitet beispielsweise gefiltert werden. Dazu können Anwender statische und dynamische Filter in den Infopackages definieren. Statische Filter bestehen aus Merkmalseinschränkungen. Damit werden nur bestimmte Buchungskreise oder Perioden im System geladen. In der Praxis gibt es jedoch häufig die Anforderung, nur die aktuelle Periode oder ein bestimmtes Intervall von Perioden zu laden. Hierzu müssen dynamische Filter angelegt werden, die Anwender mittels ABAP definieren können. Manchmal dürfen auch nur die aktuellsten Daten im Infoprovider zur Verfügung stehen. SAP BW bietet daher die Möglichkeit, über eine so genannte Request-Löschung nur die aktuellsten Daten im Infoprovider zu belassen und die Vortagesdaten zu löschen. Diese Request-Löschung lässt sich ebenfalls mit Hilfe von ABAP dynamisch ermitteln. Falls Anwender eine Datei ins BW laden möchten, können diese den Dateinamen im Infopackage fix oder dynamisch hinterlegen. Mit der dynamischen Angabe mittels ABAP lässt sich zudem sicherstellen, dass nur Dateien, die einer bestimmten Namenskonvention unterliegen oder in einem bestimmten Verzeichnis liegen, ins SAP BW geladen werden.

8. In BW 7.x funktioniert das Laden in Datenziele über so genannte Datentransferprozesse (DTP). Im DTP können Nutzer ebenfalls statische und dynamische Filter definieren. Statische Filter sind wiederum Merkmalswerte oder Intervalle. Dynamische Filter lassen sich mittels ABAP festlegen.

9. Der Datenladevorgang soll in aller Regel weitestgehend automatisiert zu einem festgelegten Zeitpunkt passieren. Für das automatisierte Laden stehen den Nutzern so genannte Prozessketten zur Verfügung. In Prozessketten wird festgelegt, in welcher Reihenfolge die Daten geladen werden müssen, die so genannten Prozessschritte. Daneben werden in dieser Prozesskette auch Schritte für die Datenziel-Administration wie Indexaufbau und -löschung festgelegt. Ein Prozessschritt selbst besteht aus einem Prozesstyp und seiner Variante. SAP liefert mit dem BW eine große Anzahl an vordefinierten Prozesstypen beispielsweise für das Datenladen, die Datenziel-Administration und zur Prozessteuerung beziehungsweise Verknüpfung von Prozessschritten aus. Varianten definieren dabei die konkrete Ausprägung des Prozesstyps. Mit BW 7.x wurde zudem ein Prozesstyp zur Entscheidung mit integriert, in dem Anwender festlegen können, welcher Prozessschritt in Abhängigkeit von einem definierbaren Ereignis ausgeführt werden soll. Mit dem Prozesstyp "Entscheidung" können Anwender beispielsweise festlegen, dass am Wochenende ein anderer DTP ausgeführt werden soll, als unter der Woche. Kompliziertere Logik zur Entscheidungsfindung muss in ABAP programmiert werden. Das Anlegen von eigenen Prozesstypen erfordert zudem Kenntnisse in objekt-orientierter Programmierung (ABAP/OO) und bildet einen weiteren Anwendungsfall für ABAP.

10. In der Praxis ist manchmal der Fall anzutreffen, dass die Daten aus dem Quellsystem nur über einen vordefinierten Funktionsbaustein geladen und aus Gründen der Datensicherheit oder Datenhoheit selbst nicht im BW gehalten werden dürfen. Für diese Fälle bietet SAP die Möglichkeit, über so genannte Virtualprovider auf Daten in Fremdsystemen zuzugreifen, die als Schnittstelle einen Funktionsbaustein anbieten. Auf einem Virtualprovider lassen sich selbst wieder Queries anlegen und die Daten für ein Berichtswesen verfügbar machen. Allerdings kann erst mit BW 7.3 ein Virtualprovider mit anderen Infoprovidern in einem neuen Typ von Infoprovider, dem Hybridprovider, zusammengefasst werden. Damit ergeben sich speziell für das Zusammenfassen von Virtualprovider mit Basis-Infocubes in einem Hybriprovider mit Direktzugriff neue Möglichkeiten für ein Real-time-Reporting. Für diese Anwendungsfälle benötigen Anwenderunternehmen jedoch einen erfahrenen ABAP-Entwickler für Ihr BW Projekt.

11. In SAP BW 7.3 kommt ein weiterer Infoprovidertyp hinzu, der so genannte semantische Infoprovider. Damit können Anwender ihre Infoprovider logisch nach Region, Land oder Zeit strukturieren. Ein Hüllenkonstrukt definiert die Aufteilung und legt intern die entsprechenden Infoprovider an. Für Entwickler und Anwender bleibt die Struktur dahinter verborgen. Jedoch lässt sich über Business-Addins die logische Aufteilung flexibel halten. Für diesen Einsatz von flexiblen semantischen Infoprovidern ergibt sich ein weiterer ABAP-Anwendungsfall.

12. Während des Lebenszyklus eines Infoproviders können sich die Anforderungen ändern, insbesondere für den Berichtsaufbau. Beispielweise müssen neue Felder ausgewertet werden oder manche Felder werden nicht mehr benötigt. In BW 3.x Systemen war es meist mit einem hohen manuellen Zeitaufwand verbunden, dies umzusetzen. SAP BW 7.x stellt dafür ein Re-Modellierungs-Tool zur Verfügung. Dieses Werkzeug erlaubt es Anwendern, zu einem Infocube neue Merkmale zu einer Dimension hinzuzufügen oder ein Merkmal aus einer Dimension zu entfernen, solange mindestens ein weiteres Merkmal in der Dimension verbleibt. Dazu wird eine Re-Modellierungs-Regel definiert, die beschreibt, wie der Infocube geändert und dies auf das Zielsystem übertragen werden soll. In der Folge wird der Infocube automatisch in die neue Struktur umgewandelt. Welche Werte das neue Merkmal erhält, lässt sich statisch über eine Konstante beziehungsweise einen Initialwert festgelegen. Merkmale aus anderen verfügbaren Merkmalswerten des Infocubes auf Datenzeilenebene abzuleiten, unterstützt das System ebenfalls. Diese Merkmalsableitung kann in ABAP/OO programmiert werden und bildet somit einen weiteren Anwendungsfall.