BW/4HANA Conversion ohne Variablen-Chaos (Teil 2): Die unterschätzte Falle im neuen BAdI-Framework

Dieser Beitrag baut auf dem ersten Teil unserer zweiteiligen Beitragsreihe auf: „BW/4HANA Conversion ohne Variablen-Chaos (Teil 1): So gelingt die Ablösung des Customer Exit RSR00001 durch das neue BAdI-Konzept“. Darin erläutern wir die technischen Grundlagen der Migration sowie die gängigen Migrationsstrategien. Die eigentlichen Herausforderungen zeigen sich jedoch häufig erst während der praktischen Umsetzung und im Testing.

Kritischer Punkt: Instanzattribute vs. statische Attribute

Eine der häufigsten Ursachen für fehlerhafte Exit-Variablen nach der Migration betrifft die Verwendung von Klassenattributen.

In vielen älteren Entwicklungen wurden Werte während der Verarbeitung in Instance-Attributen gespeichert. Dies funktionierte im klassischen RSR00001-Kontext problemlos, da die Verarbeitung innerhalb desselben Funktionsbausteinkontexts erfolgte.

Im BAdI-Framework erzeugt SAP jedoch bei jedem Verarbeitungsschritt eine neue Objektinstanz.

Das bedeutet konkret:

Instance-Attribute werden bei jedem I_STEP neu initialisiert,
zwischengespeicherte Werte gehen verloren,
Folgevariablen erhalten inkonsistente Daten,
Kaskadierungen funktionieren nicht mehr zuverlässig.

Besonders kritisch ist dies bei:

Cache-Mechanismen,
Vorberechnungen,
Benutzerkontexten,
temporären Tabellen,
Hierarchieableitungen.

Die Lösung besteht darin, persistente Zustände auf statische Attribute umzustellen.

Statische Attribute bleiben über mehrere Verarbeitungsschritte hinweg erhalten und ermöglichen damit die konsistente Weitergabe von Informationen innerhalb der Queryverarbeitung.

Diese technische Anpassung wird in vielen Projekten unterschätzt, obwohl sie häufig entscheidend für die Stabilität der Variablenlogik ist.

Typische Fehlerbilder nach der Conversion

In BW/4HANA-Projekten treten im Zusammenhang mit Exit-Variablen regelmäßig ähnliche Probleme auf.

Fehlende Variablenwerte

Variablen werden in Schritt 1 korrekt ermittelt, stehen jedoch in Schritt 2 oder 3 nicht mehr zur Verfügung.

Ursache ist meist die Speicherung in Instance-Attributen.

Inkonsistente Folgevariablen

Abhängige Variablen erhalten unterschiedliche Ergebnisse abhängig von der Ausführungsreihenfolge.

Häufig fehlt hierbei eine saubere Synchronisierung über statische Attribute oder zentrale Kontextobjekte.

Performanceprobleme

Durch die mehrfache Neuinstanziierung werden Datenbankzugriffe mehrfach ausgeführt.

Besonders problematisch sind dabei komplexe Berechtigungsprüfungen oder Hierarchieermittlungen.

Statische Cache-Mechanismen können hier erhebliche Performanceverbesserungen erzielen.

Unübersichtliche Wrapper-Strukturen

Bei zentralen Wrapper-Ansätzen entstehen häufig große monolithische Steuerklassen mit zahlreichen Sonderlogiken.

Ohne klare Strukturierung steigt langfristig die technische „Verschuldung“ erheblich.

Empfehlungen für die Praxis

Aus Projekterfahrung haben sich mehrere Best Practices etabliert.

Frühzeitige Analyse der Exit-Landschaft

Vor Beginn der Conversion sollte eine vollständige Analyse aller Exit-Variablen erfolgen:

Welche Variablen sind aktiv?
Welche Abhängigkeiten existieren?
Welche Variablen werden tatsächlich genutzt?
Welche Logiken können entfallen?

In vielen Systemen existieren zahlreiche historische Entwicklungen ohne fachliche Nutzung.

Wrapper nur als Übergangslösung

Ein zentraler Wrapper erleichtert die technische Migration erheblich. Langfristig sollte jedoch eine schrittweise fachliche Modularisierung erfolgen.

Konsequente Nutzung statischer Attribute

Persistente Zustände dürfen nicht mehr in Instance-Attributen gehalten werden.

Statische Attribute oder dedizierte Kontextklassen sind essenziell für stabile Verarbeitung.

Saubere Behandlung von I_STEP

Die Verarbeitungsschritte müssen klar getrennt implementiert werden. Vermischte Logiken führen häufig zu schwer reproduzierbaren Fehlern.

Performanceoptimierung früh berücksichtigen

Durch die neue Architektur entstehen zusätzliche Objektinstanzen und potenziell mehr Datenbankzugriffe.

Caching und zentrale Hilfsklassen gewinnen daher deutlich an Bedeutung.

Fazit zur erfolgreichen Migration von Exit-Variablen in BW/4HANA

Die Migration von Exit-Variablen gehört zu den technisch anspruchsvolleren Themen einer BW/4HANA In-Place Conversion. Zwar bleibt die fachliche Funktionalität grundsätzlich erhalten, die zugrunde liegende Architektur verändert sich jedoch erheblich.

Insbesondere die Ablösung von RSR00001 durch das BAdI RSROA_VARIABLES_EXIT_BADI erfordert eine sorgfältige Analyse bestehender Entwicklungen.

Unternehmen stehen dabei typischerweise vor der Entscheidung zwischen einer vollständigen objektorientierten Neuentwicklung oder einem pragmatischen Wrapper-Ansatz zur Wiederverwendung bestehender Logik.

Von zentraler Bedeutung ist dabei das Verständnis der neuen Instanziierungslogik des BAdI-Frameworks. Die Umstellung von Instance- auf statische Attribute ist in vielen Fällen zwingend erforderlich, um konsistente Variablenverarbeitung über mehrere Verarbeitungsschritte sicherzustellen.

Projekte, die diese technischen Besonderheiten frühzeitig berücksichtigen, können die Conversion deutlich stabiler und effizienter umsetzen.

Ü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.