Agentic AI meets SAP BW

Ich sitze vor der UI und starre auf den Bildschirm: „Aktivierung läuft… Editor nicht änderbar." Man könnte jetzt wie immer einen Kaffee holen. Oder Mails checken. Oder - wie ich es an diesem Tag getan hab - anfangen, ernsthaft darüber nachzudenken, ob das wirklich so bleiben muss. Irgendwo auf der Welt deployt gerade ein AI Agent eine komplette Microservices-Architektur und ich mappe AUFTRAGSDAT auf ORDER_DATE.

Also fange ich an zu suchen. Denn das kann doch nicht sein: Da redet die ganze Branche über Agentic AI, SAP arbeitet mit Joule an einer eigenen Vision, die aber vor allem in der Cloud läuft, für SAP-Partner keine attraktiven Einstiegsangebote hat und bei der wie immer vieles mehr Ankündigung als Realität ist - und für BW-Entwickler ändert sich: nichts.

Beim Recherchieren stolpere ich über eine MCP-Server-Liste von Marian Zeis auf GitHub, die sich ausschließlich mit SAP-Tooling beschäftigt. Jackpot - sowas gibt es schon? Und dann, beim Durchscrollen: ein MCP Server für ABAP. Derselbe Stack, auf dem BW läuft. Doppelter Jackpot.

Ich probiere es aus. Erste Minute: geflasht. Das Ding funktioniert wirklich. AI, die direkt über dieselbe Schnittstelle ins SAP-System schreibt wie Eclipse ADT selbst - kein Umweg, kein Screenshot, kein Copy-Paste.

Ein paar Wochen später: DSAG Technologietage in Hamburg. Marians Vortrag über KI-gestützte SAP-Entwicklung mit MCP-Servern. Der Saal ist proppevoll, was schon allein zeigt, wie groß das Interesse ist. Keine Joule-Demo, kein AI Units-Pricing. Stattdessen: Open Source Mindset und eine Live-Demo, die End-to-End zeigt, wie sich die Rolle des Entwicklers gerade verschiebt.

Auf der Heimfahrt von Hamburg denke ich: Moment mal. ADT API. Das gibt es doch auch für die BW Modeling Tools. Und so wurde aus einer Inspiration noch am selben Abend ein Projekt: bw-modeling-mcp.

Link zum Github repository: https://github.com/dnic-dev/bw-modeling-mcp 

Was ist MCP?

Ein reines AI-Modell hat keinen direkten Zugriff auf externe Systeme. Es verarbeitet Eingaben und generiert Ausgaben, mehr nicht. Erst eine agentic Umgebung wie Claude Code, OpenAI Codex oder Gemini CLI gibt dem Modell Tools: Bash, HTTP, Dateisystem.

Aber selbst damit kommt man bei SAP BW nicht weit. Denn die BW Modeling REST API ist nicht öffentlich dokumentiert. Sie ist die interne Schnittstelle die Eclipse BWMT selbst verwendet und nie öffentlich dokumentiert oder als offizielle Schnittstelle bereitgestellt hat. Claude weiß schlicht nicht, welche Endpoints es gibt, welche XML-Strukturen erwartet werden, wie das Lock-Protokoll  und interne Session-Handling funktioniert. Dieses Wissen steckt im MCP Server: reverse-engineered aus Eclipse BWMT, sauber in Tool-Implementierungen gekapselt und damit für jedes MCP-fähige AI-Tool nutzbar.

Genau das macht Model Context Protocol zum richtigen Ansatz: ein offener Standard, ursprünglich von Anthropic entwickelt, der AI-Modellen ermöglicht, strukturiert externe Systeme anzusprechen und echte Operationen auszuführen. Das Modell entscheidet selbstständig, wann es welches Tool braucht, das Tool führt die Operation aus, das Ergebnis fließt zurück ins Modell  und es arbeitet weiter, bis die Aufgabe erledigt ist.

Bei bw-modeling-mcp bedeutet das konkret: Der Server verbindet sich mit der BW Modeling REST API (/sap/bw/modeling/), jede Schreiboperation folgt dem BW-Locking-Protokoll - Lock, aktuelles Objekt-XML lesen, Änderungen anwenden, vollständiges XML zurückschreiben, aktivieren. Was in Eclipse ein Entwickler Klick für Klick macht, führt Claude hier per Prompt beschrieben und ohne manuelle Zwischenschritte aus.

Wo das Potenzial wirklich liegt

Von Anfang an war klar, dass der Server zwei grundlegende Anwendungsfelder bedienen soll:

• Read-only: Bestehende BW-Strukturen auslesen, analysieren, verstehen

