BTP - Central ATC
Wie kannst du das ABAP Test Cockpit in der BTP konfigurieren? Welche Stolpersteine gibt es und was kannst du am Ende damit tun? Mehr in diesem Artikel.
Inhaltsverzeichnis
In diesem Artikel werden wir uns die verschiedenen Punkte des ABAP Test Cockpits in der BTP anschauen und wie du es sinnvoll bei dir in der Organisation einsetzen kannst. Ebenso werden wir einige aktuelle Erfahrungen aus der Konfiguration und Nutzung mitgeben.
Einleitung
Das ABAP Test Cockpit, kurz ATC, basiert auf dem alten Code Inspector und ist eine Weiterentwicklung des Tools zur statischen Code Analyse im System. Der Vorteil des ATC liegt im modularen Aufbau der Prüfung und Varianten. So können beispielsweise zusätzliche Prüfungen im System installiert und so das ATC erweitert werden. Im Bereich Open Source gibt es ein paar Projekte. Das ABAP Test Cockpit kann auch so konfiguriert werden, dass Transporte oder Aufgaben nicht freigegeben werden können, wenn nicht der richtige Status bei den Prüfungen erreicht wurde. So kann ein Grundzustand an Qualität im System, ohne viel Aufwand, erzeugt werden.
Aktuell gibt es die folgenden Szenarien, für unterschiedliche Einsatzzwecke des ATCs:
- Custom Code Migration - In diesem Szenario wollen wir ein Entwicklungssystem mit einer spezifischen Variante oder einem Szenario prüfen. Dazu steht uns die "Custom Code Migration" App zur Verfügung, über die wir einen Prüflauf ausführen können.
- Developer Scenario - In diesem Szenario ruft das Entwicklungssystem die BTP auf und initiiert den Prüflauf im System. Dies kann manuell über die ABAP Development Tools oder die SE80 passieren oder automatisch bei der Freigabe eines Transports oder einer Aufgabe im System.
Hinweis: Aktuell kann kein ABAP Environment an das Central ATC angeschlossen werden, hier sind nur lokale Prüfungen und Genehmigungen möglich. In einem späteren Release soll das möglich sein.
SAP Blogs
Von SAP Seite schreibt Olga Dolinskaja sehr gute Blogs zur Einrichtung und Nutzung des ABAP Test Cockpits in der Cloud. Unter den folgenden Blogs findest du weitere Informationen:
- Configure ATC in Cloud
- ATC for On-Premise
- Use ATC as On-Premise Developer
- Exemption process
- Schedule ATC runs
- How to use baselines
Vorbereitung
Bevor wir mit der Konfiguration des Systems beginnen können, solltest du sicherstellen, dass die folgenden Hinweise im System eingespielt wurden:
- 2599695 - Migration von Eigenentwicklungen: SAP-Fiori-App: Remote-Stubs für das geprüfte System
- 3333009 - RFC-Stub für CVA/SLIN-Remote-Prüfungen
- 3358660 - Entwicklerszenario Cloud
- 2270689 - Remote-Analyse (für Quellsystem)
- 3053248 - Approver werden nicht angezeigt
- 3422320 - Dumps im Central ATC
Beim Hinweis 2270689 handelt es sich um einen Sammelhinweis, hier musst du den für dein System-Release passenden Hinweis heraussuchen. Die Hinweise müssen pro Entwicklungssystem eingespielt werden, dass du an die BTP anschließen möchtest.
Verbindung
Nachdem wir die On-Premise Entwicklungssysteme vorbereitet haben, müssen wir entsprechende Verbindungen einrichten. Einmal brauchen wir eine Verbindung von On-Premise zur BTP, von der BTP nach On-Premise und Freigaben im Cloud Connector.
ABAP Environment
Im ABAP Environment müssen wir zwei Szenarien implementieren, um eine Verbindung herzustellen. Zum einen benötigen wir die Verbindung Richtung On-Premise, um das Custom Code Migration Szenario zu bedienen, zum anderen einen technischen User und die Verbindung ins System, für die Entwicklung. Im ersten Schritt würden wir das Communication Arrangement für SAP_COM_0464 anlegen:
Hier kannst du bereits die System-ID mit übernehmen, da wir viele dieser Verbindungen brauchen. In diesem Beispiel verwenden wir die ID eines CAL Systems. Unter den zusätzlichen Eigenschaften pflegen wir den Objekt Provider, unsere Empfehlung ist die Hinterlegung der SID, damit das System zugeordnet werden kann. Die Systemgruppe kannst du einheitlich für alle Entwicklungssysteme einer Landschaft vergeben.
Für die weitere Konfiguration musst du ein Communication System hinterlegen, welches auf das Entwicklungssystem zeigt und dort den technischen User eintragen, den du On-Premise im nächsten Abschnitt angelegt hast. Als letzten Schritt müssen wir die Inbound Verbindung im System anlegen, dazu benötigen wir das Communication Scenario SAP_COM_0936:
In den zusätzlichen Attributen hinterlegst du dann den Objekt Provider aus dem vorherigen Schritt. Dies ist wichtig für die Back-Connection beim Prüfprozess. Wenn der Prozess On-Premise gestartet wird, muss das System auch eine Verbindung Richtung On-Premise aufbauen, um Daten nachlesen zu können.
In den weiteren Schritten richten wir ein Inbound Scenario ein und legen einen technischen User an, den wir dann On Premise in der RFC Verbindung eintragen, um eine Verbindung herzustellen. Der "User Name" ist dann relevant für die Konfiguration On-Premise:
Weitere Details zur Konfiguration einer Outbound und Inbound Verbindung findest du in diesem Artikel.
On-Premise
Im On-Premise System müssen wir eine RFC Verbindung einrichten und einen technischen User, der für die Zugriff aus der BTP verwendet wird. Legen wir im ersten Schritt die RFC Verbindung in der Transaktion SM59 an. Dazu legen wir eine Verbindung vom Typ "3" (ABAP Connection) an. Als Ziel verwenden wir die Cloud Connector Instanz deines Unternehmens.
Als User und Passwort hinterlegen wir den angelegten User auf dem ABAP Environment. In diesem Fall aber nicht den technischen CC*-User, sondern den vergebenen Usernamen. Da das Feld nicht allzu lang ist, sollte der Name nicht zu lang sein.
In diesem Fall verwenden wir SNC, um die Kommunikation zum Cloud Connector aufzubauen. Über den Button findest du die entsprechenden Einstellungen im System.
Im letzten Schritt aktivieren wir die schnelle Serialisierung für die RFC-Verbindung. Weitere Informationen findest du im unteren Bereich.
Haben wir die RFC Verbindung angelegt, müssen wir noch einen technischen User im System anlegen. Diesen kannst du frei benennen, er sollte aber vom Typ "B" (System) sein. Die Berechtigungen für den User findest du in der technischen Dokumentation, damit solltest du dem technischen User eine Rolle erstellen.
Cloud Connector
Im Cloud Connector müssen wir drei Dinge konfigurieren. Im ersten Schritt benötigen wir einen Service Channel von On-Premise Richtung ABAP Environment, der den Traffic weiterroutet. In der RFC Verbindung haben wir dazu den Cloud Connector als Ziel eingetragen.
Als zweiten Punkt müssen wir das Mapping des virtuellen Hosts auf unser On-Premise System durchführen. Hier benötigen wir pro System ein Mapping.
Als letzte Konfiguration müssen wird dann noch die RFC Ressourcen für die BTP freigeben, dass passiert pro virtuellem System. Die Ressourcen können aber per Download und Upload im System zur Verfügung gestellt werden. Die Liste der nötigen Berechtigungen und Freigaben für den Import findest du in Hinweis 2861842.
Zusammenfassung
Hier noch einmal eine kurze Zusammenfassung der verschiedenen Verbindungen und Schritte:
- BTP - Definition Outbound und Inbound Verbindung, Anlage Kommunikations-User
- On-Premise - RFC Verbindung, technischer User
- Cloud Connector - Freigabe der Ressourcen für On-Premise, Routing Richtung ABAP Environment (Central ATC)
Konfiguration
Nachdem wir nun die Verbindungen und Zugänge konfiguriert haben, geht es nun um die Einrichtung des Developer Szenarios. Dafür müssen wir auf beiden Systemen Konfigurationen vornehmen.
ABAP Environment
Zuerst einmal müssen wir eine Prüfvariante anlegen, wenn wir eine eigene Konfiguration verwenden wollen. Dazu würden wir auf dem Entwicklungssystem eine "ATC Check Variant" anlegen und können diese frei konfigurieren. Dies müssten wir dann ins Central ATC System transportieren.
On-Premise
On-Premise müssen wir über die Transaktion SCI die Variante konfigurieren und über die Transaktion ATC dann die Grundkonfiguration vornehmen. Dazu rufen wir die Transaktion SCI auf und navigieren über das Menü "More -> Code Inspector -> Management of -> Reference Check System" um die angelegte RFC Verbindung zu hinterlegen.
Im nächsten Schritt legen wir eine globale Prüfvariante in der Transaktion an. Am einfachsten bekommt diese Variante den gleichen Namen wie im ABAP Environment. Im Bereich "Im Referenzprüfsystem" kannst du dann die Variante hinterlegen.
Beim Speichern erfolgt auch eine Prüfung, ob die Variante im Central ATC existiert. Als letzten Schritt würden wir dann in der Transaktion ATC die Grundkonfiguration abschließen. Dort kannst du einstellen, wann das ATC ausgeführt wird und was die Fehler dann für Auswirkungen auf die Transport- und Aufgabenfreigabe haben. Hier einmal die Einstellungen aus einem S/4HANA 2023 System. Je nach Release sehen die Oberflächen unterschiedlich aus.
Zusammenfassung
Was haben wir nun eigentlich konfiguriert? Hier noch einmal eine kurze Zusammenfassung:
- BTP - Anlage der Prüfvariante
- On-Premise - Anlage der Remote-Variante, Konfiguration des ATC
Verwendung
Die Verwendung On-Premise sollte dir nun soweit bekannt sein, du kannst so weit alle Standardszenarien des ATC nutzen. In der BTP stehen dir nun verschiedene Anwendungen zur Verfügung:
- "ABAP Test Cockpit Configurator" (F4712) - Über die App kannst du eine Standardvariante definieren und für Prüfmeldungen die Klassifizierung anpassen. Damit kannst du Meldungen höher oder tiefer einstellen oder sogar komplett ausblenden, wenn dich bestimmte Meldungen in einer Prüfung nicht interessieren.
- "Custom Code Migration" (F3191) - Die App dient zum Einplanen von verschiedenen Prüfläufen, rund um das Thema Code-Analyse im Remote System. So stehen dir Varianten für eine BTP oder S/4HANA Migration zur Verfügung oder der klassische Prüflauf mit eigenen Varianten.
- "Approve ATC Exemptions" (F7472) - Über die Anwendung kannst du Anträge zu Meldungen aus dem On-Premise System bearbeiten. Die Anträge stellt der Entwickler über die ABAP Development Tools.
- "Schedule Custom Code Analysis" - Hierbei handelt es sich um eine Variante der App "Application Jobs" mit dem Filter auf Prüfläufe. Damit kannst du Prüfläufe im System einplanen und durchführen lassen.
Stolpersteine
Die folgenden Stolpersteine und Fehler sind uns bei der Implementierung über den Weg gelaufen. Wenn du die Punkte beachtet hast, solltest du weniger Probleme bei der Einführung des Central ATCs haben:
Dumps nach Hinweiseinspielung
Bei uns kam es nach der Ausführung des Reports RS_ABAP_SETUP_ANALYSIS (2270689) zu Dumps im System vom Typ "LOAD_PROGRAM_CLASS_MISMATCH". Der Fehler trat auf, wenn Ressourcen im System aktiviert werden. Hier hilft es die im Dump genannten Klassen noch einmal zu generieren.
User Name für RFC-Verbindung
Wichtig bei der Anlage On-Premise Verbindung ist die Eintragung des korrekten Users in die Authentifizierungsdetails. Wählst du den Namen des Users zu lang, passt er nicht in das Feld und du kommst vielleicht auf die Idee, die technische ID (CC*) zu verwenden.
Ziel Cloud Connector
Das Ziel der RFC Verbindung ist der Cloud Connector, der dann den Traffic weiter zum ABAP Environment leitet. Die Konfiguration des ABAP Environments direkt, hatte nicht funktioniert und funktioniert wohl nur auf neuen Systemen über Websocket-Verbindung.
Fehlender Genehmiger
Bleibt bei der Beantragung des Genehmigers im ADT der Genehmiger leer oder kommt eine Fehlermeldung, dann muss wahrscheinlich Hinweis 3053248 eingespielt werden. Beim Abruf der Genehmiger aus der BTP fehlt dann das Mapping der Gruppe.
Dumps im Central ATC
Erhältst du im Zentralsystems einige Dumps, die auf den Funktionsbaustein SADT_REST_RFC_ENDPOINT hinweisen, fehlt wahrscheinlich der Hinweis 3422320. Der Funktionsbaustein sollte während der Prüfung nicht aufgerufen werden.
TIMEOUT bei Prüfungen
Bei bestimmten Objekten dauern die Prüfungen sehr lang, obwohl kaum Coding im Objekt ist? Ebenso kann der Fehler bei WebDynpros und großen Programmen passieren. Die Prüfung dauert im ADT und der SAP GUI sehr lange und läuft nach knapp einer Stunde in einen TIMEOUT. In diesem Fall können Prüfungen in der Variante enthalten sein, die den Fehler verursachen, hier hilft es die Variante zu prüfen.
TIMEOUT im ADT
Die Prüfung in der SAP GUI läuft in wenigen Sekunden zu Ende, aber in den ABAP Development Tools läuft es sehr langsam und führt zu einem TIMEOUT. In diesem Fall hilft ein Blick in die Einstellung der RFC Verbindung. Wenn die "schnelle Serialisierung" aktiviert ist, sollte das Problem behoben sein.
Berechtigungen und Freigaben
Es kann hin und wieder vorkommen, dass nicht alle Objekte im Cloud Connector freigegeben sind oder der On-Premise User alle Berechtigungen hat. Hier lohnt sich ein Blick in die Logs des Cloud Connector und in die ST22/Feed Reader. Je nach verwendeter Prüfung, werden auch unterschiedliche Berechtigungen benötigt, hier solltest du alle Szenarien einmal genauer testen.
Einschätzung
In diesem Abschnitt wollen wir einmal auf den Nutzen und die Verwendung eingehen. Wieso setzen wir auf das Central ATC im ABAP Environment?
- Viele Entwicklungssysteme - Wenn du viele Entwicklungssysteme hast, musst du immer sicherstellen, dass das Zentrale ATC auf dem aktuellsten Stand aller Systeme ist. Bei vielen Systemen kann es schnell einmal passieren, dass ein System eher aktualisiert wird, dann funktionieren die Tests auf dem System nicht mehr.
- Wartungszeit - Der Upgrade Prozess auf dem ABAP Environment ist sehr schnell und es entstehen keine manuellen Aufwände auf deiner Seite. Testen solltest du nach dem Release allerdings schon die Hauptfunktionen.
- Kosten - Im ersten Schritt scheinen die Kosten mit ca. 2200 EUR pro Monat teuer zu sein, du erhältst allerdings auch das CVA Modul kostenlos dazu. On-Premise kostet das Modul aktuell viel Geld oder du setzt auf einen Drittanbieter, die auch entsprechend kosten.
- ADT - Die Beantragung von Ausnahmen funktioniert damit nur noch über die ABAP Development Tools. Wir fassen diesen Punkt als positiv auf, da die ADTs bereits die Standardtools zur Entwicklung sind und auch die letzten ABAP Entwickler das verstehen sollten.
Dazu aber auch einige Punkte, die du für dich selbst einschätzen solltest, wie wichtig sie dir sind.
- Features - Aktuell funktionieren nicht alle Features wie On-Premise. Zeitlich begrenzte Freigaben gibt es noch nicht, dass 4-Augen-Prinzip kann aktuell nur Organisatorisch sichergestellt werden und es können noch keine Freigabeteams pro Systemlandschaft erstellt werden. Ebenso fehlt die Möglichkeit die Objekte in der Prüfmenge dynamisch einzustellen oder auszusteuern.
- Upgrade - Aktuell hatten wir noch nicht den Fall, es kann aber sein, dass nach einem BTP Release auch alle On-Premise Systeme den aktuellen Stub benötigen. Je nach Größe der Landschaft, müssen überall neue Hinweise eingespielt werden.
Fazit
Das ABAP Test Cockpit in der Cloud kann dir den Upgradestress On-Premise nehmen und stellt einen Mehrwert in Form von CVA Prüfungen zur Verfügung, die On-Premise einiges mehr kosten würden. Gleichzeitig erhältst du immer die aktuellen Prüfungen in der BTP, auch für deine älteren Systeme.
