Woran Sie merken, dass Ihr Business Data Toolset (BDT) ein Refactoring braucht

Woran Sie merken, dass Ihr Business Data Toolset (BDT) ein Refactoring braucht

SAPs BDT (Business Data Toolset) dient in jedem Financial Services Modul zur Erweiterung der Stammdaten um kundeneigene Felder, Tabellen und Prüfungen. Im Zuge der FS Modul-Einführung werden hier meist erste Kundenerweiterungen durchgeführt. Nach und nach werden in der Wartung und in Folgeprojekten neue Felder und Prüfungen hinzugefügt. Aufgrund der Komplexität des BDTs, mangelhafter Dokumentation und unzureichender Entwickler Skill-Sets verfällt die kundeneigene BDT Codebasis zusehends. Die Folge sind nicht dokumentierte, unlesbare, schlecht wartbare und fehleranfällige BDT Entwicklungen die hohe Wartungskosten erzeugen. Zeit über ein Refactoring mit anschließender Neuausrichtung der BDT Entwicklung nachzudenken.

Aber wie erkenne ich, ob ein Refactoring meiner BDT Entwicklung notwendig ist?

  1. Eine Inflation BDT bezogener Entwicklungsobjekte

Einer BDT Anwendung liegt eine Funktionsgruppe zugrunde, die die Subscreens und Funktionsbausteine enthält. Werden hier mehrere Funktionsgruppen innerhalb einer Anwendung verwendet, ist dies ein sicheres Zeichen für den Verfall der BDT Anwendung. Eine Inflation von globalen Variablen im Top-Include ist ebenfalls ein Hinweis: im Top-Include sollte nur die einmal vorhandenen lokalen Gedächtnisse deklariert werden.

Ebenfalls zu betrachten sind die Zeitpunkt-Funktionsbausteine der BDT Anwendung. Hier sollte pro BDT Anwendung nur ein Funktionsbaustein pro Event registriert sein.

  1. “Wildwuchs“ im BDT Customizing

Wenn Sie schon dabei sind die Zeitpunkt Funktionsbausteine zu prüfen, so prüfen Sie, dass Kundenfunktionsbausteine nur Kunden-BDT-Anwendungen zu geordnet sind (noch einfacher per Tabelle TBZ1F zu prüfen: Feld FNAME mit Y* oder Z* selektieren und dann in der Ergebnismenge Einträge in Feld APPLI ungleich Y* oder Z* finden).

Suchen Sie weiterhin nach inaktiven Kunden-BDT-Anwendungen. Dauerhaft nicht genutzte Anwendungen sollten zurück gebaut werden.

BDT Screen Layout Objekte (Feldgruppen, Sichten, Abschnitte, Bilder, Bildfolgen) ohne Zuordnung sollten ebenfalls entfernt werden. Durch den Verwendungsnachweis in den entsprechenden Objekten kann geprüft werden, ob das Objekt noch verwendet wird.

  1. Viele Entwickler und hohe Änderungsfrequenz

Wenn viele Entwickler unterschiedlichen Erfahrungsgrades an der BDT Anwendung sehr häufig Änderungen vornehmen, ist dies ebenfalls ein Hinweis auf entstehende Probleme im BDT. Mit Hilfe des SAP Custom Code Management (Teil des Solution Managers) kann man schnell die Entwicklungsobjekte identifizieren, an denen überdurchschnittlich viel und durch viele Entwickler geändert wird.

  1. Mangelnde Modularisierung, keine Separation of Concern

In BDT Funktionsbausteinen, die stets erweitert werden, entwickelt sich oft eine “Add-on” Kultur: Der Entwickler der seine Änderung hinzufügt, hängt sein Coding einfach an den existierenden Code an, um möglichst wenig “Impact” zu erzeugen. Bestehendes Coding, sei es noch so unverständlich, wird nicht reorganisiert. Der Funktionsbaustein wächst in seinen Lines-of-Code und wird in sich nicht mehr weiter modularisiert und wird damit unlesbar und unwartbar. Coding, dass fachlich nichts mit einander zu tun hat, stehen im gleichen Kontext. Eine Trennung der Belange wird nicht erreicht. Sowohl die Trennung der Belange als auch die Limitierung der Lines-of-Code in Modularisierungseinheiten sind Anforderungen aus den offiziellen SAP Programmierrichtlinien.

  1. Unmengen toter und auskommentierter Code

Eine hohe Änderungfrequenz bringt auch immer wieder eine Inflation von auskommentierten oder ungenutzten (toten) Code mit sich. Beides erschwert die Wartbarkeit und sollte abgestellt werden. Da die SAP Versionsverwaltung alle Änderungen an dem Entwicklungsobjekt dokumentiert, sollte das Auskommentieren von Code und das Kommentieren mit Änderungshinweise (z.B. “Start Änderung 24.07.2015 User XYZ”) unterbleiben.

Unbenutzte Variablen und Modularisierungeinheiten erschweren die Lesbarkeit und sollten daher immer entfernt werden. Die neue Eclipse basierte Entwicklungsumgebung unterstützt den Entwickler hervorragend dabei.

  1. Eingriff in die Commit Steuerung des BDT

Die Verbuchung bei partizipierenden Anwendungen findet in der Tabellen besitzenden Anwendung statt, d.h. im Kundencoding dürfen keine Commit Anweisungen abgesetzt werden.

  1. Die Funktionalität entspricht nicht den Anforderungen/Konzepten/Testfällen

Das trifft nicht nur auf BDT Anwendungen zu, hat hier aber noch größere Bedeutung: Da Änderungen im BDT sowohl den Benutzerdialog als auch das Verhalten im Direct Input beeinflussen, ist eine aktuelle Dokumentation der Funktionalitäten unabdingbar. Wenn Testfälle auf alten Anforderungen basieren, kann ein Retest von BDT Funktionalität nur fehlschlagen und falsche Ergebnisse produzieren.

Was tun, wenn die o.g. Punkte zutreffen? Dann ist ein Refactoring unausweichlich. Unter Refactoring ist als erstes mal ein Aufräumen des Codes und der BDT Objekte, wie teilweise oben schon beschrieben, zu verstehen:

– Globale Variablen reduzieren

– toten und auskommentierten Code löschen

– unbenutzte BDT Layout Objekte löschen

– Sinnvoll modularisieren

– COMMITs entfernen und durch in UPDATE TASK Verbuchung ersetzen

– Permanentes Aktualisieren von Konzepten / Dokumentationen / Testfällen

– Code Ownership: Einige, wenige BDT erfahrene Entwickler warten alleine das BDT oder nehmen Änderungen von anderen per Code Review ab

– BDT Know How bei Entwicklern durch Schulungen aufbauen