Qualitätssicherung von ABAP-Coding: SCI & ATC

Um die Qualität von kundeneignen ABAP-Entwicklungen zu sichern, gibt es viele verschiedene Wege.

  • ABAP Test Cockpit (ATC)
  • ABAP Unit Tests
  • Github-Code-Reviews
  • uvm.

In dieser kleinen Blogreihe werden wir uns 3 Möglichkeiten im Detail anschauen und dabei feststellen, dass die einzelnen Werkzeuge sehr gut ineinandergreifen können, um die Qualität von Kundenentwicklungen zu steigern.

Anfangen möchte ich hier mit dem ABAP Test Cockpit (kurz ATC), welches die Prüfungen des SAP Code Inspectors (kurz SCI) beinhaltet und noch weitere Werkzeuge darum herum anbietet.

1.      Einführung in den SAP Code Inspector (Transaktion SCI)

Der SAP Code Inspector bietet statische Codeanalysen und Prüfungen, welche von der SAP empfohlen werden und zugleich die Qualität der Programme erhöhen. Außerdem lassen sich die Programmierrichtlinien eines Unternehmens, z. B. Namenskonventionen, darstellen.

1.1  Prüfvarianten

Das zentrale Element der statischen Code-Analyse mit dem Code Inspector oder dem ABAP Test Cockpit sind die Prüfvarianten. Diese steuern, auf welche Kriterien eigenes ABAP-Coding überprüft werden soll.

Die Prüfungen des Code Inspectors sind in verschiedene Kategorien unterteilt:

Prüfungskategorien
Prüfungskategorien

Um zu sehen, welche Prüfung wie genau funktioniert, kann man durch einen Klick auf den Dokumentationsbutton () die Dokumentation aufrufen. Einige Prüfungen bieten zusätzlich noch die Möglichkeit, Einstellungen vorzunehmen. Ein Beispiel hierzu sind unter der Kategorie Sicherheitsprüfungen die „Kritischen Anweisungen“:

Parameter für Kritische Anweisungen-Prüfung
Parameter für Kritische Anweisungen-Prüfung

Hier kann man einstellen, ob eine Prüfung eine Warnung bei den jeweiligen Statements bringen soll oder das Statement ignorieren soll.

1.2  Objektmenge

Damit man nicht immer jedes Objekt einzeln testen muss, kann man sich in der Transaktion SCI auch Objektmengen anlegen, welche geprüft werden sollen.

Ein Beispiel hierfür wäre, dass in einem Paket für ESS / MSS Entwicklungen alle Klassen mit „ZCL_XSS_“ beginnen sollen. Dafür stellt man eine Prüfvariante zusammen, welche dies abbildet, und eine Objektmenge, welche sich nur auf das Paket für die ESS / MSS Entwicklungen konzentriert.

Objektmenge-screenshot
Objektmenge-Screenshot

1.3 Inspektion

Nun werden die ersten beiden Komponenten, also die Prüfvarianten und die Objektmengen, zusammengeführt.

Jetzt kann der Entwickler oder ein Qualitätsbeauftragter die Objekte auf die einzelnen Aspekte prüfen. Dabei gibt dieser in die Objektauswahl entweder die zuvor erstelle Objektmenge, einen Transportauftrag oder ein einzelnes Objekt ein. Dann wählt man seine gewünschte Prüfvariante und lässt die Inspektion laufen.

Inspektion-Screenshot

Anschließend werden die Ergebnisse der Prüfungen in einer Liste angezeigt.

Die Inspektion selber ist nur Teil des Code Inspectors und nicht Teil des ABAP Test Cockpits.

1.4 Eigene Code Inspector Prüfungen

Manchmal reichen die SAP-Standard Prüfungen nicht aus, um die kompletten Softwareentwicklungsrichtlinien zu überprüfen. Für diesen Fall besteht die Möglichkeit, eigene SAP Code Inspector Prüfungen zu programmieren. Eine Anleitung dazu findet man hier: https://tricktresor.de/blog/series/code-inspector-erweitern/

