Agentic AI für SAP BW

Über die BICS Schnittstelle arbeitet der Agent auch direkt mit den Daten selbst. Er führt Queries aus oder fragt einen InfoProvider ab, mit Variablen, Filtern und Navigation durch Hierarchien, und zwar auch dann, wenn dafür noch gar keine Query existiert. Man stellt Fragen wie 

„Zeig mir die fünf umsatzstärksten Produkte je Monat", 

der Agent sucht den passenden Provider, versteht das Datenmodell, aggregiert und liefert das Ergebnis direkt im Chat zurück. Für Fachanwender gibt es dafür im zentralen Betrieb eine eigene Rolle mit einem bewusst kleinen Werkzeugkasten, der nur das Abfragen und Verstehen der Daten enthält und die Modellierung außen vor lässt.

Technisch übersetzt der Server die Aufrufe des Agenten in Requests an vier SAP Schnittstellen, die BW Modeling REST API für Objekte, Queries und Livedaten, die ADT API für die ABAP und AMDP Routinen, die das BW selbst generiert, die Manage API für Request Monitor und Laufzeit und die Push API für Beladungen. Damit bewegt sich der Agent auf genau den Wegen ins System, die SAP für die Modellierung vorgesehen hat. Was ein Entwickler in Eclipse Klick für Klick erledigt, formuliert der Agent als Prompt. Es gibt keinen zweiten, selbstgebauten Zugang ins System.

Beim Schreiben folgt er dem Sperrprotokoll des BW. Er sperrt das Objekt, liest dessen aktuelles XML, wendet die Änderung an, schreibt alles vollständig zurück, aktiviert und entsperrt wieder, also genau die Mechanik, mit der auch Eclipse arbeitet. Dabei greifen dieselben Prüfungen von Syntax und Aktivierung wie im Standard, sodass am Ende ein sauber aktiviertes und konsistentes Objekt steht. Jede Änderung landet auf einem Transportauftrag und wandert über den gewohnten Transportweg durch die Systemlandschaft bis nach Q und P.

Der Server ist Open Source unter MIT Lizenz, in TypeScript geschrieben und über npm installierbar. Entwickelt wird offen auf GitHub, sodass jede Codezeile einsehbar ist und man jederzeit nachvollziehen kann, was im eigenen System passiert.

Den Server kann man auf zwei Arten betreiben und beide sind gleichwertig gedacht.

Lokal startet die agentische Umgebung wie Claude Code den Server als Node.js Prozess auf dem Rechner des Entwicklers, die Zugangsdaten liegen in einer lokalen Konfigurationsdatei. Das ist der schnellste Weg, wenn eine einzelne Person loslegen will. Trotz des Namens ist der Server in diesem Fall kein dauerhaft laufender Dienst, sondern ein Programm, das nur während der Arbeitssitzung aktiv ist. Zum echten Dienst wird er erst zentral.

Zentral läuft derselbe Server als HTTP Dienst auf SAP BTP Cloud Foundry. Die Anmeldung übernimmt XSUAA, der Authentifizierungsdienst der BTP, den ein Unternehmen ohnehin schon nutzt, und dahinter führt eine BTP Destination über den Cloud Connector ins BW. Der Client braucht nur die URL, um den Rest kümmert sich der Login im Browser. So arbeiten mehrere Leute mit einem gemeinsamen Dienst, ohne dass jemand lokal etwas installieren muss.

Im zentralen Betrieb bringt der Server drei Rollen als Vorschlag mit. Der BW MCP Analyst bekommt nur, was zum Abfragen und Verstehen der Daten nötig ist, der BW MCP Reader alle lesenden Werkzeuge, der BW MCP Developer den vollen Werkzeugkasten. Einem Reader werden die schreibenden Werkzeuge nicht bloß verweigert, sie tauchen in seiner Werkzeugliste gar nicht erst auf, sodass die KI einen unerlaubten Aufruf nicht einmal vorschlagen kann. Darunter greift dann immer noch das BW selbst. Über Principal Propagation arbeitet jeder im Namen seines echten Nutzers mit dessen eigenen Berechtigungen, nicht über einen geteilten technischen Sammelnutzer, und XSUAA schreibt jeden Login mit. Die MCP Rolle ist das erste Tor und die BW Berechtigung das zweite.
Möglich wurde das durch die Vorarbeit von Marian Zeis. Er hatte den XSUAA Mechanismus für seinen eigenen ABAP MCP Server ARC-1 schon als eigenständiges Paket herausgelöst, und genau darauf setzt der BW Modeling MCP Server auf.

Richtig stark wird der Server im Zusammenspiel mit einem ABAP MCP Server wie ARC-1. Für Logik in ABAP und SQLScript arbeiten beide Hand in Hand, also genau die Arbeitsteilung, die man aus Eclipse zwischen den BW Modeling Tools und den ABAP Development Tools kennt. Wie viel das bringt, zeigt ein reales Beispiel.

Ein Energieversorger löst seine über Jahre gewachsene SAP IS U Umgebung ab und stellt die Abrechnung auf S/4HANA for Utilities um. Das BW/4HANA dahinter bleibt, die Quelle darunter wird komplett ausgetauscht. Damit fällt die gesamte Anreicherung weg, die früher über Customer Exits im Quellsystem steckte, und genau die fehlt später in den Auswertungen.

Hier spielen die beiden Server ihre Stärke aus. Zuerst bindet der Agent über den BW MCP Server die DataSources aus dem neuen System an die bestehenden Provider an und mappt die Standardfelder. Dann folgt die Gap Analyse. Für jedes fehlende Feld liest er über den ABAP MCP Server direkt im Altsystem nach, aus welcher Tabelle es stammt und welche ABAP Logik es einst abgeleitet hat. Für den Nachbau bindet er je Lookup Tabelle eine CDS basierte DataSource an, baut das Staging auf und gießt die alte Logik in eine AMDP Routine auf dem neuen Fundament. Zur Inbetriebnahme erweitert er die Ladeschritte und Prozessketten, startet die Testbeladung und prüft die Ergebnisse direkt im System.