• Write: Objekte anlegen, modifizieren, aktivieren - vollständig agentic

Die Möglichkeiten, die sich daraus ergeben, sind vielfältig. In diesem Beitrag greifen wir ein paar typische Beispiele auf, um schnell verständlich zu machen, was der Server kann und wie er funktioniert.

as Potenzial geht jedoch weit über das hinaus, was auf den ersten Blick offensichtlich ist. BW-Systeme enthalten jahrelang gewachsenes Wissen - Modellierungsentscheidungen, komplexe Business-Logik tief verschachtelt in Transformationslogiken und Query-Definitionen. Ein AI-Assistent, der direkt darin lesen und navigieren kann, eröffnet völlig neue Perspektiven: für die Analyse bestehender Strukturen, aber auch für die Überführung in moderne Datenplattformen - einer, der die Semantik hinter gewachsenen BW-Strukturen versteht und daraus eigenständig einen Zielzustand ableiten kann, der zur neuen Plattform passt.

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

Das BW fragen

Starten wir mit dem ersten Anwendungsfall: Bestehende BW-Strukturen auslesen, analysieren, verstehen.

Man kann dem MCP einfache Fragen stellen, zum Beispiel: Gib mir alle Custom-Queries im System mit Ersteller, InfoProvider und Erstell- und Änderungsdatum. In einem produktiven System würde man das je nach Rolle und Kontext enger fassen. Ein IT-Administrator fragt vielleicht nach Queries die nicht den Namenskonventionen entsprechen oder seit über einem Jahr nicht mehr angefasst wurden. Ein Entwickler interessiert sich eher dafür welche Queries auf einem bestimmten InfoProvider laufen, gerade wenn ein Umbau geplant ist. Und der Fachbereich fragt ggf. ganz anders: erkläre mir was Query X genau macht, welche Kennzahlen sie enthält und welche Variablen den Filter steuern. Auf unserem Demo-BW/4HANA System fragen wir einfach alle Custom-Queries ab, zugegeben auf einem System, auf dem schon etwas länger keine neue Query mehr entwickelt wurde.

Das Ergebnis: 28 Queries, sauber tabellarisch aufbereitet mit allen relevanten Kopfdaten, ergänzt um eine kleine zusammenfassende Analyse. Das Video ist nur minimal geschnitten, an den Stellen wo das Modell überlegt. Was nicht geschnitten ist: die eigentlichen Tool-Aufrufe. Die sind so schnell wie sie aussehen.

Ein weiteres Beispiel das zeigt, was mit Read-Only wirklich möglich ist, ist eine vollständige technische und fachliche Datenherkunftsanalyse. Das Datenmodell, das wir dabei unter die Lupe nehmen, ist unser NextJuice-Modell, das einige vielleicht aus unserem Seamless Planning Blog kennen. Ursprünglich lag es ausschließlich in der Datasphere, für diesen Einsatzzweck haben wir es ins BW gezogen, aufgebaut über den MCP-Server selbst.

Die Analyse selbst ist bewusst ambitioniert formuliert. Ich will nicht nur wissen, wie das Modell aufgebaut ist, sondern auch, was die Transformationen und Routinen technisch und fachlich tun. Das ist ein Unterschied, der wichtig ist: die Struktur abzulesen ist das eine, aber erst die Erklärung der Business-Logik macht aus der technischen Analyse eine verwertbare Dokumentation. Der Prompt dazu:

Was dabei passiert, lohnt sich im Detail anzusehen: Claude durchläuft selbstständig die gesamte Abhängigkeitskette, Schritt für Schritt: aDSO auslesen, Where-Used-Analyse auf das Objekt, rückwärts durch die Transformationen, die jeweiligen Quell-Objekte holen. Und sobald es an die Routinen-Codings geht, wechselt Claude von selbst auf den ADT MCP Server und liest den Source Code dort aus. Das ist der gleiche Wechsel den ein Entwickler in Eclipse auch macht, wenn er aus den BW Modeling Tools heraus in die ABAP Development Tools springt, um sich ein Routinen-Coding anzusehen. Nur dass Claude hier nicht die Perspektive wechselt, sondern das richtige Tool aus einem anderen MCP Server anzieht. In meinem Setup ist das vibing-steampunk.

Auch dieses Video ist nur an den Stellen geschnitten, an denen die AI selbst im Denkprozess ist, nicht bei den Tool-Aufrufen. Das Ergebnis ist so ausführlich, dass wir die vollständige Data-Lineage-Analyse als PDF angehängt haben: hier pdf Datei herunterladen.

Das BW modellieren

