Teil 1: BW/4HANA Conversion ohne Variablen-Chaos: So gelingt die Ablösung des Customer Exit „RSR00001“ durch das neue BAdI-Konzept

Die Migration von SAP BW-Systemen nach BW/4HANA ist weit mehr als eine reine technische Systemkonvertierung. Neben Anpassungen an Datenmodellen, Prozessketten und Reporting-Objekten betrifft die Conversion insbesondere auch kundeneigene Entwicklungen im Bereich der Variablenverarbeitung. Ein zentrales Thema dabei ist die Ablösung der klassischen Customer-Exit-Technologie über die Erweiterung RSR00001 durch das moderne BAdI-Konzept in BW/4HANA.

Viele historisch gewachsene BW-Landschaften enthalten umfangreiche Exit-Logiken zur dynamischen Befüllung von Variablen. Diese wurden häufig über Jahrzehnte erweitert und sind tief in Reporting- und Planungsprozesse integriert. Im Rahmen einer BW/4HANA In-Place Conversion müssen diese Entwicklungen technisch und architektonisch neu bewertet werden. Der folgende Beitrag beleuchtet die Hintergründe, Migrationsoptionen, technische Herausforderungen sowie bewährte Vorgehensweisen für die Umstellung von Exit-Variablen auf das neue BAdI-basierte Framework.

Ausgangssituation: Customer Exits mit RSR00001

In klassischen SAP BW-Systemen wurden Customer-Exit-Variablen typischerweise über die Erweiterung RSR00001 implementiert. Die zentrale Logik befand sich dabei meist im Funktionsbaustein EXIT_SAPLRRS0_001. Über die Parameter I_VNAM, I_STEP sowie I_T_VAR_RANGE konnten Variablenwerte dynamisch gelesen, manipuliert oder abgeleitet werden.

Dieses Verfahren war über viele Jahre der technische Standard für kundeneigene Variablenlogik in SAP BW. Besonders verbreitet waren dabei Szenarien wie:

automatische Periodenableitung,
benutzerabhängige Selektionen,
Hierarchieermittlungen,
Berechtigungsprüfungen,
dynamische Zeitintervalle,
variable Kaskadierungen.

Mit BW/4HANA verfolgt SAP jedoch konsequent einen objektorientierten Ansatz. Die klassische CMOD-Erweiterung RSR00001 wird daher nicht mehr unterstützt und muss durch das BAdI RSROA_VARIABLES_EXIT_BADI ersetzt werden.

SAP beschreibt diese Umstellung explizit in der offiziellen BW/4HANA-Dokumentation und empfiehlt die Nutzung filterabhängiger BAdI-Implementierungen zur Trennung und Modularisierung der Variablenlogik.

Das neue BAdI-Konzept in BW/4HANA

Das BAdI RSROA_VARIABLES_EXIT_BADI übernimmt in BW/4HANA die Funktionalität der bisherigen Customer Exits. Technisch basiert die Verarbeitung nun auf objektorientierten Klassenimplementierungen anstelle zentraler Funktionsbausteine.

Die Verarbeitung erfolgt weiterhin über unterschiedliche Verarbeitungsschritte (I_STEP), beispielsweise:

Schritt 1: Vorbelegung von Variablen,
Schritt 2: Verarbeitung nach Benutzereingabe,
Schritt 3: Validierung,
Schritt 0: Initialisierung.

Die grundsätzliche Funktionsweise bleibt damit fachlich vergleichbar. Die technische Architektur unterscheidet sich jedoch erheblich.

Insbesondere erzeugt das Framework bei jedem Verarbeitungsschritt neue Instanzen der jeweiligen BAdI-Klasse. Genau daraus ergeben sich zahlreiche Herausforderungen bei der Migration bestehender Exit-Logiken.

Zwei etablierte Migrationsansätze

In der Praxis haben sich zwei unterschiedliche Strategien zur Migration bestehender RSR00001-Implementierungen etabliert.

1. Separate BAdI-Implementierung je Variable

Der von SAP bevorzugte Ansatz besteht darin, für einzelne Variablen oder fachliche Gruppen jeweils eigene BAdI-Implementierungen anzulegen. Dabei wird die Filterfunktionalität des BAdIs genutzt, um unterschiedliche Variablen gezielt einzelnen Klassen zuzuordnen.

Die Vorteile dieses Ansatzes liegen insbesondere in:

