Stunden der Code-Doctors

Es ist vor allem der bereitgestellte Busi­ness-Content, der die SAP-Standardsoftware bei SAP-Kunden so begehrlich gemacht hat und nach wie vor macht. Es ist aber auch die Möglichkeit, SAP-Software zu verändern.

Und zwar in der Art zu verändern, wie es die individuellen Business- und Prozessnotwendigkeiten (Intellectual Property, kurz: IP) zur Abbildung in der Software erfordern.

Dabei kann es sich um kleinere Programmänderungen oder -erweiterungen handeln, wie etwa die Ergänzung um eine Telefonnummer in einem Report.

Dies können aber auch praktisch komplett neu erstellte beziehungsweise von Entwicklern geschriebene Funktionskomponenten zur Unterstützung respektive Abwicklung firmenspezifischer, teils sehr fein granularer und wettbewerbsdifferenzierender Business-Prozesse sein, wie etwa eine umfangreiche Ersatzteilemanagement-Lösung oder eine Branchenapplikation für die Qualitätssicherung.

Custom Code

So wurde im Laufe der letzten über 20 Jahre weltweit ein immenses Volumen an sogenanntem Custom-Code basierend auf Programmierlogikmethoden bei oder von SAP-Kunden erzeugt.

Dieser Programm-Code inklusive der hinterlegten Regeln oder Logiken erwecken letztendlich die vielen, vielen SAP-Transaktionen zum Leben, die für ein Funktionieren einer SAP-Software in einem Unternehmen verantwortlich sind.

Kreiert wurde derlei Custom-Code vor allem mittels Abap-Programmierung (Abap-Coding). Wobei es sich bei Abap um eine Programmiersprache (oder bei der Abap-Workbench um eine Entwicklungsumgebung) handelt, die sowohl unstrukturierte, strukturierte wie auch objektorientierte Programmierung erlaubt.

Praktisch täglich kommt nach wie vor neuer Custom-Code hinzu. Zehn Millionen Code-Zeilen, aber auch schon mal das Doppelte allein bei einem Unternehmen sind keine Seltenheit.

Groß ist die Schar an SAP-Anwendungsentwicklern allemal. Konzerne beschäftigen mitunter Hunderte von SAP-Programmentwicklern. Und auch bei einer mittelständischen Firma kann eine Anwendungsentwickler-Division eine Mannschaft von 15 oder 20 SAP-Programmierern umfassen.

Selbst ein wenig tiefer Blick in ein SAP-System oder in einen SAP-Source-Code eines Unternehmens stellt praktisch sofort den erzeugten Custom-Code dar.

Hierbei kann es sich um drei unterschiedliche Transaktionstypen handeln. Zum einen um sogenannte z-Transaktionen und zum anderen um y-Transaktionen.

Daneben gibt es Programme samt Transaktionen mit einem eigenen Namensraum (statt z oder y), meist mit einer Firmenbezeichnung, die nebenbei bemerkt bei SAP anzumelden oder zu registrieren sind.

Test unter Hana

Der Kundenbedarf, genau diesen oder jenen kreierten Custom-Code langfristig nutzen zu können, liegt auf der Hand. Auch in der SAP-On-Hana-Welt; beim Einsatz von S/4 Hana, Suite on Hana (SoH), BW on Hana oder etwa dem neuen BW/4 Hana.

Dazu ist es erforderlich, eben den besagten Custom-Code samt verwendeten oder hinterlegten Programmregeln zu analysieren, für die neue Hana-Datenbank-(DB-)Welt vereinfacht ausgedrückt zu präparieren, mittels einer Conversion zu überführen und zu testen.

Zur Unterstützung stellt SAP sogenannte Hana-Code-Compliance-Regeln (Informationen dazu beispielsweise in den SAP-Notes 1912445, 2251947) samt Anleitungen mit Checklisten zur Verfügung.

Diese Art von Therapienotwendigkeiten liegt im DB-Architekturwechsel begründet, den SAP mit Hana realisiert hat. Vereinfacht ausgedrückt funktioniert die Hana-Code-Verarbeitung gemäß einer spaltenorientierten DB-Tabellen-Verarbeitung inklusive Regeln technisch anders als bei einer Any-DB (DB2, Microsoft, Oracle) mit Zeilen-/Spaltenorientierung inklusive Indizes – nämlich bei Aufrufen/Verarbeitung nicht vorsortiert.

Dieser Begebenheit ist Rechnung zu tragen, mittels Programmierzusätzen oder Zuweisungen, die einzufügen sind. Hier gibt es „Must-Dos“, ansonsten läuft ein System auf der neuen Architektur schlicht nicht.

Wichtig ist zudem: Um den Hana-Umfang oder die -Vorteile zu nutzen, sollten auch diverse Source-Code-Verbesserungen umgesetzt werden.

Da derlei Optimierungen manuell kaum beziehungsweise sehr, sehr schwer handelbar sind, wird es fast unmöglich, sie händisch durchzuführen.

Dazu zählen zum Beispiel: eine Optimierung zusätzlicher Source-Code-Konstrukte, um die Vorteile der Hana-Datenbank auszunutzen; Performanceoptimierungen etwa mittels Push-Down-Regeln; oder: dass Teile der Businessfunktionalität auf der DB-Ebene (Filtern, Sortieren etc.) ausgeführt wird respektive läuft – und nicht auf dem Applikations-Layer.

