
Für den Fall, dass die generischen Typen der Merkmalsbeziehungen (Attribut, Hierarchie, DataStore) und der Datenscheiben (Selektion) für die individuellen Kundenanforderungen nicht ausreichen, können Sie Merkmalsbeziehungen und Datenscheiben vom Typ Exit implementieren.
| Region | Regional_Prod_ID | Produkt_ID | |
|---|---|---|---|
| R_01 | RP_123 | UP_123 | |
| R_02 | RP_123 | UP_321 | |
| ... | ... |
In den regional verschiedenen Vertriebsorganisationen können verschiedene Produkte dieselbe Identifikationsnummer haben. Damit es bei einem überregionalen Vergleich eine eindeutige Bezeichnung gibt, müssen diese RP-Nummern in eindeutige UP-Nummern umgewandelt werden. In unserem Beispiel erhält das Produkt RP_123 aus der Region R_02 die Produkt-ID UP_321.
Beispiel 2: Wir nehmen an, dass ein unternehmensweiter Planungsprozess für Vertriebskennzahlen pro Kalenderquartal auf der Ebene der Produktgruppen aufgesetzt werden soll. Hierbei ist zu berücksichtigen, dass einige regionale Vertriebsorganisationen ihre Plandaten (zumindest für bestimmte Planversionen) ab einem definierten Zeitpunkt festschreiben, während andere ihre Plandaten anpassen können, wenn bestimmte Ereignisse solche späten Anpassungen erfordern.
Unter diesen Umständen können z.B. die Plandaten einer Region A für das erste Quartal des folgenden Jahres nach dem 15. Dezember des laufenden Jahres festgeschrieben werden, während einer Region B erlaubt wird, ihren Plan einer sich unerwartet ergebenden Gelegenheit eines zusätzlichen Umsatzes sogar bis zum Ende des Monats Januar des folgenden Jahres anzupassen. Um dies nachvollziehbar zu machen, kann man eine Planversion V2 einführen, diese neue Planversion mit den ursprünglichen Plandaten aus Planversion V1 füllen und dann diese Planversion für Anpassungen allein der Region B öffnen.
Um die Anforderung aus Beispiel 1 zu implementieren, kann man eine Merkmalsbeziehung vom Typ Exit definieren, die zwei Relationen (Schritte) mit Ableitung enthält: Die erste Relation hat die eindeutige ID als Quell- und die ursprüngliche ID (in Verbindung mit der ursprünglichen Vertriebsorganisation) als Zielmerkmal; die zweite genau umgekehrt. Somit wird die ursprüngliche ID abgeleitet, wenn auf der eindeutigen ID geplant wird. Die eindeutige ID wird abgeleitet, wenn die Felder umgedreht werden. Konsistenz der beiden IDs wird sichergestellt, wenn beide Merkmale für Planung offen sind.
Die Anforderung aus Beispiel 2 ist ein typischer Fall für eine Datenscheibe vom Typ Exit, definiert auf den Merkmalen Region, Planversion und Quartal, mit Zugriff auf Daten, die außerhalb des BW-Systems in einem Werkzeug für den Planungsprozess bearbeitet werden, das seine Daten in der Datenbank speichert. Um diese Anforderung noch individueller zu machen, soll es einige Administratoren geben, die die Berechtigung haben, jederzeit Plandaten anzupassen, um falsche Eingaben zu korrigieren.
Die typische ABAP-Exit-Implementierung dieser Beispiele ist direkt, indem die externen Daten mittels SQL-Befehlen der ABAP-Laufzeit aus der Datenbank gelesen und unter Berücksichtigung weiterer Informationen wie Benutzername (sy-uname) Sätze in der korrespondierenden Struktur geprüft, abgeleitet oder erzeugt werden.
Sie können die Planung im BW durch die Verwendung datenbankinterner Routinen in der SAP HANA-Datenbank SAP HANA-optimiert ausführen. Wenn Sie den Planning Applications Kit verwenden, empfehlen wir, die kundenspezifische Exit-Funktionalität für Merkmalsbeziehungen und Datenscheiben ebenfalls direkt in der SAP HANA-Datenbank mittels SQLScript zu implementieren. Andernfalls schöpfen Sie nicht in jedem Fall die Möglichkeiten der Performanceoptimierung aus: Plandaten müssten dann an die ABAP-Laufzeit übergeben und satzweise verarbeitet werden. Während das für Darstellung der Daten analytischer Queries keinen Nachteil darstellt, da die Daten in der ABAP-Laufzeit ohnehin verfügbar sind, kann es sich auf die Performance nachteilig auswirken, wenn Disaggregation (Top-Down-Verteilung) oder Planungsfunktionen auf Massendaten ausgeführt werden. In solchen Fällen findet nämlich die ganze Datenverarbeitung in der SAP HANA-Datenbank statt; eine ABAP-Implementierung der Exit-Funktionalität würde demnach verhindern, dass die Performance optimiert wird.
Beachten Sie jedoch folgendes: Auch wenn Sie für alle Methoden, die in Merkmalsbeziehungen und Datenscheiben verwendet werden, SQLScript-Procedures implementieren, müssen dennoch auch die korrespondierenden ABAP-Implementierungen vorhanden sein, weil das System in bestimmten Situationen die ABAP-Äquivalente anstößt, um eine satzweise Datenübertragung zwischen dem BW-System im SAP NetWeaver Stack und der SAP HANA-Datenbank zu vermeiden.
Im Falle einer SQLScript-Implementierung werden die Namen der implementierenden SQLScript-Procedures in der ABAP-Laufzeit bestimmt und weitere Parameter, die nur im SAP NetWeaver Stack verfügbar sind (wie der Benutzername im Systemfeld sy-uname), für die spätere Verwendung in der SQLScript-Implementierung ermittelt.
Die SAP HANA-spezifischen Schnittstellen haben folgende Aufgaben: