Agentic AI in der Praxis: MCP-Server für SAP BW/4HANA

Im April hatten ich hier den bw-modeling-mcp vorgestellt, einen Open-Source-MCP-Server, der KI-Assistenten direkt in SAP BW/4HANA arbeiten lässt. Der Server konnte damals schon viel. Was ihm fehlte, war der Praxisbeweis. Getestet hatten wir ausschließlich gegen eigene Demo-Systeme. Erfahrungswerte aus echten Kundenlandschaften gab es noch keine.

Drei Monate später sieht der Arbeitsalltag im BW anders aus als je zuvor. Der Server läuft in zwei Kundenprojekten im täglichen Einsatz, deckt den kompletten BW/4HANA-Lebenszyklus ab und lässt sich jetzt auch zentral auf der SAP BTP betreiben. Und es bleibt nicht beim BW. Für SAP Datasphere entwickeln wir gerade ein eigenes Plugin, das aus dem, was der MCP-Server im BW ausliest, die passenden Datasphere-Modelle ableitet und gleich anlegt. Wie das aussieht, können Sie ganz unten im Beitrag selbst nachvollziehen, an einer interaktiven Lineage-Analyse aus genau diesem Plugin.

Das alles gehen ich in diesem Beitrag der Reihe nach durch, vom Server selbst über den zentralen Betrieb bis zu den beiden Kundenprojekten. Den MCP-Server finden Sie wie gehabt im GitHub-Repository: https://github.com/dnic-dev/bw-modeling-mcp.

Ein MCP-Server, der versteht, baut und betreibt

Drei Dimensionen machen den MCP-Server aus. Erst zusammen ergeben sie ein Werkzeug, mit dem man arbeitet, statt zu experimentieren.

Verstehen. Der Agent liest nicht nur Objekte, sondern Zusammenhänge. Suche, Where-Used, Datenfluss-Lineage über sämtliche Ebenen, jeder Objekttyp bis hinunter zur Routine, Planungsmodelle eingeschlossen. Dazu Live-Daten über BICS und die DataSource-Vorschau. Damit läuft der Agent selbstständig rückwärts durch beliebig tiefe Beladungsketten, von der Query bis zum Quellsystem.

Bauen. Alles, was im Modellierungsalltag vorkommt: InfoObjects und InfoAreas, aDSOs, DataSources und InfoSources, Transformationen mit ABAP- und AMDP-Routinen, DTPs, Queries, Prozessketten. Anlegen, ändern, aktivieren, Pakete zuordnen, transportieren. Am Ende steht kein Vorschlag im Chatfenster, sondern ein aktiviertes Objekt auf dem Transportauftrag. Angelegt über dieselbe REST-API und nach demselben Locking-Protokoll, mit denen auch Eclipse BWMT arbeitet.

Betreiben. DTPs ausführen, Requests aktivieren, Daten über die Push-API laden, Prozessketten starten und überwachen, Ladeläufe nach Status, Fehler und Historie analysieren. Erst damit schließt sich der Kreis: Was der Agent baut, kann er auch beladen, prüfen und im Fehlerfall tiefer analysieren.

MCP-Server zentral auf SAP BTP: Vom lokalen Skript zum Enterprise-Betrieb

Bisher konnte der MCP-Server nur lokal betrieben werden. Der lokale Modus ist für einzelne Entwickler gebaut. Ein Node.js-Prozess auf dem eigenen Rechner, die Zugangsdaten in einer lokalen Konfigurationsdatei. Zum Ausprobieren ist das genau richtig. Für ein ganzes Entwicklerteam mit demselben Anspruch trägt es nicht mehr. Es fehlt der zentrale Ort für den Betrieb, der gemeinsame Login und die Möglichkeit für die IT, zu steuern, wer was darf. 

Genau diese Lücke schließt Version 1.2. Der Server läuft jetzt wahlweise weiter lokal oder zentral als HTTP-Dienst auf SAP BTP Cloud Foundry. Die Anmeldung läuft über XSUAA, den Authentifizierungsdienst der BTP, den das Unternehmen ohnehin nutzt. Dahinter führt eine BTP-Destination über den Cloud Connector ins BW. Der MCP-Client braucht nur die URL, den Rest regelt der Login im Browser. Möglich wurde das durch die Vorarbeit von Marian Zeis. Er hatte den XSUAA-Authentifizierungsmechanismus für seinen ABAP-MCP-Server ARC-1 bereits als eigenständiges Paket ausgekoppelt und als fertigen Pull Request beigesteuert. Dieselbe Basis trägt jetzt bw-modeling-mcp.5

Was das praktisch verändert, zeigt der direkte Vergleich:

Zwei Rollen liefert der Server als Vorschlag mit, eine mit den Lese-Tools (BW MCP Reader) und eine mit dem vollen Werkzeugkasten (BW MCP Developer). Einem Reader werden die Schreib-Tools dabei nicht nur verweigert, sie verschwinden aus der Tool-Liste, die KI schlägt einen unerlaubten Aufruf also gar nicht erst vor. Darunter greift über Principal Propagation weiterhin das BW mit seinen Berechtigungen selbst. Die MCP-Rolle ist das erste Tor, die BW-Berechtigung das zweite.

Sehen Sie sich die Aufzeichnung unseres Webinars an: "Bridging Business and Analytics: The Plug-and-Play Future of Data Platforms"

Das erste Projekt: Customer-Exits mit Agentic AI im SAP BW nachbauen

Das erste Beispiel stammt aus einem Kundenprojekt, in dem gerade ein Plattformwechsel im großen Stil läuft. Ein regionaler Energieversorger löst seine über Jahrzehnte gewachsene SAP-IS-U-Umgebung ab und stellt die energiewirtschaftliche Abrechnung auf S/4HANA for Utilities um, zentral betrieben von einem Dienstleister. Das BW/4HANA dahinter bleibt, die Quelle darunter wird vollständig ausgetauscht. Damit ist auch die alte Customer-Exit-Logik weg, denn im standardisierten Betrieb ist für kundeneigene Anreicherung im Quellsystem kein Platz mehr. Was das BW über Jahre aus diesen Exits bezogen hat, liefert der neue Ladeweg schlicht nicht mehr. 

Diese Lücke zu schließen ist Fleißarbeit mit Ansage, und genau die übernimmt der Agent. Er fährt die Kette vom Aufdecken bis zur produktiven Beladung selbst durch, über den BW-MCP für die Modellierung und den ABAP-MCP fürs Lesen der Altlogik.

1. Zuerst bindet der Agent die DataSources aus dem neuen Quellsystem an die bestehenden Provider an und mappt die Felder, die im Standard ankommen. 
2. Das ist die Grundlage für den Abgleich pro DataSource: Welche Felder kamen bisher wirklich herein und wurden gemappt, welche davon fehlen im neuen Ladeweg. Diese Differenz ist der Gap. Für jedes Gap-Feld liest der Agent über den ABAP-MCP-Server die gewachsene Exit-Logik direkt im abzulösenden System aus, Feld für Feld: welche Quelltabelle, welche Ableitung, welche ABAP-Logik dahintersteckt.
3. Dann sucht er den neuen Weg zu denselben Daten. Für jede Lookup-Tabelle aus dem Customer-Exit eine passende CDS-basierte DataSource, als Rückfallebene ein SAPI-ODP-Extraktor. Diese Quellen bindet er ans BW/4HANA an und baut eine Staging-Ladekette dazu auf. In den eigentlichen Ladeketten bekommt jedes betroffene Feld eine Lookup-Routine in AMDP, die den alten Exit auf dem neuen Fundament nachbildet.
4. Zuletzt geht das Ganze in Betrieb. Der Agent implementiert die Ladeschritte, erweitert die Prozessketten, stößt die Testbeladung an und prüft die Ergebnisse direkt im System. Was er baut, kann er auch beladen und kontrollieren.

Automatisch heißt hier nicht unbeaufsichtigt. An den kritischen Punkten hat der Agent zunächst pausiert und gut lesbare Zwischenstände ausgegeben, gegen die wir prüfen konnten, ob bis dahin alles trägt. Erst danach ging es weiter.

Denn das sind keine einzelnen Objektabfragen, sondern vielstufige komplexe Workflows, die manuell ganze Beraterwochen kosten würden. Damit die KI sie zuverlässig durchläuft, müssen sie ebenso präzise spezifiziert sein. Beides liegt bei uns in einem Wissensrepository: das Kontextwissen zur Landschaft und die Workflows als belastbare Runbooks, im Kern ein Verzeichnis aus Markdown-Dateien, aus dem sich jeder neue Lauf bedient.

Das zweite Projekt: Agentic AI migriert BW-Modelle nach SAP Datasphere

Das zweite Beispiel aus einem laufenden Projekt ist ebenfalls eine Migration, diesmal wechselt jedoch nicht die Quelle, sondern das Zielsystem. Die Modelle sollen von der SAP BW Bridge nach SAP Datasphere migriert werden. Das Ziel ist dabei, ein sauberes, neu gedachtes Modell auf der Zielplattform anzustreben und keine 1:1 Abbildung von Logiken und Persistenz-Objekten. Bevor man das bauen kann, muss man aber lückenlos verstehen, was das gewachsene BW-Modell heute wirklich tut.

