BTP - ATC Automatisierung
Wie kannst du dein ABAP Test Cockpit in der BTP automatisieren und dir die Ergebnisse zuschicken lassen, wenn es einmal Probleme gibt? In diesem Artikel gehen wir auf die Details ein.
Inhaltsverzeichnis
In diesem Artikel gehen wir auf die aktuellen Möglichkeiten des ABAP Test Cockpit für die Automatisierung in der BTP ein. Dazu schauen wir uns den Standard an und wie wir den Rest übernehmen können.
Einleitung
Das ABAP Test Cockpit im SAP BTP ABAP Environment bietet eine zentrale Lösung an, um alle Backendsysteme automatisch zu prüfen. Im Gegensatz zur klassischen On-Prem Transaktion ATC, funktionieren allerdings einige Prozesse im ABAP Environment anders. Daher schauen wir uns die aktuellen Möglichkeiten an und wie wir den Prozess möglichst automatisieren können.
Prüfvariante
Im ersten Schritt benötigen wir eine Prüfvariante, um eine Prüfung im System durchführen zu können. In dieser Prüfvariante wollen wir die eigentliche Prüfung definieren, aber auch den Scope der Prüfung einstellen, damit die passenden Entwicklungsartefakte geprüft werden.
Apps
Mit dem Release 2508 wurde die Anwendung "Custom Code Migration" auf zwei neue Tiles aufgeteilt. Damit soll die Anwendung verschiedenen Rollen zugeordnet werden, grundsätzlich wird die gleiche Anwendung aufgerufen. Über die Anwendungen kannst du einen neuen Lauf einplanen.
Projekt
In der App legen wir ein neues Projekt an. Über den "Create" Button kannst du ein neues "Custom Code Analysis Project" anlegen. Dieses benötigen wir, um einen eigenen Prüflauf zu starten.
In der Variante können wir nun einen Namen vergeben, dann wählen wir ein Prüfvariante aus. Hier kannst du eigene Prüfvarianten definieren, aber auch alle Standardvarianten wählen. Grundsätzlich können wir auch ein Remotesystem angeben, wenn wir ein On-Prem System prüfen wollen. In diesem Fall prüfen wir das lokale System.
Im nächsten Schritt können wir den Scope der Prüfung definieren. Wollen wir bestimmte Pakete prüfen, dann können wir hier all unsere Pakete angeben. Wollen wir alles prüfen oder bestimmte Pakete ausschließen, dann können wir dies im unteren Teil einstellen. Sind wir damit fertig, entfernen wir noch das Flag, damit die Prüfung nicht direkt im Anschluss startet.
Job
Um nun die Prüfung automatisieren zu können, können wir einen Job im System einplanen. Hier finden wir die Anwendung "Schedule Custom Code Analysis", die im Grunde die Standard App für die Application Jobs verwendet.
Über "Create" kannst du einen neuen Job erstellen, hier sollte die richtige Variante bereits voreingestellt sein. Weiterhin kannst du einstellen, ob der Job einmalig oder wiederkehrend laufen soll. Grundsätzlich führt der Job nun die Prüfung aus und persistiert das Ergebnis auf der Datenbank.
Ergebnisse
Die Ergebnisse des Laufs werden im System persistiert. Seit dem Release 2508 gibt es nun auch Core Data Services im Standard, die du für das Lesen nutzen kannst. Hierfür gibt es die Views:
- SATC_API_RESULT_HEADERS - Hier findest du die verschiedenen Läufe, die durchgeführt wurden. Du kannst nach Zeitstempel und anderen Kriterien filtern.
- SATC_API_FINDINGS - Die verschiedenen Findings eines Prüflaufs kannst du in dieser Tabelle finden. Neben der Meldung und der Klassifizierung findest du weitere Informationen zu den Findings.
Automatisierung
Damit wäre so weit der aktuelle Standard erklärt. Wie können wir hier noch den Schritt des Mailversands automatisieren? Dazu verwenden wir eine kleine Eigenentwicklung, die du auch auf GitHub findest, wenn du sie ebenfalls verwenden willst.
Application Job
Da wir direkt im Anschluss die Ergebnisse prüfen wollen, erstellen wir einen Application Job, den wir später als zweiten Schritt in der Einplanung definieren wollen. Dieser Job soll das Ergebnis des Prüflaufs über die Core Data Services extrahieren und nach bestimmten Kriterien aufbereiten.
Implementierung
Bei der Implementierung der Logik lesen wir die letzten Läufe aus den beiden Core Data Services, prüfen ob die entsprechenden Fehlerkategorien enthalten sind und bereiten die E-Mail für den Versand vor. Die Daten bereiten wir dann in der Mail als HTML auf. Den Code findest du im verlinkten GitHub Repository, wenn du dir die verschiedenen Objekte und Bestandteile anschauen möchtest. Zum einfachen Handling der Fehler und Nachrichten haben wir den ABAP Message Logger verwendet.
Template
Damit unser Benachrichtigungsjob direkt nach unserer Prüfung gestartet wird, erstellen wir ein neues Template im System. Dazu gehen wir in die App "Application Job Templates" und erstellen über "Create" ein neues Template. Hier geben wir einen Namen und können die Sichtbarkeit einstellen.
Über den Button "Maintain Steps" im unteren Bereich, können wir nun unsere Schritte hinzufügen. Mit "Save Job Template" werden die beiden Schritt hinzugefügt. Im Template können wir Standardwerte setzen, das können wir aber auch später bei der Einplanung des Jobs machen.
Mit "Save" speichern wir das Template und können die App wieder verlassen.
Ausführung
Um nun den Job zu einzuplanen, wechseln wir wieder in die App "Application Jobs" und legen über "Create" einen neuen Job an. Hier wählen wir für den Start das gewählte Template aus. Möchtest du den Job regelmäßig einplanen, dann kannst du hier noch die Optionen im zweiten Schritt befüllen. Im dritten Schritt befüllen wir die Parameter und wählen den Prüflauf aus.
Für unsere Benachrichtigungen wollen wir den letzten ATC Lauf verwenden, daher stellen wir die Anzahl auf 1. Wir möchten gern eine Mail erhalten, wenn die Priorität auf Fehler oder Warnung steht. Dann tragen wir noch Absender und Empfänger für den E-Mail Versand ein.
Mit "Schedule" wird der Job ausgeführt, je nach Einstellung wird dieser sofort gestartet. Sind alle Kriterien erfüllt, sollten wir dann auch eine Mail erhalten.
Fazit
Damit wurde die ABAP Test Cockpit im System automatisiert und wir erhalten zum Abschluss eine E-Mail. Zusätzlich können wir noch steuern, dass wir nur eine E-Mail erhalten, wenn Fehler in der Prüfung sind. Damit können wir mit einer kleinen Eigenentwicklung den Prozess automatisieren.