klarer fachlicher Trennung,
besserer Wartbarkeit,
höherer Transparenz,
objektorientierter Architektur,
vereinfachtem Debugging.

Gerade in modernen BW/4HANA-Systemen mit Clean-Core-Strategie ist dieser Ansatz langfristig sinnvoll. Fachliche Verantwortlichkeiten lassen sich sauber trennen und technische Abhängigkeiten reduzieren.

Allerdings bedeutet dieser Weg häufig einen hohen initialen Migrationsaufwand. Historisch gewachsene Exit-Logiken müssen analysiert, zerlegt und teilweise vollständig neu strukturiert werden.

Besonders bei großen BW-Systemen mit mehreren hundert Exit-Variablen kann dies erhebliche Projektressourcen binden.

2. Zentraler Wrapper-Ansatz

Viele Kunden entscheiden sich daher zunächst für einen pragmatischeren Migrationsweg. Dabei wird die bisherige RSR00001-Logik nicht vollständig neu entwickelt, sondern über eine zentrale Wrapper-Klasse weiterverwendet.

Das BAdI fungiert hierbei lediglich als Einstiegspunkt und delegiert die Verarbeitung an bestehende Klassen oder Funktionsbausteine. Technisch ähnelt dies einer Adapter-Architektur.

Typischerweise erfolgt dabei:

Aufruf des BAdIs,
Übergabe der Variablenparameter,
Weiterleitung an bestehende Exit-Logik,
Rückgabe der Variablenwerte.

Der wesentliche Vorteil dieses Ansatzes besteht in der schnellen technischen Conversion bei minimalen Änderungen an bestehendem Code.

Gerade bei In-Place Conversions mit engem Zeitrahmen stellt dies häufig den wirtschaftlich sinnvollsten Weg dar.

Langfristig empfiehlt sich dennoch ein schrittweises Refactoring in fachlich getrennte BAdI-Implementierungen.

Bedeutung von I_T_VAR_RANGE und Variablen-Weitergabe

Ein zentraler Aspekt bei der Migration betrifft die Übergabe und Verarbeitung abhängiger Variablen.

Bereits im klassischen RSR00001-Konzept spielte die Tabelle I_T_VAR_RANGE eine wichtige Rolle. Sie enthält die Werte bereits verarbeiteter Variablen und ermöglicht dadurch variable Abhängigkeiten innerhalb einer Query.

Beispiele hierfür sind:

Ableitung von Perioden aus Geschäftsjahren,
dynamische Werksselektion basierend auf Benutzerrollen,
Hierarchieeinschränkungen,
Folgevariablen mit Kaskadierung.

Im BAdI-Konzept bleibt diese Logik grundsätzlich erhalten. Allerdings verändert sich die technische Behandlung der Variablenzustände erheblich.

Da jede Verarbeitung über neue Klasseninstanzen erfolgt, können zuvor zwischengespeicherte Werte verloren gehen, sofern diese nicht korrekt persistiert werden.

Genau hier entstehen viele der typischen Fehlerbilder nach einer BW/4HANA Conversion.

Doch warum funktionieren Variablen, die über Jahre stabil gelaufen sind, nach der Conversion plötzlich nicht mehr zuverlässig? Die Antwort liegt in einem technischen Detail des neuen BAdI-Frameworks, das in vielen Projekten unterschätzt wird – und häufig erst im Integrationstest sichtbar wird. Darum geht es in Teil 2: BW/4HANA Conversion ohne Variablen-Chaos (Teil 2): Die unterschätzte Falle im neuen BAdI-Framework.

Über den Autor

Dennis Slanar

Dennis Slanar ist Senior Manager bei der movisco AG und verfügt über 9 Jahre Berufserfahrung im Projektmanagement, sowie der Umsetzung und Migration von (SAP) DWH-Lösungen. Dabei ist er mit allen Phasen eines Projektes von der Initiierung über die Analyse & Konzeption, logische und physische Datenmodellierung, Entwicklung und Testdurchführung bis zur Produktivsetzung vertraut. Er besetzt in seinen Projekten unterschiedliche Rollen und berät die Kunden in den Themen Datenmanagement, Datenintegration, Data Warehousing, Anforderungsanalyse, Reporting und Projektmanagement gestützt auf SAP und Non-SAP Systeme. Infolgedessen bringt er Erfahrung im LSA und LSA++ und modellgetriebenen Architekturansatz (HANA SQL DWH) mit. Ferner sind ihm hybride DWH-Lösungen geläufig.