Auslesen ist die eine Hälfte, aber die eigentlich spannende Frage ist natürlich: kann Claude auch Objekte anlegen, Transformationen bauen, Daten laden? Die Antwort ist: Ja, kann er.
Und um das zu zeigen, nehme ich diesmal bewusst nicht wieder unser NextJuice-Modell, sondern ein Beispiel direkt aus dem echten Leben - tatsächlich die spontane Idee eines Kollegen für seinen allerersten MCP-Prompt. Genau so fängt man also an. Ob man für Bundesliga-Auswertungen wirklich ein SAP BW/4HANA braucht, sei mal dahingestellt - aber als Demo hat es definitiv Charme.

Create a field-based aDSO [NJBULI] with write-interface (Type standard) to store Bundesliga match results in the InfoArea [MCPBW_01]. Include fields for matchday,home team, away team, home goals, away goals, and match date. Use NUMC(2) for matchday so it can serve as a key field. Use aggregation type NONE for all numeric fields. Define matchday, home team, and away team as key fields. Suggest suitable technical names for the fields. Then load the aDSO with a sample dataset of around 30 plausible matches via the Push API.

Was an diesem Beispiel schön ist: es zeigt in einem einzigen Durchlauf drei verschiedene Dinge. Erstens die Modellierung, bei der Claude ein Write-Interface aDSO vom Typ Standard in der richtigen InfoArea anlegt, mit den im Prompt vorgegebenen Eckdaten wie Aggregationsart und Schlüsselfeldern. Zweitens die Feldstruktur, die aus einer fachlichen Beschreibung ("matchday, home team, away team, home goals, away goals, match date") in konkrete BW-Felder mit passenden Datentypen und Längen übersetzt wird, inklusive sinnvoller technischer Feldnamen die Claude selbst vorschlägt. Und drittens das Laden der Daten über die Push API, über die man per REST-Schnittstelle Datensätze direkt ins aDSO schreiben kann. Claude generiert dafür einen plausiblen Datensatz von 30 Spielen und schreibt ihn in einem Rutsch als JSON-Records ins System. Dass Bayern München dabei wieder ziemlich gut dasteht, war zu erwarten - da hätte ich mir ehrlich gesagt etwas mehr Halluzination gewünscht.

Was man im Video außerdem sieht: vor jedem schreibenden Tool-Aufruf fragt Claude Code nach, ob es den Aufruf tatsächlich ausführen darf. Das ist kein Zufall, sondern bewusst so eingestellt. In meinem Setup laufen alle lesenden Tools ohne Rückfrage durch, weil sie nichts verändern. Bei schreibenden Operationen wie dem Anlegen eines aDSO oder dem Push ins System muss ich aktiv bestätigen. So bleibt die Kontrolle beim Entwickler, ohne dass man sich durch jedes harmlose Lese-Tool durchklicken muss.

Das Beispiel deckt nur einen Bruchteil dessen ab, was der MCP aktuell kann. Ein Blick auf die weiteren Funktionen:

• InfoObjects: Merkmale und Kennzahlen anlegen mit allen gängigen Datentypen, Stammdaten- und Textunterstützung, Anzeige- und Navigationsattribute verwalten

• aDSOs: Felder und InfoObjekte hinzufügen und entfernen, Schlüsselfelder verwalten, Feldeigenschaften wie Aggregationsverhalten anpassen, aDSO-Typen und Einstellungen ändern

• InfoAreas: anlegen und Objekte zwischen InfoAreas verschieben

• InfoSources: anlegen, Felder verwalten, aus bestehenden Objekten übernehmen

• Transformationen: anlegen zwischen allen gängigen Quell- und Zieltypen, Feld-Mappings als Direct-Mapping oder Formel setzen, Start-, End- und Feldroutinen in ABAP oder AMDP hinzufügen, Runtime zwischen ABAP und AMDP umschalten

• DTPs: anlegen, Filter und Filter-Routinen setzen, Beschreibung und Einstellungen pflegen

• BW Queries (read-only): vollständige Auflösung von Variablen, Filtern, Layout, berechneten und eingeschränkten Kennzahlen inklusive rekursiv aufgelöster CKF-Formeln, sowie Exceptions und Query-Einstellungen

• Allgemein: Suche und Where-Used-Analyse, Aktivierung, Sperren freigeben, Objekte löschen, Transportauftrags-Zuordnung

Und wenn es an ABAP- oder AMDP-Coding für Routinen geht, bleibt der BW MCP bei seiner Rolle und überlässt das Schreiben des eigentlichen Quellcodes einem ADT MCP Server. Die beiden arbeiten Hand in Hand, so wie auch in Eclipse die BW Modeling Tools und die ABAP Development Tools nebeneinander laufen. Eine vollständige Übersicht aller Tools findet sich in der README des Projekts.

