SAP-Zertifizierungstipps, die man beachten sollte und Tricks, die man vermeiden sollte
Vor kurzer Zeit haben wir wieder den jährlichen SAP-Zertifizierungsprozess unserer Xiting-Softwarelösungen abgeschlossen. Dies beinhaltet natürlich einen gewissen Aufwand und auch Nutzen, aber ich habe wieder gemerkt, dass die Vermeidung von riesigen Aufwänden oder „Show Stoppern“ und auch die Maximierung des Nutzens lange vor dem Zertifizierungsprozess beginnt. Das betrifft vor allem den Code von Drittanbietern, der weder Kundencode noch SAP-Code ist und so oft ungeprüft in Kundensysteme gelangt.
Ich möchte einige Punkte teilen, die geprüft werden sollten, wenn der Einsatz von (nicht-zertifizierbaren) Softwarelösungen überlegt wird. Idealerweise sollten nur zertifizierte Lösungen in Betracht kommen, dann können viele dieser Probleme nicht in Ihren SAP-Systemen auftreten.
Auf- und Abwärtskompatibilität
Für Xiting’s aktuelle SAP S/4HANA-Zertifizierung muss die Software auf SAP_BASIS Release 7.56, HANA 2021 zertifiziert werden. Viele Kunden sind jedoch noch auf SAP_BASIS Release 7.31 oder älter, das bereits vor 10 Jahren veröffentlicht wurde und einen wichtigen Meilenstein für das ALV-Entwicklungs-Framework darstellt. Auf welchem Release entwickelt wird und wie eine Auf- und Abwärtskompatibilität getestet werden kann, stellt eine große Herausforderung dar. Aufwärtskompatibilität ist wichtig für Verkäufe an neue Kunden. Abwärtskompatibilität ist genauso wichtig für wiederkehrende Einnahmen aus der Softwarepflege und -Wartung. Darum muss die Software auf- und abwärtskompatibel entwickelt und getestet werden.
Tipp: Zusätzlich zu der Frage nach einer SAP-Zertifizierung können Sie Hersteller nach ihren Testkonzepten und Kompatibilitäten fragen, bevor Sie die Software evaluieren, da diese Dinge oft „Show Stopper“ für die Planung Ihres Software-Lebenszyklus sein können.
Verwendung von undokumentierten Objekten und Komponenten-Neutralität
Das Verwenden von Dictionary-Objekten mit schönen Namen im Entwicklungssystem kann ein Minenfeld an nachfolgenden Problemen auf fremden Systemen mit anderen Komponentenversionen bedeuten. Diese Probleme können so gravierend sein, dass eine erneute Installation der Software nicht möglich ist, ohne dass vorher alles gelöscht werden muss. Der Grund dafür ist, dass undokumentierte Funktionen und nicht-existierende Objekte jederzeit geändert oder gelöscht werden können und dadurch unterschiedliche Nachfolge-Effekte (je nach Release und Häufigkeit der Importversuche) nach sich ziehen können.
Tipp: Ein Komponenten-neutraler Transport sollte maximal Warnungen über Nametabs und Importsequenzen, die auf andere Schritte warten, anzeigen. Keine Fehler.
Direkte Änderungen an SAP-Tabellen
Dies ist nichts, was ein Entwickler freiwillig tun würde, außer der Verkaufsdruck eine Funktion bereitzustellen ist größer als die Vernunft, freigegebene APIs zum Datenmodell nicht zu übergehen. Oder der Entwickler beachtet das Datenmodell eines fremden Pakets und potenzielle Änderungen daran tatsächlich nicht. In beiden Fällen ist dies ein schwerwiegendes Symptom des Produktmanagements der Lösung und der Entwicklungs-Koordination. Wenn Sie eine solche direkte Änderung finden, finden Sie wahrscheinlich auch mehr und womöglich auch Backdoors, um diese vor Code-Reviews zu verschleiern.
Tipp: Verwenden Sie den SAP SCI CVA Code-Scanner, um SQL-Injections aus fremden Paketen zu identifizieren. Ohne grünes Licht aus dem CVA, kann die Lösung nicht zertifiziert werden und deshalb auch nicht in SAP-gehosteten Systemen installiert werden. Wenn diese Programme Fehler oder korrupte Daten hervorrufen, wird Ihnen SAP nicht helfen diese Fehler zu beheben. Eine schnelle Prüfung kann mit der Transaktion SE11 gemacht werden, wo die Verwendungsnachweise auf Tabellen wie USR02, AGR_1251, DEVACCESS, etc. geprüft werden.
HANA Readiness und CVA scans
Die HANA Readiness und CVA-Scans von Transaktion SCI sind sehr nützlich, um Probleme frühzeitig zu entdecken und sollten regelmäßig ausgeführt werden, um einen Rückstau und große Arbeitslisten zu vermeiden, um diese Probleme zu korrigieren. Je mehr Kunden die Lösung verwenden und je länger der Rückstau wird, desto mehr Störungen wird dies für die Software-Entwicklung und den Software-Lebenszyklus verursachen. Das bedeutet, es werden mehr Korrekturen benötigt mit zunehmenden Abhängigkeiten, die an einem gewissen Punkt nur noch durch Support Packages oder Release-Upgrades behoben werden können.
Tipp: Unterscheiden Sie zwischen Fehlerkorrekturen und Funktions-Anforderungen und der Release-Kompatibilität verglichen mit der Priorität. Wenn Sie HANA Readiness- und CVA-Anpassungen von Beginn an berücksichtigen, können Fehlerkorrekturen und auch Funktions-Anforderungen oft noch am gleichen Tag durch den Lieferanten ausgeliefert werden.
Verwendung von Scripting Tools, Bildschirmaufnahmen und e-CATTs
Falls APIs fehlen oder nicht verwendet werden, wird die Versuchung größer, verschiedene Formen von Scripting für UI-Objekte zu verwenden. Dies ist eine Falle, da SAP UIs regelmäßig ändern oder ersetzen wird und im Falle von vielen Anwendungen es unmöglich ist, alle Dialognachrichten auszuarbeiten. Zum Beispiel hat das PFCG-Paket sechs Nachrichtenklassen, mehr als 1000 Nachrichten und noch mehr dynamische Dialoge und Suchhilfen für die Felder von 4000 Objekten. Ein Release-unabhängiges Script für alle Konstellationen und möglichen Fehler zu erstellen, wird so nahezu unmöglich und fehleranfällig in der Pflege.
Tipp: Ab SAP-Release 7.50 werden API-Methoden für die Geschäftsfunktionen der PFCG bereitgestellt, also gibt es kein valides Argument mehr, das für Scripting Tools spricht.
Keine Vorlage-Rollen oder SU24-Berechtigungsvorschläge
Dies erscheint zunächst unkritisch, selbst wenn der Lieferant SAP_ALL für Benutzer (auch technische für Jobs oder RFC-Aufrufe und Webservices) der Anwendung empfiehlt. Zumindest werden sie keine Probleme mit Berechtigungen haben. Allerdings wird es Ihr Problem sein, dass Sie keine Ahnung davon oder Kontrolle darüber haben, welche Funktionen die Anwendung aufruft und es auch keine Dokumentation via Verwendungsnachweis für die Berechtigungen gibt, die beschreiben, was die Anwendungen überhaupt machen. Der Lieferant kann Ihnen also erzählen, was die Anwendung leisten kann und welche Funktionen sie hat, aber unter welchen Umständen diese funktionieren und was sie wirklich machen, kann nur durch eine Evaluierung des Quellcodes durch Sie herausgefunden werden.
Tipp: Bestehen Sie auf Vorlagerollen und idealerweise SU24-Berechtigungsvorschlägen, um Verwendungsnachweise verfolgen zu können.
Versuche Lizenzroutinen und kritische Statements zu verstecken
Jeder Softwarelieferant wird versuchen, sich in irgendeiner Form vor Kopien zu schützen. Vor allem davor, von einem Konkurrenten kopiert zu werden. Dafür gibt es Möglichkeiten für clever designte Lizenzschlüssel, aber leider auch die Versuchung den Code zu verstecken oder dynamisch während der Laufzeit zu generieren. Versuche, den Code zu verstecken unter Verwendung des obsoleten ABAP-Statements „*@#@@[SAP]“ funktionieren in höheren Releases nicht mehr, aber ihre Anwesenheit ist ein böses Omen. Alternativ können auch die ABAP-Statements GENERATE SUBROUTINE oder INSERT REPORT gefunden werden, die Codes zur Laufzeit aus (externen) Quellen erstellen.
Mit dem folgenden einfachen, aber leistungsfähigen Programm können Sie solche Programme finden:
REPORT z_scan_for_hidden_includes.
INITIALIZATION.
DATA: source(255) OCCURS 0,
prog like trdir-name.
SELECT name FROM trdir INTO prog.
READ REPORT prog INTO source.
IF sy-subrc NE 0.
WRITE:/ ‚If sy-subrc = 8 then new kernel hardcoding method is like SAPMSYST.‘.
WRITE:/ ‚If sy-subrc = 4 then the old # keyword is still in use.‘.
WRITE:/ sy-subrc,prog.
ENDIF.
ENDSELECT.
