047: ABAP - ADT for VS Code (Part 3)

Inhaltsverzeichnis

• Schritte
• Copilot
• MCP
• Agent
• Beispiel - Roman Numbers
• Ausblick

In den letzten Folgen hatten wir uns VS Code angeschaut und wie du die verschiedenen Funktionen für die ABAP-Entwicklung aufrufen kannst. Dabei sind wir Schritt für Schritt durch den Editor gegangen und haben uns die verschiedenen Features angeschaut. Ein großer Punkt ist aber auch, dass Agentic AI nun über weite Strecken für den Code ganz einfach umsetzbar und möglich ist. Deshalb schauen wir uns jetzt in dieser Folge Agentic AI mit dem Fokus auf die ABAP-Entwicklung an und welche Features du bereits heute verwenden kannst.

 

Schritte

Dabei beschreibt Agentic AI eigentlich nur, dass ein generatives Large Language Modell iterativ an einem Problem arbeitet. Dabei gibt es einen sogenannten Agenten, den wir definieren und der gewisse Eigenschaften und Fertigkeiten mitbringt, welcher dann das Problem bzw. den eigentlichen Prompt bearbeitet und die Umsetzung im System macht. Dabei kann ein Agent-Loop entstehen: Wenn zum Beispiel das Ziel nicht erreicht ist, arbeitet der Agent so lange weiter, bis zum Beispiel Fehler behoben sind und sich der Code aktivieren lässt.

Für die Konfiguration in VS Code verwenden wir den Copilot. Dabei hast du zwei Möglichkeiten: Entweder du aktivierst deinen GitHub-Account und loggst dich damit ein oder du verwendest zum Beispiel einen API-Key, wenn du ein Large Language Model abonniert hast, wie zum Beispiel Gemini oder Claude. Danach müssen wir weitere Tools aktivieren, hier den eingebauten MCP-Server in ABAP. Diesen aktivieren wir und integrieren ihn dann in den Copilot, damit die Tools auch verwendet werden. Im dritten Schritt definieren wir uns den eigentlichen Agenten, unseren ABAP-Developer, der später einmal die Entwicklung durchführen soll und gewisse Guidelines von uns mitbekommt. Im letzten Schritt könnten wir noch Custom Instructions hinterlegen, das sind zusätzliche Arbeitsanweisungen, die wir dann einem Prompt mitgeben können. Dieser Schritt ist aber erst einmal optional und diesen würden wir in diesem Video auch nicht ausführen.

 

Copilot

Die nächsten Schritte wollen wir uns natürlich live im System anschauen und wechseln dazu wieder zurück in unseren Editor, um dort die Konfiguration vornehmen zu können. Im oberen Bereich findest du dazu die Seitenleiste, die wir aufklappen können, um dann den eingebauten Chat zu sehen. Im Chat hast du oben verschiedene Einstellungsmöglichkeiten, um neue Chats anzulegen, Einstellungen vorzunehmen, zu aktualisieren oder die Breite zu ändern. Im unteren Teil findest du das Eingabefenster. Für unseren Agenten beziehungsweise unseren ABAP-Developer: Wenn wir einmal auf den Punkt Modelle klicken, sehen wir, dass wir aktuell keine Modelle zur Verfügung haben. Wir können uns aber in den Copilot einloggen, um diese zu Laden. Dazu findest du im unteren Teil das Copilot-Icon und kannst dann auswählen, wie du dich anmelden möchtest, entweder per GitHub, per Google, per Apple zum Beispiel oder über andere Authentifizierungsmöglichkeiten.

Nachdem wir uns dann im Browser authentifiziert haben, finden wir weitere Einstellungen hinter dem GitHub-Copilot-Icon. So sehen wir zum Beispiel die verbrauchten Credits, die wir haben, aber hier können wir zum Beispiel auch Inline Suggestions ausschalten. Diese Vorschläge, die uns Copilot macht, während wir im Editor arbeiten, haben nämlich auch Nachteile: Wenn wir in einer leeren Klasse arbeiten, bekommen wir teilweise Vorschläge, die total irrelevant sind für unser eigentliches Vorhaben und unsere eigentliche Klasse. Deshab schalten wir der Einfachheit halber den Ghost Text aus. Gehst du nun im Chatfenster auf die Auswahl der Modelle, findest du die verfügbaren Modelle, die über GitHub Copilot angeboten werden. Hier wählen wir Claude 4.6 Sonnet aus, da das Modell völlig ausreichend ist, um ABAP-Code mit einem guten Kontext zu generieren. Hinter dem Modell hast du dann noch weitere Einstellungsmöglichkeiten, um die Effektivität des Modells zu steigern oder Kosten zu sparen, wenn zum Beispiel die Kontextleistung reduziert wird.

 

