SAP-Daten für KI-Agenten zugänglich machen: Wie ich einen eigenen MCP-Server für ABAP gebaut habe

Wer aktuell KI für ABAP-Code nutzt, macht das meistens so: Code aus SAP kopieren, in ChatGPT oder Claude einfügen, bearbeiten lassen, Ergebnis zurückkopieren. Bei jeder Änderung wieder von vorne. Das funktioniert, ist aber Handarbeit, die sich nicht skaliert, und bei größeren Funktionsbausteinen oder Reports wird es schnell unübersichtlich. Ich habe mir überlegt: Warum nicht die KI direkt an SAP dranhängen, so wie sie an jedes andere System auch angebunden wird. Das Ergebnis ist ein eigener MCP-Server, der SAP-Daten lesend und schreibend für KI-Agenten zugänglich macht.

Ein MCP-Server (Model Context Protocol) ist im Grunde eine standardisierte Schnittstelle zwischen KI-Agenten und einem System, ähnlich wie eine API, nur speziell für den Zugriff durch LLMs gebaut. Der SAP-MCP-Server macht ABAP-Quellcode von Funktionsbausteinen und Reports für KI-Agenten direkt lesbar und beschreibbar, wenn man dem Agenten die nötigen Berechtigungen gibt. Statt Code manuell zu exportieren, zu bearbeiten und wieder zu importieren, liest der Agent den Stand direkt aus dem System, schlägt Änderungen vor und schreibt sie nach Freigabe zurück. Zugriff läuft über die üblichen SAP-Schnittstellen wie RFC und BAPI, abgesichert über ein eigenes Berechtigungskonzept statt offenem Vollzugriff. Ich habe den Server neben meiner Tätigkeit im SAP-Umfeld gebaut, aus einer konkreten Frustration heraus, nicht als Experiment am Wochenende. Inzwischen ist er fester Bestandteil der täglichen Arbeit im SD-Umfeld, bei Materialstammdaten, Preisfindung und Verfügbarkeitsprüfung.

Der Server setzt auf RFC- und BAPI-Verbindungen auf, über die er Funktionsbausteine, Reports und Stammdaten wie Materialstammdaten (MARA, MVKE, MARC) auslesen kann. Schreibzugriffe sind bewusst eng begrenzt: der Agent bekommt nur die Berechtigungen, die für die jeweilige Aufgabe nötig sind, nicht pauschalen Zugriff auf das ganze System. Bevor eine Änderung tatsächlich ins System zurückgeschrieben wird, läuft sie durch eine Bestätigung, kein automatisches Durchschreiben ohne Kontrolle. Das ist bewusst so gebaut, weil ein Fehler in einem produktiven SAP-System teurer wird als in einer Testumgebung.

Für die Anbindung an KI-Modelle nutze ich das Model Context Protocol direkt: Claude, GPT und andere LLMs sprechen darüber mit dem Server, ohne dass ich für jedes Modell eine eigene Integration bauen muss. Das ist der eigentliche Vorteil von MCP gegenüber einer klassischen API: einmal gebaut, funktioniert es mit jedem MCP-fähigen KI-System.

Ein MCP-Server allein reicht nicht, weil er die internen Prozesse einer Firma nicht kennt. Ein Agent, der lesend und schreibend auf SAP zugreifen kann, aber nicht weiß, warum ein Prozess in genau dieser Firma anders läuft als im SAP-Standard, macht am Ende trotzdem Fehler oder braucht ständig Nachfragen. Deshalb gibt es zusätzlich eine Wissensquelle: interne Dokumentation wird gecrawlt, auch Screenshots werden per Bild-zu-Text-Erkennung ausgewertet, und das Ergebnis läuft über einen zweiten MCP-Server, der Agenten und LLMs Zugriff auf firmeninternes Prozesswissen gibt. Damit muss man einem Agenten nicht bei jeder Anfrage neu erklären, was Prozess A oder B in genau diesem Unternehmen bedeutet, er kann selbst nachschlagen. Bei einem Kunden läuft das inzwischen produktiv für Materialstammdaten, Verfügbarkeitsprüfung und Preisfindung im SD-Umfeld.

Firmen, die überlegen, KI an ihr SAP-System anzubinden, stehen meistens vor zwei Optionen: eine große SAP-Beratung mit entsprechendem Overhead beauftragen, oder direkt mit jemandem arbeiten, der beides selbst gebaut hat und versteht. Wir bieten das Zweite: SAP-Anbindung und MCP-Server-Entwicklung aus einer Hand, mit klar abgestecktem Umfang, den wir vorher gemeinsam festlegen. Wer wissen will, ob und wie sich das für die eigene SAP-Landschaft umsetzen lässt, sieht sich mit uns die bestehende Systemlandschaft gemeinsam an, bevor irgendetwas gebaut wird.

Häufige Fragen