Daneben ist es denkbar, Prüfungen aus dem Open-Source-Projekt ABAP Open Checks zu importieren und zu nutzen. Im Zuge dessen benötigt man das Tool ABAPGit, welches von der SAP unterstützt und auch in der ABAP-Cloud Umgebung eingesetzt wird.

2.     ABAP Test Cockpit (Transaktion ATC)

Das ABAP Test Cockpit fügt dem Code Inspector noch weitere Funktionen hinzu; am wichtigsten sind hierbei:

  • Regelmäßige Prüfläufe
  • Information an den Entwickler über fehlgeschlagene Prüfungen
  • Genehmigungsprozesse

Wenn man das ATC nun startet, wird folgender Startbildschirm sichtbar:

ATC Überblick
ATC-Überblick

ATC-Administration

Im Bereich „Setup“ werden allgemeine Einstellungen für die Qualitätskontrolle getroffen.

Der Punkt „ATC konfigurieren“ bietet generelle Einstellungsmöglichkeiten. Diese bestehen beispielsweise in einer allgemeinen Prüfvariante zur Durchführung von Prüfungen. Darüber hinaus kann man entscheiden, ob Befreiungen in einem zentralen oder lokalen System verwaltet werden und welches Verhalten bei Transportfreigabe stattfinden soll.

Um ein zentrales ABAP Test Cockpit aufzusetzen, empfehle ich die Blogreihe von Bärbel Winkler: Setting up a central ATC-System. Dort werden alle Aspekte aufgezeigt, die benötigt werden, um ein zentrales ATC-System aufzusetzen.

Der Knoten „Läufe“ ermöglicht es, regelmäßig und automatisiert einen Prüflauf einzuplanen. Dabei wird ein Job eingeplant, welcher eine bestimmte Prüfvariante über die zu prüfenden Objekte laufen lässt.

Prüflauf-Konfiguration

Um gezielt auf einzelne Entwicklungen, Projekte oder Module zu prüfen, werden die in Punkt 1.2 erwähnten Objektmengen verwendet. Beispielsweise ist es möglich, einen Lauf für ESS / MSS Entwicklungen, einen für klassische HCM-Entwicklungen und einen für FI-Entwicklungen einzuplanen – stets unter der Voraussetzung, dass es Sinn ergibt, die Läufe voneinander zu trennen.

Unter „Ergebnisse verwalten“ sieht man alle Ergebnisse der verschiedenen Läufe, was bei der Analyse von eventuellen Fehlern helfen kann.

Qualitäts-Governance

Falls man einen Genehmigungsprozess für ATC-Befunde verwenden möchte, kann man in der ATC-Administration die genehmigenden Personen pflegen.

Im Befreiungs-Browser sieht man alle Anträge auf Befreiung, die ein Entwickler nach einer ATC-Prüfung gestellt hat. Für den Fall, dass ein Antrag nicht genehmigt wird, wird der Transportauftrag blockiert, sodass man diesen nicht in ein nächstes System transportieren kann.

Im Befreiungsantrag kann man auch einen Kommentar hinterlegen, bei dem ein Entwickler begründen kann, weshalb die Richtlinien verletzt werden. Ein Beispiel hierfür wäre eine externe Entwicklung, welche eingekauft wurde; diese kann oder sollte man nicht verändern, daher wäre eine Befreiung angebracht. Neben einer Nachricht, weshalb eine Befreiung beantragt wird, kann der Genehmiger eine Notiz hinterlassen, weshalb eine Befreiung erteilt oder verweigert wird.

Fazit

Mit dem statischen Code-Analyse-Tool „SAP Code Inspector“ und dem darüber gesetzten „ABAP Test Cockpit“ lassen sich also sehr gute Qualitätsprozesse im Bereich der ABAP-Entwicklung etablieren, sodass ein einheitliches und vor Qualität nur so strotzendes Produkt entsteht.

Dieser Blog-Eintrag gibt nur einen groben Überblick über die Möglichkeiten, die SAP den Entwicklern an die Hand gibt, um die eigenen Entwicklungen zu verbessern.

Der nächste Beitrag dieser kleinen Blogserie über Qualitätssicherung von ABAP-Coding wird von automatisierten ABAP-Unit-Tests und Test-Driven-Development handeln.

Keine Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.