MCP

Ein wichtiger Bestandteil zur guten Arbeit eines Agenten und zur Anreicherung von Informationen ist ein MCP-Server. Dieser Server wird mittlerweile mit den ABAP Development Tools ausgeliefert und läuft dabei direkt auf dem Language Server, so wie wir es bereits in der Theorie hatten. Aktuell wird dieser Server aber inaktiv ausgeliefert und wir müssen diesen erst über die Einstellungen aktivieren. Dazu wechseln wir in die Einstellungen, zum Beispiel mit Strg + Komma, und können dann in den Bereich Extensions wechseln. Dort findest du die ABAP Development Tools, öffnest diese und scrollst ganz nach unten, um die Einstellungen für den MCP-Server zu finden. Bevor du den MCP-Server aktivierst, kannst du auch noch den Port einstellen, wenn du einen anderen Port auf deinem Gerät wählen möchtest. Nach dem Einschalten des MCP-Services kommt eine entsprechende Meldung in VS Code, die darauf hinweist, dass nun der Server hochfährt. Hier kann es sein, dass du sonst Fehlermeldungen erhältst, wenn es Probleme bei der Aktivierung gibt.

Wechseln wir nun wieder zurück zum Copilot-Chat. Hier finden wir hinter dem ausgewählten Modell noch die Möglichkeit, die Tools zu konfigurieren. Wir klicken auf den Button und bekommen eine entsprechende Übersicht mit allen Tools in unserem Editor. Dabei definiert diese Einstellung die Tools, die unser Agent später verwenden darf. Hier sind bereits Tools wie das Editieren von Dateien oder die Suche im Workspace aktiviert. Im unteren Bereich findest du den ADT-MCP-Server. Hier solltest du sicherstellen, dass alle Tools aktiviert sind, die du auch benutzen möchtest. Der Einfachheit halber aktivieren wir alle Tools, die verfügbar sind. Grundsätzlich könntest du auch Schreibtools oder Tools, die etwas im System anlegen, deaktivieren, wenn du nur den Read-only-Modus verwenden möchtest.

 

Agent

Der letzte Schritt der Konfiguration ist nun die Anlage des eigentlichen Agenten, der die ABAP-Entwicklung unterstützen soll. Dazu findest du im Copilot-Chat wieder eine Möglichkeit, dieses Mal auf der linken Seite des Modells, wo auch der Agent-Modus oder das Symbol für den Agent-Modus aktiv ist. Grundsätzlich kannst du verschiedene Agents anlegen, die einen verschiedenen Kontext haben und verschiedene Anweisungen im Bauch. So könntest du zum Beispiel auch einen Review-Agenten anlegen, der Code-Reviews für dich durchführt, um vorab eine gewisse Codequalität sicherzustellen, bevor du dann den Review an deine Kollegen gibst. Über den Button "Custom Agent" legen wir einen neuen Agenten im System an. Dazu gehst du auf "Create New Agent", um den Wizard für die Anlage zu starten. Als Nächstes müssen wir den Ablageort definieren. Hier haben wir zum Beispiel die Möglichkeit, ihn im aktuellen Workspace zu hinterlegen, oder wir können ihn zum Beispiel auch global im Copilot-Bereich ablegen, damit der Agent global verfügbar ist. In diesem Fall sorgen wir dafür, dass der Agent für den Copilot zur Verfügung steht, und wählen das Verzeichnis aus. Nun geben wir dem Agenten noch einen Namen. Dieser Name wird in der Datei hinterlegt, aber auch später bei der Auswahl des Agents angezeigt. Im Anschluss wird ein Markdown-File angelegt, welches wir nun mit unseren Anweisungen anreichern können. Grundsätzlich besteht ein Agent nur aus Beschreibungen, die die eigentlichen Tools beschreiben und welche Regeln er beachten sollte, also keine große Magie.

