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.
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.
Anwendungsfälle im Query-Reporting
Innerhalb des Berichtswesens basierend auf "BW BEx Queries" gibt es insgesamt neun Anwendungsfälle, in denen ABAP-Kenntnisse einen Vorteil für ein SAP-BW-Projekt bringen. Diese Anwendungsfälle erstrecken sich auf das Erstellen und Ausführen von Queries sowie das Berichtswesen.
13. Nachdem Daten in die Datenziele geladen wurden, lassen sich mittels des Query Designers "BEx Queries" auf den Infoprovidern erstellen, ausführen und das Ergebnis beispielsweise im Excel-Frontend für SAP BW Auswertungen anzeigen. Im Query Designer können Anwender statische und dynamische Filter über Query-Variablen definieren. Statische Filter sind wiederum fixe Merkmalswerte. Dynamische Filter können über Query-Exit-Variablen zum Merkmal definiert werden. Die Query-Exit-Variable wird zur Laufzeit der Query ausgeführt und bestimmt, welcher Merkmalswert zum Merkmal während der Query-Ausführung zurückgegeben wird. Das sind zum Beispiel Variable, die beispielsweise den vergangenen Monat oder das Zeitintervall vom 1. Januar bis heute zurückliefern. Neben diesen Exit-Variablen lassen sich dynamische Spaltenüberschriften definieren. Jede Query-Exit-Variable wird zentral im Exit "EXIT_SAPLRRS0_001" aufgerufen. In der täglichen Praxis benötigen Anwender häufig die Möglichkeit, Berechtigungen für den ausführenden Nutzer zur Laufzeit der Query zu ermitteln. Über dynamische Berechtigungsvariablen lässt sich zur Laufzeit der Query entscheiden, welche Daten ein Nutzer sehen darf und welche nicht.
14. Ein weiterer Anwendungsfall sind Merkmale und Kennzahlen, die nur zur Query-Laufzeit verfügbar sind. Solche Merkmale und Kennzahlen werden daher virtuelle Merkmale beziehungsweise virtuelle Kennzahlen genannt. Die virtuellen Merkmale und Kennzahlen selbst sind zwar bei der Query-Definition verfügbar, ihre Werte werden aber erst zur Query-Laufzeit in einem User-Exit (EXIT_SAPMRSRU_001) berechnet.
15. Neben der reinen Anzeige der Query-Ergebnisse in Excel lassen sich diese auch im Web darstellen. Mittels des "Web Application Designers" (WAD) können Entwickler Web-Applikationen erstellen. Der Web Application Designer verfügt über eine große Anzahl an vordefinierten Web-Elementen, so genannte "Webitems". Falls die Funktionalität dieser Standard-Webitems nicht ausreicht oder kundeneigene Webitems erstellt werden sollen, kann dies mittels objekt-orientierter Programmierung gelöst werden. Diese über den Standard hinausgehenden Webitems müssen dazu das Interface "IF_BICS_CONS_WEBITEM_CUST_EXIT" implementieren.
16. BEx Queries bieten die Möglichkeit, aus der Query in eine beliebige SAP-Transaktion abzuspringen. Dies geschieht über die so genannte Bericht-Bericht-Schnittstelle. In dieser Schnittstelle wird die Quell-Query, aus der der Absprung möglich sein soll, sowie das Sprungziel hinterlegt. Das Sprungziel kann jede beliebige Transaktion sein.
17. Neben der reinen Anzeige von Daten, lassen sich Daten aus dem BW auch in das ERP-System zurückschreiben. Das ist häufig bei Anwendungen der integrierten Planung der Fall. Plandaten werden dabei aus dem ERP ins BW geladen und dort den Planern zur Verfügung gestellt, mit der Option, die Planwerte auf aggregierter Ebene anzupassen. Die geänderten Werte können erneut verteilt und anschließend ins ERP zurückgeschrieben werden, beispielsweise für eine weitere Planungsrunde. Das Zurückschreiben funktioniert mit Hilfe so genannter Retraktoren. Neben den Standard-Retraktoren für CO können ABAP-Entwickler auch kundeneigene Retraktoren entwickeln.
18. Aus der Anforderung, dass Query-Ergebnisse als Schnittstelle für weitere Systeme oder Anwendungen dienen, ergibt sich ein weiterer Anwendungsfall für ABAP. Um Query-Ergebnisse in angeschlossenen Systemen verarbeiten zu können, müssen diese in Funktionsbausteine oder Klassen gekapselt werden. Zum Auslesen der Query sieht SAP die beiden Klassen "CL_RSR_REQUEST" und "CL_RSR_DATA_SET" als Schnittstelle vor.
19. Neben der reinen Darstellung der Query-Ergebnisse in Excel oder im Web hat SAP mit dem so genannten Composite Environment (CE) weitere Applikationen hinzugefügt, die die Produktivität von Nutzern im Web erhöhen sollen. Der Visual Composer (VC) ist beispielsweise Bestandteil des Composite Environment und erlaubt Geschäftsprozess-Experten die graphisch gestützte Modellierung von Abläufen ohne dafür eine Zeile Programmcode schreiben zu müssen. Dabei werden Applikationen aus verschiedenen vordefinierten Elementen zusammengestellt, die miteinander über vordefinierte Eingangs- und Ausgangsverbindungspunkte in Beziehung gesetzt werden. Der Hauptzweck dieser Anwendung ist es, service-orientierte Anwendungen zu erstellen und Services aufzurufen. Geschäftsprozess-Experten rufen bestimmte Services innerhalb ihrer Anwendungen auf, wie zum Beispiel Services für den Materialstamm oder andere kundeneigene Services. Diese Services können als Funktionsbausteine implementiert sein und im Visual Composer aufgerufen werden. Dies ist ein weiterer Anwendungsfall für ABAP im SAP BW.
20. Mit dem Zukauf von Business Objects (BO) 2008 hat SAP seinen Anwendern viele weitere Werkzeuge für die Berichtserstellung und -darstellung an die Hand gegeben. Eines dieser Werkzeuge ist Crystal Reports, mit dem ein pixel-genaues Berichts-Layout möglich ist und das WYSIWYG-Drucken unterstützt. Damit lassen sich Berichte beispielsweise einfach an bestehende Corporate Design Standards anpassen. Crystal Reports ist grundsätzlich offen für verschiedene Datenquellen. Daher unterstützt das Tool auch die Einbindung von SAP-Funktionsbausteinen als Datenquelle für einen Bericht. Dabei spielt es keine Rolle, ob es sich um ein SAP-ERP-, -CRM-, -SCM- oder -BW-System handelt. Diese Funktionsbausteine als Datenquelle für Crystal Reports bilden einen weiteren Anwendungsfall für ABAP.
21. Neben Crystal Reports hat SAP mit dem Zukauf von BO noch zwei weitere, wichtige Werkzeuge übernommen, um Berichte zu erzeugen und darzustellen. Das sind "WebIntelligence" für die Darstellung von Queries im Web mit einfachen Navigationsfunktionen, sowie "Dashboard Design", auch als "XCelsius" bekannt. Mit Dashboard Design können Entwickler anspruchsvolle Management-Cockpits auf einfache Art und Weise bauen. Alle diese Frontend-Werkzeuge unterstützen Web-Services als Datenquelle. In SAP lassen sich Funktionsbausteine einfach in Webservices umwandeln.
Anwendungsfälle in der integrierten Planung
22. In den zurückliegenden Jahren gewann das Thema Planung eine immer größere Bedeutung für Unternehmen - in erster Linie um die wachsenden Herausforderungen der Märkte meistern zu können. SAP liefert mit der "Integrierten Planung" ein Werkzeug aus, mit dessen Hilfe Entwickler im SAP BW Planungsanwendungen erstellen können. Die Planung wird mit dem so genannten "Planning Modeler" umgesetzt. Dabei handelt es sich um ein Web-basiertes GUI, mit dem sich alle notwendigen Planungsobjekte definieren lassen. Mit der Auslieferung von SAP BW 7.0 lief der Planning Modeler auf dem Java-Stack, mit BW 7.3 laufen Planning Modeler und "Planning Wizard", für die schnelle Generierung von Planungsobjekten, alternativ nun auch auf dem ABAP-Stack. Im Hinblick auf Erweiterungen und besseren Debugging-Möglichkeiten ist dies ein weiterer wichtiger Anwendungsfall für ABAP-Entwickler.
23. Die wichtigsten Elemente für die Planung sind Aggregationsebenen, Filter und Planungsfunktionen. Planungsfilter unterteilen die Daten für die Benutzer, dass nur auf die für die Planung unmittelbar benötigten Daten zugegriffen werden kann. Darüber hinaus definiert der Filter die Datenmenge, auf der die jeweilige Planungsfunktion ausgeführt wird. Dabei lassen sich statische und dynamische Planungsfilter anlegen. Dynamische Filter basieren wie bereits beschrieben auf Query-Exit-Variablen. Entwickler können bereits bestehende Query-Variablen in der Planung nutzen, aber auch eigene nur für die Planung zu verwendende Variablen anlegen.
24. Planungsfunktionen werden dafür genutzt, systemgestützte Daten zu generieren und zu editieren. Planungssequenzen beschreiben dabei die Reihenfolge, in der Planungsfunktionen ausgeführt werden. Die integrierte Planung liefert eine Vielzahl von Planungsfunktionen mit, wie etwa das Kopieren oder Verteilen von Daten. Viele Unternehmen verfolgen indes eigene Verteilungsregeln, nach der die Plandaten auf einzelne Monate verteilt werden sollen. Dazu haben Entwickler die Möglichkeit, kundeneigene Planungsfunktionen in der Transaktion "RSPLF1" anzulegen. Dies erfordert jedoch Kenntnisse in der objekt-orientierten Programmierung.
Anwendungsfall Enterprise Information Management (EIM)
25. Je besser die Stammdaten, desto besser sind im Allgemeinen auch die Akzeptanz der BW-Berichte und des BW-Systems insgesamt. In der Praxis mangelt es jedoch in vielen BW-Systemen an der Qualität der Stammdaten. Um Stammdaten aus verschiedenen Systemen zu harmonisieren, lassen sich "SAP Master Data Management" (MDM) oder "SAP BO Data Federator" integriert in die "SAP BO Data Services" einsetzen. Beide Werkzeuge laufen unabhängig vom SAP-BW-System und können auch auf einem Notebook installiert werden. SAP sieht hier die so genannte "MDM ABAP API" als Schnittstelle vor, mit der sich Stammdaten von und zum BW-System oder anderen SAP-Systemen zu SAP Master Data Management austauschen lassen. Der "Data Federator Query Server" greift dabei auf einen ABAP Callback zu, um Daten mit dem BW auszutauschen. Der Einsatz von Master Data Management oder des Data Federators innerhalb der Stammdateninitiative im SAP BW bildet einen weiteren Anwendungsfall für ABAP.
Anwendungsfall Data Mining
26. Das SAP BW lässt sich auch dafür einsetzen, um neue Zusammenhänge zwischen Daten aufzuspüren. Bestes Beispiel hierfür ist das Cross-Selling, wie es beispielsweise Amazon.com praktiziert. Wenn ein Kunde ein Produkt bei Amazon kauft, werden ihm weitere Produkte vorgeschlagen, die andere Kunden gekauft haben. SAP BW bietet hierzu den "Analysis Prozess Designer" oder die "Data Mining Workbench" an. Es handelt sich hierbei um eine graphisch gestützte Oberfläche, mit der Anwender Objekte per "Drag & Relate" miteinander verbinden und so die Daten manipulieren können. Insgesamt stehen im System 16 vordefinierte Datentransformationen zur Verfügung. Eine dieser vordefinierten Transformationen ist "Routine". In diesem Transformationstyp lassen sich eigene Transformationsregeln hinterlegen, sei es eine ABC-Analyse oder auch nur eine Regel zur Merkmalsableitung. Der Einsatz von Data Mining und des Analysis Prozess Designers bildet an dieser Stelle den letzten Anwendungsfall für ABAP im SAP BW. (ba)