Mit SAPDie SAP SE mit Sitz im baden-württembergischen Walldorf ist ein… More Datasphere entwickelt SAP seine Datenplattform konsequent weiter in Richtung Cloud-Zukunft. Für viele BW-Anwender stellt sich die Frage: Wie bilde ich gewohnte BW-Konzepte wie Customer Exit Variablen in der neuen Welt ab? Die Antwort: Abgeleitete Variablen in SAP Datasphere. Ist diese Antwort aber valide?
In diesem Beitrag beleuchten wir die neuen sogenannten abgeleiteten Variablen (Derived Variables) durch die Demonstration eines typischen Customer Exit Anwendungsfall in SAP Datasphere und versuchen, diese Antwort in der Praxis zu prüfen.
Was sind Customer Exit Variablen in SAP BW?
In SAP BW erlauben Customer-Exit-Variablen (Typ “Customer Exit”) die dynamische Ermittlung von Variablenwerten zur Laufzeit. Zum Beispiel den ersten Tag des aktuellen Monats, den aktuellen Benutzer oder eine komplexe Hierarchiestufe. Die Logik wird in ABAP über das User-Exit Include ZXRSRU01 (bzw. BADI_RSR_VARIABLES_EXIT) umgesetzt und bietet große Flexibilität.
Typische Einsatzszenarien:
- Automatische Auswahl von Zeiträumen
- Einschränkung von Daten je nach Benutzerrolle
- Logikgesteuerte Filterwerte in Queries
Abgeleitete Variablen in SAP Datasphere – Was ist das?
Mit den abgeleiteten Variablen bietet SAP Datasphere ein vergleichbares Konzept. Diese werden innerhalb einer Analytischen Modells (Analytical Model) definiert. Anders als in BW wird die Logik nicht in ABAP, sondern in der grafischen Oberfläche oder mittels SQL Script abgebildet.
Eine abgeleitete Variable ist eine Variable, deren Wert nicht direkt vom Benutzer eingegeben wird, sondern automatisch vom System über eine Nachschlagetabelle (Lookup-Entität) ermittelt wird. Diese Lookup-Entität kann z. B. eine Tabelle oder ein View sein, in dem die relevanten Informationen hinterlegt sind.
Die Ableitung funktioniert so, dass basierend auf einem bekannten Eingabewert (wie etwa einem Land) automatisch ein dazugehöriger anderer Wert (wie z. B. die passende Währung) gefunden und gesetzt wird. Dieser abgeleitete Wert wird nicht im Eingabedialog angezeigt, weil der Nutzer ihn nicht direkt sieht oder ändert. Er wird im Hintergrund vom System bestimmt.
Abgeleitete Variablen: Ein Anwendungsbeispiel:
Abgeleitete Variablen sind ideal für Anwendungsfälle, in denen man standardisierte Filterwerte dynamisch benötigt in etwa wie:
- Das automatische Filtern auf den aktuellen Tag/Woche/Monat
- Filterung auf den eingeloggten Benutzer zur Dateneinschränkung
- Dynamische Berechnung von Zeiträumen ohne Benutzereingabe
Im folgenden Beispiel werden wir ein Anwendungsfall demonstrieren, indem wir Datumsfelder einer Faktenquelle dynamisch durch selbstdefinierte Zeitintervalle festlegen. Dabei sollen Intervalle nicht durch manuelle Eingabe von Datumswerte, sondern durch die einfache Auswahl einer Intervalldefinition festgelegt werden.
Implementierungsschritte:
Damit die Input Variablen eine dynamische Herleitung aus einer Lookup Entität haben statt der manuellen Eingabe werden drei Views mit der Semantic Usage „Dimension“ benötigt:
1. Dimension:
Dimension Tag kann mit wenig Aufwand in der Space Konfiguration generiert werden.
2. Dimension: Zeitintervalle
Die Dimension der Zeitintervalle ist eine View, hinter der eine SQL-Logik steht, die in diesem Anwendungsfall die Definition der Auswahlliste mit dynamischer Datumzuordnung festlegt. Unabhängig von diesem Demo Fall muss diese View nicht zwingend nur die Verarbeitung von Daten unterstützen. Sie kann jedes beliebige Eingabeobjekt definieren.
3. Dimension: Lookup Entität.
Diese View ist notwendig für Assoziation mit dem Analytic Model und sie muss nach der Eingabe von Input Parameter immer nur ein Wert zurückgeben.
Die folgende Grafik zeigt das Zusammenspiel aller drei Dimensionen:
1. Dimension Zeitintervalle:
Für unseren Use Case benötigen wir zwei dynamische Auswahlwerte: Current Month & Last Month. Um diese Werte durch eine View zu realisieren, bauen wir eine SQL Abfrage, die folgende Spalten zurückgibt:
Angenommen der heutige Tag wäre 22.05.2025, dann wäre die Rückgabe wie folgt:
| Beschreibung | Startdatum | Enddatum |
|---|---|---|
| Current Month | 01.05.2025 | 01.04.2025 |
| Last Month | 31.05.2025 | 30.04.2025 |
Hierfür wird die folgende SQL Abfrage verwendet:
2. Dimension Lookup Entität:
Die Lookup Entität ist das Objekt, welches später mit dem Analytic Model assoziiert wird, um die den Parametern Werte zu übermitteln. Diese View hat die Aufgabe, basierend auf dynamische Variablen einzelne Dateneinträge zu filtern und auszugeben.
Durch die folgenden Schritte wird die Lookup Entität für die Verwendung bereitgestellt, dabei müssen folgende Punkte beachtet werden:
- Diese View braucht ein Filterknoten, um Einzelwerte zurück geben zu können
- Dieser Filter basiert auf Input Variablen, die den Start und Enddate eindeutig erkennt und zurückgibt
- Der Input Variabel leitet die Auswahlliste durch eine logische Assoziation zur Dimension im Schritt 1 (siehe Screenshot).
3. Faktenquelle und Analyse Modell:
Nun benötigt die Faktenquelle, dessen Datumswerte gefiltert werden müssen, ebenso dynamische Input Variablen. Alle erstellten Input Variablen werden später wie Puzzle in Zusammenspiel gebracht:
Zum Schluss werden alle Objekte und Variablen in Verbindung gebracht. Die Input Variablen der Faktenview müssen so eingestellt werden, dass sie ihre Werte aus der Lookup Entität herleitet.
Der vorherige Anwendungsfall ist eine kleine Demonstration dessen, was mit dynamischen Lookup-Variablen in Datasphere möglich ist. Dieses Szenario kann mit beliebigen Werten (Kostenstellen, Organisationseinheiten etc.) ausgeführt werden.
Ersetzt das die Funktionalitäten der Customer Exit Variablen?
Abgeleitete Variablen in SAP Datasphere sind durchaus nicht als „Customer Exit Datasphere Edition“ zu verstehen. Sie ersetzen also nicht die Customer Exit Variablen aus SAP BW vollständig, bilden allerdings einen Teil der Funktionalität ab und können für viele Standardszenarien eingesetzt werden.
Hier ein kurzer Vergleich:
| Merkmal | SAP BW Customer Exit | SAP Datasphere Abgeleitete Variable |
|---|---|---|
| Technologie | ABAP basiert | Kein ABAP – grafisch bzw. expression-based |
| Flexibilität | Sehr hoch (programmierbar) | Eingeschränkter, aber wachsend |
| Laufzeit | Bei Ausführung der Query | Bei Ausführung des analytischen Modells |
| Kontextabhängigkeit | Vollständig (Benutzer, Rollen etc.) | Eingeschränkt (Benutzername, Datum, evtl. mehr) |
| Implementierung | EXIT_SAPLRRS0 bzw. BAdI | Innerhalb des Analytical Models, ggf. zentral über Lookup Entitäten |
| Wartbarkeit / Upgrade-Freundlichkeit | Wartungsintensiv, teils komplex | Intuitiver im UI, Cloud zentrisch |
Fazit
Hergeleitete Variablen („Derived Variables“) bieten einen zeitgemäßen Ansatz, um typische Anwendungsfälle von BW Exit Variablen in der Cloud-Welt umzusetzen. Im Rahmen einer Migration lohnt es sich daher genau zu analysieren, welche Aufgaben früher über Customer Exits gelöst wurden und wie diese Anforderungen heute mit den Möglichkeiten der SAP Datasphere abgebildet werden können. Dabei zeigt sich: Einige Funktionen lassen sich direkt über Derived Values realisieren, andere hingegen erfordern alternative Lösungsansätze innerhalb des neuen Datenmodells.
Haben Sie Fragen? Sprechen Sie uns gerne an!
Christopher Kampmann
Senior Manager
SAP Information Management
christopher.kampmann@isr.de
+49 (0) 151 422 05 448
