Back in April, I introduced the bw-modeling-mcp here—an open-source MCP server that allows AI assistants to work directly within SAP BW/4HANA. The server was already capable of a lot back then. What it lacked was real-world validation. We had tested it exclusively against our own demo systems. There was still no experience from actual customer environments.
Three months later, my day-to-day work in BW looks different than ever before. The server is in daily use in two customer projects, covers the entire BW/4HANA lifecycle, and can now also be operated centrally on SAP BTP. And it doesn’t stop with BW. For SAP Datasphere, we’re currently developing our own plugin that derives the appropriate Datasphere models from the data the MCP server reads in BW and creates them immediately. You can see for yourself what this looks like at the very bottom of this post, in an interactive lineage analysis from this very plugin.
In this post, I’ll walk you through all of this step by step, from the server itself to centralized deployment to the two customer projects. As always, you can find the MCP server in the GitHub repository: https://github.com/dnic-dev/bw-modeling-mcp.
Check out our blog series "Agentic AI meets SAP BW": |
|
| 1. Agentic AI meets SAP BW | |
| 2. Agentic AI in Practice |
Three dimensions define the MCP Server. Only together do they form a tool you can actually work with, rather than just experiment with.
Understanding. The agent reads not just objects, but relationships. Search, where-used analysis, data flow lineage across all levels - every object type down to the routine level, including planning models. Plus live data via BICS and the DataSource preview. This allows the agent to autonomously trace back through load chains of any depth, from the query all the way to the source system.
Building. Everything that occurs in day-to-day modeling: InfoObjects and InfoAreas, aDSOs, DataSources and InfoSources, transformations with ABAP and AMDP routines, DTPs, queries, and process chains. Create, modify, activate, assign packages, transport. The result is not a suggestion in the chat window, but an activated object on the transport request. Created via the same REST API and using the same locking protocol that Eclipse BWMT uses.
Operations. Execute DTPs, activate requests, load data via the Push API, start and monitor process chains, and analyze load runs by status, errors, and history. Only then is the circle complete: What the agent builds, it can also load, check, and analyze in greater depth in the event of an error.
Until now, the MCP server could only be run locally. Local mode is designed for individual developers. A Node.js process on your own computer, with access credentials stored in a local configuration file. This is perfect for testing. But it’s no longer sufficient for an entire development team with the same requirements. It lacks a central location for operation, a shared login, and the ability for IT to control who has access to what.
Version 1.2 closes this very gap. The server can now run either locally or centrally as an HTTP service on SAP BTP Cloud Foundry. Login is handled via XSUAA, the BTP authentication service that the company uses anyway. Behind the scenes, a BTP destination connects to BW via the Cloud Connector. The MCP client only needs the URL; the rest is handled by the browser login. This was made possible by the groundwork laid by Marian Zeis. He had already extracted the XSUAA authentication mechanism for his ABAP MCP server ARC-1 as a standalone package and contributed it as a completed pull request. bw-modeling-mcp now builds on this same foundation.
A direct comparison illustrates what this means in practice:
| Scenario | Before | After |
| One developer, one BW | local process on their machine | central service, login with their own identity |
| Multiple users, one server | not possible, no central authentication |
all via BTP, each identity flows through to BW |
| Tool permissions | whoever starts the server may use every tool | granted per role, independent of the BW authorization concept |
| BW authorizations | enforced via the user's own credentials | enforced unchanged, every call in the name of the real user |
| Traceability | limited | XSUAA logs every login, BW sees the real user |
The server provides two roles as suggestions: one with the reading tools (BW MCP Reader) and one with the full toolbox (BW MCP Developer). Not only are write tools denied to a Reader, but they also disappear from the tool list; the AI therefore does not even suggest an unauthorized call in the first place. Underneath this, BW continues to apply its own authorizations via Principal Propagation. The MCP role is the first gate; the BW authorization is the second.
The first example comes from a customer project in which a large-scale platform migration is currently ongoing. A regional energy supplier is replacing its SAP IS-U environment - which has evolved over decades - and migrating its utilities billing to S/4HANA for Utilities, which is centrally operated by a service provider. The underlying BW/4HANA remains in place, but the source system beneath it is being completely replaced. This also means the old customer exit logic is gone, since there is no longer any room for customer-specific enrichment in the source system under standardized operations. The new loading path simply no longer provides the data that BW has been obtaining from these exits for years.
Closing this gap is a painstaking task, and that’s exactly what the agent tackles. It runs through the entire process itself - from discovery to production loading - using the BW-MCP for modeling and the ABAP-MCP for reading the legacy logic.
“Automatic” here does not mean “unsupervised.” At critical points, the agent initially paused and output clear, readable interim results, which we could use to verify that everything was functioning correctly up to that point. Only then did it continue.
This is because these are not individual object requests, but multi-step, complex workflows that would take consultants weeks to complete manually. For the AI to run through them reliably, they must be specified just as precisely. We store both in a knowledge repository: the contextual knowledge about the landscape and the workflows as robust runbooks - essentially a directory of Markdown files that each new run draws upon.
The second example from an ongoing project is also a migration; this time, however, it is not the source system but the target system that is changing. The models should be migrated from the SAP BW Bridge to SAP Datasphere. The goal here is to create a clean, redesigned model on the target platform, rather than a 1:1 mapping of logic and persistence objects. Before this can be built, however, one must have a complete understanding of what the legacy BW model actually does today.
This understanding is again provided by the combination of BW-MCP and ABAP-MCP. The agent reads the model end-to-end and reveals all the complexity that has accumulated over the years: transformation logic with ABAP routines at multiple levels, lookups to additional tables with their own lineage, and Customizing tables. This results in a complete lineage within BW, plus a second one on the Datasphere side that shows what already exists there. Both can be combined into a comprehensive picture.
The crucial intermediate step is to translate this technical logic into a language that the business department can understand. The agent extracts the custom logic and describes it in business terms. Only then can we verify whether a rule still applies today or whether the business department has a delta that should be incorporated immediately. After all, the goal is not to migrate the old state 1:1, but rather the understood and refined version. Based on this verified understanding, the AI derives a clean, SQL-based concept for Datasphere, initially as a draft. From this, our own Datasphere plugin creates the models and puts them into operation via replication flows and task chains.
For Datasphere, we’re working on our own plugin, which we’re developing during this project. While there are already several open-source MCP servers, they rely almost exclusively on the OData Consumption API; as a result, they only see the published models and not the underlying remote tables, and are primarily read-only. There are skills based on the Datasphere CLI for creating objects. However, this is still not enough for reliable automation - manual intervention is required too often - and, most importantly, it lacks what makes a model stable in the first place: our modeling standards. Our plugin provides exactly that - best practices from numerous projects, fixed naming conventions, and the implications of an object change for dependent objects, all neatly encapsulated in skill descriptions. This ensures that every new model integrates into the existing landscape rather than standing alone as an island.
The AI itself requires only Markdown files to orchestrate this workflow. However, whoever is responsible for the model wants to be involved in the decision-making process, make their own adjustments, and truly understand what’s happening. That’s why our Datasphere plugin also generates a lineage analysis that can be linked to the one from BW and shows the complexity of an evolved model at a glance. You can click through the example below to see what this looks like — specifically, a demo model from our own system. Using the Details panel, you can display complete information for each step, from the fields to the routine logic. The legend can be toggled interactively, and in the header, you can choose whether to display Datasphere associations or, in the BW section, lookup objects from transformations and virtual objects.
The BW-MCP server now includes 85 tools covering the entire BW/4HANA lifecycle. This breadth wasn’t conceived on the drawing board, but rather because these two projects pushed the server to its limits week after week - and each limit often meant a new tool. The sheer number of tools has now become an issue in itself; the next step is to consolidate them into fewer, but more broadly configurable, tools.
However, it is not the tools alone that determine whether agent-based workflows are suitable for everyday use, but rather the context - that is, everything the AI knows about the system before the first task is specified. An agent that is expected to work confidently within a mature customer system needs this knowledge to be permanently available, not re-explained for every task. We organize this as a versioned knowledge repository, based on the Open Knowledge Format - a relatively new, open standard from Google for AI-readable knowledge bases.
How to quickly set up such a repository, keep it up to date, and clearly define its scope is a major topic in its own right, which we’d like to explore in more depth in our next post.
Would you like to find out exactly what Agentic AI can do in your SAP data landscape? Contact us - we’ll guide you from the initial secure environment all the way to day-to-day agent-based operations.