Dieses Verständnis liefert wieder die Kette aus BW-MCP und ABAP-MCP. Der Agent liest das Modell end-to-end aus und legt die ganze Komplexität offen, die sich über die Jahre angesammelt hat: Transformationslogik mit ABAP-Routinen auf mehreren Ebenen, Lookups auf weitere Tabellen mit eigener Herkunft, Customizing-Tabellen. Daraus entsteht eine vollständige Lineage im BW, dazu eine zweite auf der Datasphere-Seite, die zeigt, was dort schon existiert. Beide lassen sich zu einem durchgehenden Bild verbinden.

Der entscheidende Zwischenschritt ist, diese technische Logik in eine Sprache zu übersetzen, die der Fachbereich lesen kann. Der Agent zieht die Sonderlogiken heraus und beschreibt sie fachlich. Erst dadurch lässt sich prüfen, ob eine Regel heute überhaupt noch gilt oder ob der Fachbereich ein Delta hat, das gleich mit einfließen soll. Denn migriert werden soll nicht 1:1 der alte Stand, sondern der verstandene und bereinigte. Aus diesem geprüften Verständnis abstrahiert die KI ein sauberes, SQL-basiertes Konzept für Datasphere, zunächst als Entwurf. Daraus legt unser eigenes Datasphere-Plugin die Modelle an und nimmt sie über Replication Flow und Task Chains in Betrieb.

Für Datasphere setzen wir bewusst auf ein eigenes Plugin, das wir im Rahmen dieses Projekts entwickeln. Zwar gibt es schon einige Open-Source-MCP-Server, aber sie setzen fast ausschließlich auf der OData-Consumption-API auf, sehen demnach nur die freigegebenen Modelle und nicht die Remote-Tabellen darunter, und sind überwiegend nur lesend. Für das Anlegen von Objekten gibt es Skills auf Basis der Datasphere-CLI. Für verlässliche Automatisierung reicht uns das trotzdem nicht, zu oft muss man von Hand nachfassen, und vor allem fehlt das, was ein Modell erst tragfähig macht: unsere Modellierungsstandards. Genau die bringt unser Plugin mit, die Best Practices aus vielen Projekten, feste Namenskonventionen und die Folgen einer Objektänderung für abhängige Objekte, sauber in Skill-Beschreibungen gefasst. So fügt sich jedes neue Modell in die bestehende Landschaft ein, statt als Insel daneben zu stehen.

Die KI selbst braucht zum Orchestrieren dieses Workflows nur Markdown-Dateien. Wer das Modell verantwortet, will aber mitdenken, eigene Anpassungen einbringen und wirklich verstehen, was passiert. Deshalb erzeugt unser Datasphere-Plugin auch eine Lineage-Analyse, die sich mit der aus dem BW verbinden lässt und die Komplexität eines gewachsenen Modells auf einen Blick zeigt. Wie das aussieht, können Sie im Folgenden selbst durchklicken, bewusst an einem Demomodell aus unserem eigenen System. Über das Detail-Panel blenden Sie zu jedem Schritt die vollständigen Informationen ein, von den Feldern bis zur Routinen-Logik. Die Legende lässt sich interaktiv schalten, und in der Kopfzeile können Sie wählen, ob Datasphere-Assoziationen oder – im BW-Bereich – Lookup-Objekte aus Transformationen und virtuelle Objekte angezeigt werden sollen.

Warum Kontext wichtiger ist als einzelne KI-Tools: Unser Fazit

Inzwischen zählt der BW-MCP-Server 85 Tools über den kompletten BW/4HANA-Lebenszyklus. Diese Breite ist nicht am Reißbrett entstanden, sondern weil diese zwei Projekte den Server Woche für Woche an seine Grenzen gebracht haben, und jede Grenze bedeutete oft ein neues Tool. Inzwischen ist die Menge selbst zum Thema geworden, als Nächstes steht eine Konsolidierung auf weniger, dafür breiter parametrisierte Tools an.

Doch nicht die Werkzeuge allein bestimmen, ob agentische Workflows im Alltag tragen, sondern der Kontext, also alles, was die KI über das System weiß, bevor die erste Aufgabe formuliert ist. Ein Agent, der in einem gewachsenen Kundensystem souverän arbeiten soll, braucht dieses Wissen dauerhaft verfügbar, nicht bei jeder Aufgabe neu erklärt. Wir organisieren es als versioniertes Wissens-Repository und orientieren uns dabei am Open Knowledge Format, einem relativ neuen, offenen Standard von Google für KI-lesbare Wissensbasen.

Wie man so ein Repository schnell aufsetzt, aktuell hält und sauber abgrenzt, ist ein eigenes großes Thema, das wir im nächsten Beitrag gerne vertiefen wollen.

Möchten Sie herausfinden, was Agentic AI in Ihrer SAP-Datenlandschaft konkret leisten kann? Sprechen Sie uns an, wir begleiten Sie von der ersten abgesicherten Umgebung bis zum agentischen Arbeitsalltag.