Ob und wie sich der vorhandene Custom-Code (z- und y-Transaktionen sowie Transaktionen mit eigenem Namensraum) nach einer Conversion Hana-seitig auch so verhält wie gewünscht, hängt jedoch stets von mehrerlei Begebenheiten ab.

Mitunter sind sehr tiefe Source-Code-Analysen erforderlich, um eine erfolgreiche Code-Therapie umzusetzen.

Denn: nur im Source-Code liegt faktisch die Wahrheit.

Und: Wer ohne Code-Therapie einen On-Hana-Einsatz startet, läuft Gefahr, dass die Programme nach einem Umstieg auf ein On-Hana-System wie etwa S/4 Fehler aufweisen.

Schlicht formuliert: Die Programmteile in einem SAP-On-­Hana-System auf der Basis von Custom-Code funktionieren hier und da nicht mehr wie gehabt, mit teils frappierenden negativen Auswirkungen auf das Business.

Nach den aktuellen Erfahrungen nimmt die notwendige durchzuführende Änderung oder Umstellung einer Code-Zeile für einen Code-Experten/ SAP-Entwickler in etwa zehn Minuten in Anspruch.

Wie viele Code-Zeilen-Änderungen im Rahmen einer Conversion/Migration durchzuführen sind, hängt natürlich vom Einzelfall ab.

Es können 20, 200 oder auch 20.000 Änderungen sein. In aller Regel handelt es sich um Massenänderungsarbeiten. Was logischerweise einen entsprechenden Ressourceneinsatz, Zeit und Kosten erfordert.

Bei größeren Änderungsarbeiten treten Code-Factories oder Off-Shore-Programmiereinheiten in Aktion.

Bei derlei Änderungsarbeiten macht natürlich Automatisierung mittels Software Sinn. Und zwar nicht nur, um den zeitlichen Aufwand oder die Kosten zu minimieren, sondern auch, um eine gleichbleibend hohe Qualität sowie eine entsprechende Prozesssicherheit zu gewährleisten.

Automatisierung

Da­rüber hinaus können mittels Automatisierung Optimierungen realisiert werden.

Idealerweise stellt ein derartiges Conversion-Tool eine entsprechende Analysefunktionalität zur Verfügung, mit der Aufwände/Meilensteine exakt abgeschätzt werden können.

Gleichfalls muss es in der Lage sein, mit den von SAP bereitgestellten Werkzeugen wie etwa Code Inspector oder SQL-Monitor zusammenzuarbeiten und diese zu ergänzen beziehungsweise zu erweitern.

Mit dem Code Inspector beispielsweise ist es möglich, SAP-Repository-Objekte zu prüfen. Und zwar nach verschiedenen Kriterien. So etwa hinsichtlich Performance, Syntax, Security oder der Einhaltung von Namenskonventionen.

Ebenso lässt das Werkzeug die Suche nach Abap-Worten (sogenannte Tokens) zu. Anschließend stellt der Code Inspector Fehlermeldungen oder Warnhinweise zur Verfügung oder listet diese auf.

Es ist ein generisches Tool, das sich recht einfach den spezifischen Begebenheiten anpassen lässt.

Auch sollte ein Conversion-Tool auf einer Art Metamodell basieren, das es möglich macht, lückenlos jede Zeile Code zu finden, zu lesen, zu untersuchen und den Code entsprechend den Erfordernissen automatisch zu ändern. Sodass sich am Ende des Tages ein Error-Free-Code für die On-Hana-Nutzung verwenden lässt.

Nach den Erfahrungen bei internationalen Konzernen sowie bei mittelständischen Firmen ist es durch den Einsatz des ausgefeilten und sehr leistungsfähigen Tools for SAP Custom-Code möglich, selbst große On-Hana-Conversions in einem Zeitraum von einer bis maximal zwei Wochen zu realisieren – und zwar inklusive technischer Integrationstests und bereit zur Abnahme durch Endbenutzer.

Enduser testen die Funktionalität nach einer Conver­sion in aller Regel nicht vollumfänglich. Die Praxis zeigt, dass sich hierbei Kunden auf die Kerngeschäftsprozesse konzentrieren.

Wenn es Fehlerraten gibt, dann liegen diese im Promillebereich. Zeigen sich systematische Fehler, werden diese im Metamodell berücksichtigt.

Betroffene Code-Zeilen lassen sich anschließend durch die Automatisierung schnell abermals generieren und die Fehlerbeseitigung ist erfolgt.

Darüber hinaus stellt das Werkzeug Features zur Verfügung, mit denen ein Code optimiert werden kann. Und zwar bis hin zur Analyse, ob sich ein Custom-Code in den SAP-Standard überführen lässt oder, wie bereits ausgeführt, ob ein vorhandener Code minimiert oder (vom Applikation- in den DB-Layer) verlagert werden kann, um ein Hana-System in puncto Performance zu verbessern.

Nach den Erfahrungen schlummert in SAP-Systemen Code, der nicht genutzt wird und der – nach Prüfung – eliminiert werden kann. Dieser existierende ungenutzte Code kann demnach am gesamten existierenden Code in einem System bis zu 60 Prozent ausmachen.

Dieser Umstand lässt sich als „technische Schuld“ bezeichnen. Diese technische Schuld hat sich meist durch eine ineffiziente Entwicklung respektive Custom-Code-Erzeugung bei zahlreichen SAP-Kunden über die Zeit hinweg aufgebaut und steigt nach wie vor.

Im Zuge einer On-Hana-Conversion tut man gut daran, diese konsequent abzubauen.