054: Recycling-Heroes - Data Generation (Document)
In dieser Folge generieren wir Testdaten Off-Stack mit Claude und lassen uns die Methode schreiben, bevor wir dann im echten ABAP System den Review durchführen und die Beispieldaten für unsere Dokumente laden.
Inhaltsverzeichnis
In dieser Folge wollen wir Off-Stack Testdaten für unsere Dokumenten-App generieren, uns den ABAP-Code schreiben lassen, den wir dann ins Git-Repository pushen und am Ende im ABAP-System ausführen, um uns das Einfügen der verschiedenen Testdaten zu erleichtern.
Clone
Dazu verwenden wir Visual Studio Code mit einem installierten Claude-Code-Plugin und Git, um an die Daten zu kommen. In der gleichen Installation ist auch ABAP installiert, welches aber aktuell nicht läuft. In dieser Folge wollen wir in VS Code ohne ABAP und ABAP MCP arbeiten. Dazu müssen wir im ersten Schritt den Git-Clone durchführen und verwenden dafür unser Recycling-Heroes-Core-Repository. Dieses klonen wir in unser Projektverzeichnis, wo auch andere Projekte von GitHub liegen. Als Nächstes lassen wir dies in einem neuen Fenster öffnen. Damit ist unser Workspace fokussiert auf das aktuelle Git-Repository. Damit es das LLM etwas leichter hat, öffnen wir die Dateien, die wir bearbeiten wollen, wie unsere Initialisierungsklasse für die Daten, und öffnen gleichzeitig auch die JSON-Files, für die wir auch weiterhin Testdaten generieren wollen. Damit ist unser Workspace vorbereitet, um gleich mit dem LLM darauf zu arbeiten.
Prompting
Wir verwenden das Claude-Code-Plugin und dazu das Modell Opus 5.5 in der Einstellung "Medium". Damit wir uns das Tippen sparen können, geben wir per Voice-Input die verschiedenen Details an das Large Language Model weiter. Dazu weisen wir darauf hin, dass wir eine neue Methode in der aktuellen Klasse haben wollen, die für die Dokumente-Entitäten generiert. Dabei soll ein neues Verzeichnis "Attachment" auf dem Root-Layer angelegt werden, in dem die verschiedenen Dokumente angelegt werden. Zusätzlich geben wir Informationen darüber mit, welche Dokumente wir generieren wollen und für welche Zielgruppe, sodass wir zum Beispiel für alle Employees die verschiedenen Basisdokumente haben. Gleichzeitig wollen wir auch für Customers kleine Bilder anhand des Titels und der Beschreibung sowie fünf Fahrzeuge haben, die später eingefügt werden sollen. Zusätzlich geben wir noch Informationen dazu mit, welches der eigentliche Core Data Service ist, der als Referenzdatentyp verwendet werden soll, um den Prompt damit abzuschließen. Das Modell fängt nun an zu arbeiten, um herauszufinden, was es anlegen soll, in welchem Format, und um die verschiedenen Todos durchzuführen.
Dateien
Die Generierung ist nun abgeschlossen. Schauen wir uns einmal die Klasse im Detail an. Dort wurden zwei neue Methoden generiert: "load_documents", was die eigentlichen Dokumente von GitHub herunterlädt und ungefähr die gleiche Logik anwendet wie zuvor, und die Methode "get_attachment", die dann die einzelnen Entitäten separat liest.
Scrollen wir dann nach oben, finden wir einen neuen Ordner für die Attachments, die angelegt wurden. Ebenso eine neue Datei für die verschiedenen Dokumente. Auf den ersten Blick haben die Dokumente verschiedene Texte erhalten, Informationen zu den Employees, die wir auch über die Employee-Datei bereitgestellt haben. Spannend wird hier später vor allem beim Einfügen, dass die richtigen Tags geladen werden, da diese über die UUID im System angelegt sind.
Schauen wir uns dann einmal die Testdateien an, so finden wir verschiedene Bilder zu unseren Angestellten. Ebenso können wir uns ein PDF anschauen, welches auf den ersten Blick in Ordnung aussieht. Für den ersten Grob-Check ist das soweit in Ordnung. Führen wir nun einen Push durch, um die neuen Testdaten und die angepasste Klasse zurück ins Git-Repository zu bringen.
GitHub
Die Daten sind nun auf GitHub angekommen und wir finden unseren Commit mit den verschiedenen Assets, die hinzugefügt wurden. Navigieren wir dann zurück ins Repository, können wir uns die verschiedenen Attachments einmal im Detail anschauen, da wir bisher zum Beispiel noch nicht die PDFs gesehen haben. Hier wurden verschiedene Bewertungsdokumente der Recycling Heroes GmbH angelegt, ebenso wie ein CV, welches erfundene Informationen enthält, perfekt für unsere Testdaten also.
ABAP
Zurück in ABAP müssen wir nun unsere angepasste Klasse wieder ins System einspielen. Die anderen Dokumente verbleiben weiterhin auf GitHub. Diese können wir nicht ins System bringen. Dazu gehen wir in das abapGit-Plugin, welches in unserer Eclipse-Installation vorhanden ist, und führen einen Pull auf dem Repository durch. Hier wählen wir unsere Klasse für die Initialdaten, um diese dann zurück ins System zu bringen. abapGit benötigt nun eine kurze Weile, um die verschiedenen Objekte wieder ins System zu holen und zu überschreiben. Sind wir damit fertig, müssen wir einmal alles Inaktive im System aktivieren, um einen sauberen Stand herzustellen. Damit können wir auch prüfen, ob die Anpassungen, die von Claude durchgeführt wurden, auch zum richtigen Ergebnis geführt haben und wir keine Syntaxfehler im Code haben.
Bevor wir dann den Code im System ausführen, wollen wir noch ein kurzes Code-Review machen und die Ergebnisse prüfen. Vorher sollten wir noch alle alten Daten, die wir bereits generiert haben, auskommentieren, damit wir nur die neuen Entitäten im System anlegen. Auf den ersten Blick liest die Logik das Dokument von GitHub ein. Gleichzeitig werden die angelegten Texte gelesen, um die passende UUID zuzuordnen. Im unteren Bereich wird dann auch das Mapping durchgeführt, um einen neuen Eintrag anzulegen, und zum Abschluss ein MODIFY ENTITIES ausgeführt. Somit werden die Daten im System generiert. Führen wir zum Abschluss nun die Klasse aus und lassen die Dokumente im System generieren. Das Ergebnis erhalten wir dann in der Konsole: alle importierten und angelegten Dokumente.
Test
Zum Abschluss gehen wir dann noch in die Preview unserer Anwendung und lassen uns einmal alle Dokumente laden, um das Ergebnis zu prüfen, das wir eingespielt haben. Wir sehen soweit alle zugeordneten Dokumente und Dokumententypen, die angelegt wurden. In den Details finden wir auch die zugeordneten Tags, hier zum Beispiel PDF, Personal und Important. Über einen Klick auf das Dokument können wir den Download starten. Prüfen wir dann einmal das Dokument, sehen wir, dass das PDF sauber im System angehängt wurde und sich nun ebenfalls an dem Beleg befindet.
Zusammenfassung
In der heutigen Folge wollten wir uns einmal anschauen, wie wir Off-Stack ohne ein ABAP-System Testdaten generieren können. Mit Hilfe von modernen LLMs, die mittlerweile sehr gut entwickeln können, haben wir Testdaten, aber auch die ABAP-Anpassungen erzeugt und diese dann wieder ins System deployed, um zu validieren, ob das Ergebnis dem entspricht, was wir haben wollten. Grundsätzlich müssen wir sagen, dass wir die ABAP-Klasse kein einziges Mal nacharbeiten mussten, sondern das, was ursprünglich angepasst wurde, auch 1 zu 1 übernommen werden konnte. Damit haben wir unzählige Dokumente im System für unsere verschiedenen Anwendungsfälle definiert, ohne eigentlichen Code schreiben zu müssen oder uns umständlich Testinformationen auszudenken. Wir hoffen du konntest etwas mitnehmen. Danke fürs Zuschauen und bis zum nächsten Mal.
YouTube
Video