Serie: Entwurfsmuster für BW/4HANA Customer Exit Variablen
Veröffentlicht am 4. Januar 2021 von | ABAP | BEx Query Variables |
Einleitung
In dieser Artikelserie beschäftige ich mich mit einem Thema, das für jedes BW/4HANA Projekt relevant ist: Die Implementierung der Customer Exit Variablen. Hier gibt es jede Menge Wildwuchs und in den meisten älteren BW-Systemen sieht es dort reichlich chaotisch aus. Das gilt auch dann, wenn mal jemand ein "Framework" für die Auslagerung des Codes entwickelt hat.
Der Titel legt nahe, dass im BW/4HANA im Gegensatz zum klassischen BW irgend etwas anders wäre. Das ist aber leider nicht der Fall, der Title wurde nur aus Marketing Gründen gewählt. ;-) Leider hat die SAP die Chance verpasst, mit dem BW4 hier ein alternatives Konzept zu wählen.
Ein Vorteil gibt es aber bei vielen BW/4HANA Projekten, nämlich dass es sich um Greenfield Projekte handelt. Das bedeutet, es besteht die Chance, gleich von Anfang an Dinge besser zu machen, als sie im alten Vorgängersystem waren.
Übersicht über die einzelnen Themen
Diese Serie besteht aus den folgenden Beiträgen. Am besten liesst man sich von vorne nach hinten durch das Thema durch.
Ein bekanntes Thema
Mit den Problemen haben sich auch schon viele andere Autoren (und Berater) beschäftigt, und sie sind zu unterschiedlich eleganten Ansätzen gekommen. Beispielsweise
- Tobias Meyer in seinem Blog mit einem eigenen BAdI mit Filter auf die Variablen
- Thorsten Kessler in seinem Blog mit Artikeln über
- Denis Reis beschreibt einen Fuba basierten Ansatz in diesem Artikel
Das ist nur ein kleiner Ausschnitt aus den Artikeln über dieses Thema. Das zeigt vor allem: Hier gibt es Optimierungsbedarf. Und das deckt sich auch mit meinen Erfahrungen aus einigen großen BW/4HANA Projekten.
Die Perspektive eines Entwicklers
Da ich früher als ABAP-Entwickler und -Entwicklungsleiter in der Produktentwicklung tätig war, habe ich ein anderes Verständnis von Qualität und sauberem, wartbarem Code als Entwickler, die überwiegend in Kundenprojekten unterwegs sind. Insbesondere habe ich wesentlich mehr Erfahrung als viele BW-Berater, für die die ABAP Entwicklung nur ein sehr kleiner Teil der täglichen Arbeit darstellt.
In meinen letzten Projekten hat sich aber diese Erfahrung aus der ABAP Produktentwicklung als sehr hilfreich rausgestellt. Denn wenn es über die einzelnen Variableneexits oder eine einzelne Transformationsroutinen hinaus geht, insbesondere wenn Konzepte und Frameworks benötigt werden, dann spielen die Themen Clean Code, UnitTests, Wartbarkeit und Zuverlässigkeit eine große Rolle.
Aus dieser Perspektive heraus möchte ich einen Vorschlag für ein wirklich sauberes Entwurfsmuster für die Implementierung von Customer Exit Variablen machen. Dabei werden die Prinzipien der modernen Softwareentwicklung berücksicht, insbesonder des Clean Code und der Testgetriebenen Entwicklung. Es soll aber auch einfach praktische Vorteile, insbesondere viel Transparenz bei der täglichen Arbeit mit den Variablen erreicht werden. Unter anderem
- Entkopplung des Codes der Variablen, so das möglichst wenig Abhängikeiten bestehen. So können sich Änderungen nicht auf das ganze System auswirken.
- Abhängigkeiten der Variablen untereinander werden aus dem Code in ein Customizing verlagert. Somit werden diese gut sichtbar.
- Gemeinsame Logiken werden nur einmal entwickelt und können ohne Risiko wiederverwendet werden
- Ähnliche Logiken werden über Parameter wieder verwendbar. Die Parametrisierung ist wiederum gut sichtbar.
- Standardaufgaben werden mit Hilfsmethoden erledigt, was die den Code der einzelnen Variablen einfacher und stabiler macht.
- Jede Implementierung einer Customer Exit Variablen kann mit ABAP UnitTests überprüft werden.
Doch zunächst starte ich mit der Analyse der Situation. Warum gibt es so viel Wildwuchs, was sind die Ursachen und was können wir daraus lernen. Diese Fragen behandele ich im Artikel Probleme bei Customer Exit Variablen