Brauchst du eine erste initiale Beladung des Agenten, findest du weitere Informationen in der SAP-Dokumentation. Hier ist bereits ein Test-File mit ersten Anweisungen definiert. Dieses kannst du kopieren und dann in deinen Agenten einfügen. Später ist einmal angedacht, dass initial mit dem Plugin auch automatisch ein agent.md-File ausgeliefert wird, welches du verwenden kannst, um einen ersten Standard-Agenten zu konfigurieren. Wir fügen nun unser eigenes Agent-File ein. Dabei siehst du im oberen Teil erst einmal einige Konfigurationsmöglichkeiten wie den Namen des Agents, eine kurze Beschreibung, was der Agent eigentlich tut, und verschiedene Tools, die dem Agenten später zur Verfügung stehen. Im unteren Bereich findest du die Informationen teilweise aus der Vorlage und teilweise schon ergänzt, also erst einmal allgemeine Informationen und im unteren Bereich auch Instruktionen zum Thema Testing. Da wir noch weitere Anforderungen haben, fügen wir noch das Thema Qualität mit ein. So sollen zum Beispiel keine ungarischen Notationen verwendet werden, also keine Variablen-Präfixe. Kommentare sollten nur verwendet werden, wenn nötig. Der Agent soll sich an die Clean ABAP Guidelines halten und beschreibende Namen für Variablen verwenden, also gewisse Qualitäten, die wir in unserem Code haben wollen. Zum Abschluss speicherst du die Datei und bist mit der Konfiguration des Agents fertig. Der Agent steht nun zur Verfügung und kann gewählt werden, damit dieser beim nächsten Chat auch berücksichtigt wird.

 

Beispiel - Roman Numbers

Im nächsten Beispiel wollen wir eine Klasse from Scratch erstellen, die es so noch nicht im System gibt. Das heißt, wir fangen mit unserem eigentlichen Prompt an und sagen, dass wir eine Klasse benötigen, die auch in einem bestimmten Paket abgelegt werden soll. Dabei geben wir den Namen der Klasse erst einmal nicht vor. Vom Inhalt her sagen wir, dass römische Zahlen in arabische Zahlen konvertiert werden sollen. Und wir benötigen auch Unit-Tests, um zu validieren, dass die Logik funktioniert, und es sollen auch die verschiedenen Edge Cases mit getestet werden.

Das LLM beginnt nun mit dem Arbeiten und stellt erst einmal für uns eine To-do-Liste auf. Das heißt, wir sehen schon mal, was der Agent in den nächsten Schritten tun möchte. Diese To-do-Liste können wir aufklappen und sehen so zum Beispiel, dass er sich erst einmal die Liste der Destinationen holen möchte, da wir nicht angegeben haben, auf welchem System die Umsetzung erfolgen soll. Als Nächstes würde er dann die Klasse anlegen, würde dann verschiedene Unit-Tests hinzufügen und am Ende versuchen, die Klasse zu aktivieren. Das Aktivieren ist deshalb wichtig, da wir am Ende feststellen, ob noch Fehler in der Klasse vorhanden sind, was durchaus möglich ist. Dann erhält das LLM entsprechende Informationen und kann die Fehler korrigieren.

Im oberen Teil fragt der Agent bereits nach entsprechenden Berechtigungen. Bestimmte Tool-Aufrufe müssen wir hier manuell approven, weil das unsere Default-Einstellungen sind. Diese Default-Einstellung findest du im unteren Bereich und kannst sie zum Beispiel auch so setzen, dass alle Tools automatisch akzeptiert werden. In diesem Fall wollen wir aber etwas die Kontrolle behalten und schauen uns die verschiedenen Aufrufe an. Der erste Aufruf ist direkt vom MCP-Server und er versucht aktuell die vorhandenen Destinations abzurufen. Das heißt, er möchte sich einen Überblick verschaffen, welche Systeme verfügbar sind und auf welchem System er eigentlich arbeiten sollte. Im nächsten Schritt validiert das Large Language Model erst einmal über die Destination, die es gefunden hat, den entsprechenden Klassennamen, also ob es diese Klasse bereits im System gibt. Diesen Tool-Request akzeptieren wir ebenfalls. Über den Kontext sehen wir entsprechend, was er eigentlich versucht; in diesem Fall versucht er auf dem Paket zu schauen, ob die entsprechende Klasse vorhanden ist. Der nächste Request ist dann, ob er auch die Klasse anlegen darf. Das heißt, wir sagen "akzeptieren", damit die Klasse auf dem System angelegt wird. Was er nun tut. Auf der anderen Seite können wir dann einmal den Workspace aktualisieren und sehen, dass die Klasse bereits im System vorhanden ist. Allerdings ist diese noch leer. Der Agent hat erst einmal die leere Implementierung angelegt und einen entsprechenden Namen vergeben. Der Agent beginnt nun mit dem eigentlichen Implementierungsgedanken. Das heißt, man sieht im Chat erst einmal, was er sich überlegt, welche Implementierung er anlegen will, welche Edge Cases es gibt und was er noch so berücksichtigen sollte. Grundsätzlich interessant, um zu verstehen, wie iterativ der Agent vorgeht und welche Dinge er sich anschaut, die er dabei bedenken muss. Aktuell haben wir noch keine Änderungen im System, das ist der eigentliche Denkprozess, der hier noch im Hintergrund läuft.