Selbst ausprobieren

Das Setup ist überraschend unspektakulär. Was es braucht, sind drei Dinge: eine MCP-fähige agentic Umgebung, ein BW/4HANA-System und ein paar Minuten Zeit.

In meinem Setup nutze ich Claude Code, alternativ funktioniert der Server genauso mit anderen MCP-kompatiblen Clients. Das Grundprinzip ist bei allen Clients dasselbe, die konkrete Konfiguration aber unterschiedlich. Für Claude Code sind es im Wesentlichen drei Schritte: das Repository von GitHub klonen, mit npm install und npm run build einmal bauen, und in der .mcp.json im Projektverzeichnis den Server samt BW-Zugangsdaten eintragen. Die vollständige Anleitung inklusive Beispiel-Konfiguration steht in der README des Projekts.

Wo Claude Code läuft, ist Geschmackssache. Ich nutze die native Integration in VS Code, genauso gut funktioniert aber eine normale PowerShell, das integrierte Terminal in VS Code oder auch eine Terminal-Ansicht in Eclipse.

Und damit zu der Frage, die an dieser Stelle oft kommt: Muss ich dafür irgendwo einen Server aufsetzen? Nein. Der Begriff "MCP Server" ist hier missverständlich, denn trotz des Namens handelt es sich nicht um einen Server im klassischen Sinne. Der MCP ist ein lokales Node.js-Skript, das die agentic Umgebung beim Start mitstartet und das nur so lange läuft wie die Sitzung aktiv ist. Der MCP-Server spricht vom lokalen Rechner aus mit der REST-API des BW-Systems, genau wie es Eclipse BWMT auch tut.

Agentic AI meets SAP BW: Unser Fazit und wie es weitergeht

Was bisher zu sehen war, ist erst der Anfang. Der MCP deckt schon einen großen Teil der typischen BW-Entwicklungs- und Analyse-Szenarien ab und an neuen Features wird kontinuierlich gearbeitet. Das Query-Lese-Tool etwa ist erst vor wenigen Tagen dazu gekommen, nach meiner Bekanntmachung auf LinkedIn letzte Woche. Und der Server ist inzwischen auch in der kuratierten Liste von Marian Zeis gelandet - derselben Liste, über die ich vor wenigen Monaten selbst auf das Thema gestoßen bin. Auf der Roadmap stehen als nächstes unter anderem CompositeProvider, Planungsobjekte, eine Kompatibilität mit BW on HANA 7.5 und Launchpad-Funktionen wie Prozessketten.

Ein Muster, das sich dabei wahrscheinlich fortsetzen wird: neue Objekttypen kommen meistens zuerst im Read-Modus dazu. Das hat einen einfachen Grund. Lesen ist vergleichsweise geradlinig, Create, Update und Modify dagegen deutlich komplexer, weil BW intern mit Locking, Session-Handling, Transporten und vielen kleinen API-Besonderheiten arbeitet, die erst sauber gekapselt werden müssen, bevor eine schreibende Operation wirklich stabil ist. Das bedeutet aber nicht, dass es dabei bleibt. Der Anspruch ist, den MCP Schritt für Schritt zu einem Werkzeug zu machen, das ein BW-System vollumfänglich verstehen und auch darin arbeiten kann.

Daneben stellen sich weitere Fragen, die wir spannend finden und sicher noch vertiefen werden: Wie viel Tokens "verbraucht" eine typische BW-Operation, wie ist die allgemeine Performance und welche Rolle spielt Prompting dabei, also welche Formulierungen liefern die besten Ergebnisse bei möglichst geringem Ressourceneinsatz? Wie gut funktioniert der MCP-Server mit anderen AI-Plattformen wie OpenAI Codex oder Microsoft Copilot Studio, oder mit modell-agnostischen Tools wie OpenCode, die zusätzlich auch lokale Modelle unterstützen. Und natürlich: Welche sicherheitsbezogenen Fragen stellen sich, wenn AI-Assistenten agentic in Systemen mit kritischen Datenmodellen arbeiten - etwa im HR-Reporting? Das sind keine akademischen Fragen, sie entscheiden am Ende darüber, ob aus einem spannenden Ansatz ein produktives Werkzeug wird.

Interessiert an der Optimierung Ihres BW-Systems oder benötigen Sie Unterstützung bei der Implementierung? Kontaktieren Sie uns noch heute für eine persönliche Beratung und erfahren Sie, wie unsere Lösungen Ihre SAP BW/4HANA-Umgebung transformieren können.