Fehler bei der Verarbeitung von Transporten haben irgendwann jeden, der in SAP-Änderungen involviert ist, Nerven gekostet und unter Umständen sogar zu einer Produktionsunterbrechung geführt. In der gesamten Branche hört man stets dieselben Geschichten: Nachdem alle Aspekte der neuen Version getestet wurden und von einer erfolgreichen Überführung in die Produktion ausgegangen wurde, wird diese gestaffelt durchgeführt. Die Transporte importieren die Änderungen in die Produktion – und dann tritt der Worst Case ein. Die Diagnose zeigt, dass das Problem nicht funktions-, sondern transportbedingt war: Die Transporte wurden in der falschen Reihenfolge importiert, ein Transport ist unter den Tisch gefallen oder hat ein Objekt auf eine frühere Version zurückgesetzt, wodurch es zu einer Regression kam. Das kommt Ihnen bekannt vor?
Eigentlich sollten diese Probleme doch bei den Tests gefunden werden? Leider eignen sich Funktionstests schlecht dafür, diese Art von Defekt zu finden. Es ist schlichtweg das falsche Tool für den Job. Warum arbeiten wir dann mit Funktionstests, um diese Art von Problemen zu verhindern?
Im Allgemeinen greifen SAP-Teams auf Funktionstests zurück, um zwei verschiedene Arten von Fehlern zu ermitteln: Funktionsdefekte, deren Ursache Programmier- oder Logikfehler im Code sind und technische Release-Defekte, die häufig auf ein Transportproblem zurückzuführen sind. Funktionsdefekte haben falsches Verhalten oder ein falsches Ergebnis zur Folge; am besten lässt sich dies mittels Funktionstests erkennen. Ein technischer Release-Defekt ist häufig die Folge eines Fehlers bei der Transportverarbeitung sowie der Architektur von SAP selbst. Dazu gehören häufig auftretende Fehler wie falsche Importreihenfolgen, Überholvorgänge, Überschreibungen und fehlende Transporte sowie Dutzende weiterer Fehler, die im Zusammenhang mit der Verarbeitung einzelner Transporte im Release-Plan auftreten.
Wenn Funktionstests und die manuelle Nachverfolgung gut funktionieren würden, um technische Release-Defekte und Probleme bei der Transportverarbeitung in SAP zu ermitteln, könnten Unternehmen diese Probleme erkennen und verhindern. Kein Release Manager hätte dann die beneidenswerte Aufgabe (hüstel, hüstel), Excel-Tabellen von Transporten und Objekten nachzuverfolgen, um Fehler zu verhindern. Technische Release-Defekte treten in SAP-Umgebungen jedoch nach wie vor häufig auf und machen oft einen großen Teil der Ausfallereignisse aus. Weder das Testen noch die manuelle Nachverfolgung funktionieren so perfekt wie gewünscht, denn beide Verfahren sind zeitaufwändig und von Natur aus Aufgaben ohne Mehrwert: Schließlich ist das beste Ergebnis, dass nichts gefunden wird oder passiert. Wenn das der Fall ist, haben wir nur unnütz Zeit darin investiert, mögliche Probleme zu finden.
Von außerhalb von SAP kann man an dieser Stelle etwas lernen: das DevOps-Konzept der kontinuierlichen Integration. In Sprachen wie C# oder Java hat sich der Build- und Bereitstellungsprozess mit Automatisierung, Nachverfolgung von Code in einem Versionskontrollsystem, Erstellen neuer ausführbarer Dateien mit skriptbasierten, konsistenten Prozessen, automatischem Testen von Codeänderungen auf Übereinstimmung mit technischen Verträgen usw. bewährt. Die Möglichkeiten einer guten Pipeline für die kontinuierliche Integration bzw. kontinuierliche Auslieferung würden den Rahmen dieses Artikels sprengen. Es ist aber möglich, dies auch in SAP zu realisieren. Und das sollten wir auch tun.
Der Schwerpunkt bei der kontinuierlichen Integration in SAP liegt auf der Automatisierung der Transportverarbeitung und der Änderungskontrolle. Grundsätzlich sollte die Automatisierung das Erkennen von Überholvorgängen, Überschreibungen, Zurücksetzen auf ältere Versionen, erforderlichen manuellen (nicht transportierbaren) Änderungen, der Importreihenfolge, von Abhängigkeiten (fehlende Transporte und Objekte) sowie das Überprüfen auf sensible Objektänderungen und je nach Umgebung u. U. weitere Änderungen umfassen. Ein ausgefeilterer Ansatz der kontinuierlichen Integration würde die Retrofit- und Konflikterkennung in N + 1/n-Umgebungen automatisieren, Code Inspector und ABAP Unit Test integrieren und die Erstellung, Freigabe und Nachverfolgung der Transporte von Kopien automatisieren.
Ein aussagekräftiger Indikator dafür, wie gut dies funktioniert, ist unsere Backout-Funktionalität: Vor Jahren haben wir eine Transport-Backout-Technologie entwickelt, um die Nachfrage unserer Kunden nach einer Lösung zur Bewältigung von Unfällen bei der Transportverarbeitung zu befriedigen und die damit einhergehenden Ausfallzeiten zu reduzieren. Bei Kunden, die eine Lizenz für unsere ActiveControl-Technologie erwerben, spielt diese Funktion bei der Evaluierung der geschäftlichen Auswirkungen von Investitionen in unsere Technologie häufig eine wichtige Rolle. Die meisten Kunden berichten allerdings, dass die Funktion nur selten genutzt wird. Warum? Weil die Implementierung guter Praktiken für die kontinuierliche Integration, die Inline-Analyse und die frühzeitige Erkennung von Transportproblemen einen solchen Sicherheitsschalter überflüssig machen.
Welche Auswirkungen hätte die Beseitigung technischer Release-Fehler und deren Erkennung mittels Funktionstests für Ihr Unternehmen? Würden sie einen schwerwiegenden Ausfall (oder zwei!) pro Jahr verhindern? Würden sie es Ihnen ermöglichen, Ihr Unternehmen besser zu unterstützen – mit häufigeren Änderungslieferungen und größerer Zuverlässigkeit –, weil volles Vertrauen in die Release-Qualität besteht? Hätte ein Release-Manager, der dies manuell nachverfolgt, dann die Möglichkeit, sich wertschöpfenderen Aktivitäten zuzuwenden? Was wären die wirtschaftlichen und Wettbewerbsvorteile dieser Änderungen Ihrem Unternehmen wert?
Wenn die Notwendigkeit entfiele, Tests auf normale Probleme bei der Transportverarbeitung durchführen zu müssen, um Ausfälle und Fehler zu reduzieren, und die Einführung von DevOps-Methoden und Automatisierung in Ihrer SAP-Umgebung verheißungsvoll klingt, sollten Sie sich ActiveControl von Basis Technologies anschauen. ActiveControl wurde speziell für SAP entwickelt – und zwar genau zur Lösung dieser Herausforderungen für ECC, S/4HANA und viele SAP-Anwendungstechnologien.