Der Agent hat nun erste Änderungen an der Klasse vorgenommen. Diese können wir sehr gut sehen: Erstens ist die Klasse nun mit den ersten Informationen befüllt. Auf der linken Seite sehen wir alle geänderten Objekte oder Includes, an denen bereits Änderungen vorgenommen wurden, und unter der To-do-Liste sehen wir ebenfalls, dass sich Dateien geändert haben. Hier ist nun die Möglichkeit, um Änderungen zu bestätigen oder rückgängig zu machen, da sonst der Agent einfach fortfährt. Wir können die Änderungen aufrufen, indem wir auf die Datei klicken, und im Callout sehen wir die geänderten Zeilen, die wir dann mit "Keep" bestätigen können oder mit "Undo" wieder zurückdrehen können. Hier solltest du ein wenig Zeit investieren in den Review-Prozess und dir anschauen, was eigentlich generiert wurde und ob dies deinen Anforderungen entspricht. Der Agent hat drei Methoden implementiert: Eine Methode für die eigentliche Konvertzierungslogik, eine Methode zur Validierung der Inhalte und eine weitere Methode, um die Konfiguration der verschiedenen Symbole zu erhalten. Wir können nun auch einmal auf die Datei klicken und sehen, dass wir in den Unit-Tests landen. Hier hat der Agent bereits eine ziemlich große Anzahl von Unit-Tests aufgebaut. Diese behalten wir ebenfalls mit "Keep".

Zum Abschluss bestätigen wir noch, dass die Klasse aktiviert werden soll. Dann aktiviert Copilot entsprechend die komplette Klasse. Sind noch Fehler vorhanden, wie in diesem Fall, macht er noch weitere Anpassungen an der Logik. Ist die Aktivierung erfolgreich durchgelaufen, möchte Copilot nun die Unit-Tests zum Abschluss starten, um zu prüfen, ob das Ergebnis korrekt ist. Zum Abschluss erhalten wir eine Gesamtsicht, was nun passiert ist: Es sind alle Unit-Tests durchgelaufen, es wurden verschiedene Edge Cases getestet und die Logik wurde implementiert. Damit ist der eigentliche Agent-Loop nun beendet und wir können uns das Ergebnis im System anschauen. Grundsätzlich wäre es nun unsere Aufgabe zu validieren, dass die Best Practices eingehalten werden. Und wir können zum Beispiel entweder selbst nacharbeiten oder dem Agenten weitere Instruktionen geben, um bestimmte Codebestandteile anzupassen, mit denen wir vielleicht noch nicht zufrieden sind.

 

Ausblick

Der Agent wurde nun im System eingerichtet und eine erste Klasse von ihm implementiert. Die Konfiguration muss deshalb sauber durchgeführt werden, damit ein entsprechendes Large Language Model vorhanden ist und wir dem Agenten auch Kontext mitgeben können. Der Agent sollte natürlich wissen, was für ein Agent er ist und welche Möglichkeiten er hat, was wir mit der "agent.md" realisiert haben. In der nächsten Folge werden wir dann auf weitere Beispiele aus dem Bereich der Unit-Tests eingehen und uns das Thema RAP-Entwicklung anschauen. Danach werden wir die restlichen Folgen durchgehen und die Präsentation abschließen. Deshalb schon einmal danke bis hierher fürs Zuschauen und für das Interesse ... und bis zum nächsten Mal.

 

YouTube
Video