SAP BW/4HANA hat eine komplett neue Codeline, die um drei bis vier Millionen Codelines bzw. Zeilen reduziert wurde. So kommt BW/4HANA mit deutlich weniger Code und auch ohne NetWeaver aus. Resultat ist eine schnellere Gesamtperformance des Systems. In erster Linie profitieren Kunden bzw. Anwenderunternehmen deshalb von einer schnelleren Bereitstellung von Updates, neuen Funktionen und einer besseren Systemperformance.

Ein Umstieg auf BW on HANA bzw. BW/4HANA ist auf Grund des End-of-Life BW 7.5 unausweichlich (PAM: „SAP BW 7.5 will continue to the end of 2027 with extended maintenance to 2030.“). Im Gegensatz zu den bisherigen BW-Varianten fehlt im BW/4HANA übrigens eine integrierte Planungsfunktionalität.

Ob ein Redesign mit Greenfield-Ansatz, Brownfield oder lediglich eine Migration oder gar eine Mischform sinnvoll ist, wird in Zusammenarbeit mit unseren Kunden erarbeitet.

So z.B. ist ggf. auch ein ABAP-Coding für eine erhebliche Geschwindigkeitssteigerung nicht komplett umzubauen, sondern nur die Performance-kritischen Teile können in SQL remodelliert werden, um so die Projektkosten einer wenig sinnvollen kompletten Code-Remodellierung zu reduzieren.

Um bereit für eine BW/4HANA zu sein, dürfen u.a. keine DSOs, Cubes, Multiprovider/Infosets, 3.5er-Transformationen, Infopackages usw. verwendet werden.

Der Umbau kann halbautomatisch erfolgen, ohne jedoch das neue Potential der HANA Datenbank wirklich auszuschöpfen. Anpassen der Transformationen auf neue BW/4HANA -Objekte, z.T. dadurch Anpassen der Codings erforderlich

Möglich ist auch eine Datenversorgung aus den Quellsystemen mittels Operational Data Provisioning oder Change Data Capturing von CDS-Views im ERP. Auch hier wird untersucht, ob ein Nutzen der neuen Technologien zur Datenbeschaffung sinnvoll ist.

Während Transformationen (ohne ABAP) oder Aktivierungen erheblich beschleunigt werden, hat der Einsatz der HANA-Datenbank auf ABAP-basierte Transformationen wenig Einfluss.

Um das Potential der HANA besonders effektiv nutzen zu können, wird ein Code Push-Down notwendig, insbesondere ein Umbau der ABAP-Transformationen auf HANA-SQLScript.

Es gibt viele Möglichkeiten ein bestehendes BW-System in die neue Welt zu migrieren.

Somit konzentrieren wir uns auf die Verwendung von ABAP in Transformationen:

Diese Vorgehensweisen sind natürlich abhängig von dem Ursprungs-ABAP sowie den ABAP und SQLScript Skills des BW-Mitarbeiters.

Kommen wir also nun zu der Frage, wie kann eine solche Migration ablaufen?

1. „Entrümpeln“ des ABAP, um nicht mehr verwendete Code-Strecken zu eliminieren/auszukommentieren

2. Vereinigung von Start-/Feld- und Endroutinen, am besten zu einer Endroutine. Dies erleichtert die folgende SQL-Konvertierung. Dies ist eine Empfehlung, aber nicht zwingend erforderlich.

3. Anlegen von InfoSourcen und einer 1:1 SQL Transformation. (siehe Datenflussdiagramm, ganz rechts)

4. Heraussuchen eines ABAP-Abschnitts, der zeitaufwändig erscheint und häufig genutzt wird, auskommentieren und Umsetzen nach SQL. (In den folgenden Codings das intabY=select i.*,… from :intabX i;)

5. jeweils für einen weiteren umformulierten SQL-Abschnitt.

6. Gegebenenfalls Testlauf der neuen Transformation und Abgleich mit den Ergebnissen der ursprünglichen Transformation

7. Wieder zurück zu Punkt 4, bis alles nach SQL migriert wurde, oder die Geschwindigkeit ausreichend ist. Selten durchlaufenes oder zu komplexes Coding sollte ggfs. nicht konvertiert werden

8. Ggfs. DTP‘s austauschen und optional Aufräumen der alten Routinen

Alle Codings existieren parallel: Die Originaltransformationen, die „entrümpelte“ ABAP Endroutine, und die schrittweise konvertierte ABAP-SQL Transformation. Somit können sämtliche Varianten gegeneinander getestet und die Ergebnisse miteinander verglichen werden.

Es bestand die Befürchtung, dass Teile des BW bei neuen Anforderungen oder im Fehlerfall nicht mehr neu aufgebaut werden könnten. Auf der BW-Testmaschine wurden die Zeiten aller DTPs bei einem Neuaufbau aufgenommen und drei besonders teure Transformationen identifiziert.

Weitere, ebenfalls langlaufende Transformationen wurden wegen der zu hohen Komplexität der Geschäftslogik für einen Umbau nicht in Betracht gezogen. Innerhalb des ABAP-Codings konnten wiederum Bereiche ausgemacht werden, die nur für bestimmte Belege und nur selten durchlaufen werden, andere hingegen aufwendige Nachleselogiken bei jedem Satz erforderten. Hierauf lag zunächst der Fokus der Optimierung.

Neben dem Entrümpeln und der Vereinigung von Start-, Feld- und Endroutinen und vorbereitend dem Aufsplitten in zwei sukzessiven Transformationen (zu entwickelndes SQL gefolgt von dem Original-ABAP) begann der Umbau.

Begonnen wurde mit dem wichtigsten Block, den Fakturen. Bei der Erreichung einer „ausreichenden“ Geschwindigkeit wurde der Umbau hier beendet und mit den Aufträgen und Lieferungen fortgefahren. Auch bei den Aufträgen wurde nur etwa die Hälfte des Codings nach SQL übersetzt, der Lieferungen-Datenfluss konnte sogar komplett nach SQL umformuliert werden (so dass die Laufzeit komplett auf HANA umgeschaltet werden konnte).

Natürlich wurden ständig die Laufzeiten gemessen und die Transformationsergebnisse verglichen. Wahrscheinlich hätte auch das ABAP-Coding nochmal erheblich optimiert werden können, so dass die Ergebnisse nur bedingt verallgemeinerbar sind.

Es gibt kein Entweder -Oder oder gar ein Richtig oder Falsch. Mischformen zwischen ABAP und SQL sind möglich. Auch konnten einige SQL-Codings aus den Fakturen später beim Umbau der Lieferungen mit nur geringen Änderungen „wiederverwendet“ werden, so dass sich sogar eine Art Coding-Bibliothek herausgestellt hat.

Bei Interesse liefern wir Ihnen gern Coding-Beispiele für eine strukturierte und beschleunigte Umsetzung aus. Wenden Sie sich in diesem Fall an …