SAP ECC MCP-Server: KI-Agenten an ECC 6.0 anbinden

Was ist ein MCP-Server für SAP ECC?

Ein MCP-Server für SAP ECC stellt ausgewählte Funktionen Ihres ECC-6.0-Systems als fest definierte Werkzeuge für KI-Assistenten bereit, etwa „Auftragsstatus lesen“ oder „offene Posten eines Kunden anzeigen“. Der KI-Assistent spricht das offene Model Context Protocol, der Server übersetzt jeden Werkzeugaufruf in einen Aufruf einer ECC-Schnittstelle: einen OData-Service über SAP Gateway, einen BAPI per RFC oder einen eigenen Funktionsbaustein.

Technisch ist das bei ECC gut machbar. Die eigentliche Arbeit liegt an anderer Stelle: Welche Schnittstellen darf ein KI-Agent nach der SAP API Policy überhaupt nutzen, wie bleiben die Rechte des einzelnen Nutzers erhalten, und wie baut man so, dass die Investition die Migration nach S/4HANA übersteht? Genau darum geht es auf dieser Seite. Die Grundlagen zu SAP und MCP allgemein stehen im Ratgeber MCP-Server für SAP, der Vergleich mit anderen ERP-Systemen unter MCP-Server für ERP-Systeme.

• SAP ERP 6.0 / ECC
• OData über SAP Gateway
• BAPI und RFC
• IDocs
• Z-Entwicklungen

Welche Schnittstellen bietet SAP ECC 6.0 für KI-Agenten?

ECC 6.0 bietet vier Wege, über die ein MCP-Server Daten lesen oder Vorgänge anstoßen kann: OData-Services über SAP Gateway, BAPIs und andere RFC-fähige Funktionsbausteine, IDocs für den asynchronen Belegaustausch und kundeneigene Z-Schnittstellen. Für KI-Agenten eignen sie sich sehr unterschiedlich.

OData über SAP Gateway. SAP Gateway macht ABAP-Funktionen als REST-artige OData-Services verfügbar. Ab SAP NetWeaver 7.40 ist die Gateway-Komponente SAP_GWFND laut SAP im Standard enthalten und bündelt den Umfang der früheren Add-ons IW_FND, GW_CORE und IW_BEP. SAP unterscheidet zwei Aufstellungen: eingebettet im ECC-System oder als zentraler Hub, der auch in einer DMZ stehen kann und Angriffe vom Backend fernhält (SAP Help: Deployment Options). Für MCP-Werkzeuge ist OData der angenehmste Andockpunkt: HTTP, JSON, sauber filterbar, gut mit Gateways und API-Management zu kombinieren.

BAPI und RFC. BAPIs sind die klassischen, von SAP für die Nutzung von außen vorgesehenen Methoden an Geschäftsobjekten, aufrufbar per RFC. Viele ECC-Prozesse sind nur hier mit ihrer Prüflogik erreichbar. Für einen MCP-Server heißt das: Er braucht eine RFC-Bibliothek und eine Netzverbindung zum Gateway-Port des SAP-Systems, oder ein BAPI wird über einen OData-Service gekapselt, der ihn intern aufruft.

IDocs. IDocs transportieren Belege asynchron zwischen Systemen, etwa Bestellungen oder Lieferavise. Für dialogische KI-Fragen („Wo steht Auftrag 4711?“) passen sie nicht, weil keine direkte Antwort zurückkommt. Sinnvoll sind sie dort, wo ein Agent einen Vorgang vorbereitet, ein Mensch ihn freigibt und dann ein IDoc den Beleg auf dem gewohnten Weg ins System bringt.

Z-Entwicklungen. Eigene OData-Services, Funktionsbausteine und CDS-Views im Kundennamensraum gibt es in fast jedem ECC-System. Sie sind oft der einzige Weg zu Logik, die nur in Ihrem System existiert. Was die SAP API Policy dazu sagt, steht weiter unten.

Unsere Faustregel: Ein Werkzeug, ein Geschäftsvorgang, eine Schnittstelle. Werkzeuge wie „frag OData“ oder „lies Tabelle X“ sehen flexibel aus, machen aber genau das, was SAP in der API Policy einschränkt, und lassen sich gegenüber Revision und Betriebsrat kaum erklären.

Wie lange wird SAP ECC noch gewartet, und was heißt das für KI-Projekte?

SAP hat am 4. Februar 2020 angekündigt, die Kernanwendungen der SAP Business Suite 7, zu denen SAP ERP 6.0 gehört, bis Ende 2027 in der Mainstream-Wartung zu halten. Danach ist eine optionale erweiterte Wartung von Anfang 2028 bis Ende 2030 gegen Aufpreis möglich, wer sie nicht wählt, wechselt in die kundenspezifische Wartung (SAP News, 04.02.2020).

Für Unternehmen mit sehr komplexen Landschaften hat SAP am 4. Februar 2025 zusätzlich die „SAP ERP, private edition, transition option“ angekündigt: ein Cloud-Abonnement im Rahmen von RISE with SAP, nutzbar von 2031 bis 2033, unter der Bedingung, dass die Systeme vor Ende 2030 in die SAP ERP, private edition umgezogen sind und auf SAP HANA laufen (SAP News, 04.02.2025).

Was das für ein KI-Projekt auf ECC bedeutet: Ein MCP-Server auf ECC lohnt sich, wenn er den Nutzen jetzt bringt und die Arbeit nicht mit dem ECC-System verschwindet. Deshalb investieren wir bei ECC wenig in systemspezifische Tiefe und viel in eine saubere Werkzeugschicht: fachlich benannte Werkzeuge, klare Ein- und Ausgaben, Berechtigungs- und Protokollkonzept. Diese Schicht bleibt, nur die Adapter darunter wechseln (siehe Migration).

Was sagt die SAP API Policy zu ECC und eigenen Z-Schnittstellen?

Die SAP API Policy gilt auch für ECC: Laut SAP-FAQ ist sie Teil der Dokumentation aller Cloud-Lösungen und des gesamten On-Premise-Portfolios (FAQ, Frage 1). Für KI-Agenten zählt vor allem Ziffer 2.2.2, die API-Nutzung durch KI-Systeme, die Aufrufe selbst planen oder auswählen, außerhalb von SAP anerkannter Wege untersagt. Die ausführliche Einordnung mit Zitat und den anerkannten Wegen steht im Abschnitt SAP API Policy 2026 unseres SAP-Ratgebers. Hier geht es um die Fragen, die bei ECC zusätzlich aufkommen.

Published APIs auf ECC. Ziffer 1.1 der Policy versteht unter Published APIs alles, was im SAP Business Accelerator Hub steht oder in der produktspezifischen Dokumentation ausgewiesen ist. Für ECC heißt das in der Praxis: Prüfen Sie für jeden BAPI, jeden Standard-OData-Service und jeden IDoc-Typ, ob er für Ihr Release dokumentiert ist. Community-Blogs und Forenbeiträge verleihen laut FAQ (Frage 23) keinen Published-Status.

Eigene Z-Schnittstellen. Ziffer 1.2 erlaubt ausdrücklich, dass Kunden in Private-Cloud- und On-Premise-Systemen eigene ABAP-Schnittstellen nutzen. Die FAQ präzisiert das in Frage 27. Dort steht, welche Schnittstellen als „custom-developed“ gelten, und wo die Grenze verläuft:

Übersetzt: Ihre Z-Schnittstelle ist kein Problem an sich. Sie ist aber auch kein Umweg. Ein Z-OData-Service, der nur dazu dient, einem KI-Agenten außerhalb eines anerkannten Weges freien Zugriff zu geben, fällt laut FAQ genau unter die Einschränkung. Und was die Z-Schnittstelle intern aufruft, muss selbst den Regeln der Policy folgen.

Was die FAQ sonst für ECC-Landschaften festhält:

• ODP-RFC ist laut SAP Note 3255746 für Kunden- und Drittanwendungen auf ABAP-Systemen mit PI_BASIS, SAP BW oder BW/4HANA nicht zulässig (FAQ, Fragen 22 und 23). Für Datenextraktion an KI- oder Analyseplattformen ist das kein Weg.
• ADT-Schnittstellen (ABAP Development Tools) sind laut Frage 33 für Entwicklung gedacht, nicht für agentische KI-Abläufe auf Geschäftsdaten.
• Ein internes API-Inventar mit Namensraum, Schnittstellentyp, Zweck und verantwortlichem Team empfiehlt SAP für eigene Schnittstellen (Frage 28). Für ein MCP-Projekt ist das ohnehin die Arbeitsgrundlage.
• Regelbasierte Abläufe ohne LLM-Planung fallen laut Frage 40 nicht unter Ziffer 2.2.2, wohl aber unter die übrigen Regeln.

Wer baut MCP-Server für stark angepasste ECC-Systeme?

Stark angepasste ECC-Systeme brauchen ein Team, das ABAP-Eigenentwicklungen lesen kann und zugleich MCP, Berechtigungen und KI-Sicherheit beherrscht. Standardkonnektoren scheitern dort meist nicht an der Technik, sondern daran, dass die entscheidende Logik in Z-Tabellen, User-Exits und Eigenentwicklungen liegt, die kein fertiges Produkt kennt.

So gehen wir bei viel Custom Code vor:

1. Fragen sammeln, nicht Tabellen. Wir starten bei den Fragen, die Ihr Team heute per Telefon, Excel-Export oder SE16-Abzug beantwortet. Daraus entstehen die Werkzeuge.
2. Vorhandene Schnittstellen inventarisieren. Welche Standard-BAPIs und OData-Services decken die Frage ab? Welche Z-Bausteine gibt es schon, wer pflegt sie, auf welche SAP-Objekte greifen sie zu? Der Cloud Readiness Check im ABAP Test Cockpit zeigt, wo Eigenentwicklungen auf nicht freigegebene SAP-Objekte zugreifen (FAQ, Frage 30).
3. Fachlogik in ABAP kapseln, nicht im MCP-Server nachbauen. Wenn eine Kennzahl nur mit Ihrer Z-Logik richtig wird, gehört sie in einen eigenen Funktionsbaustein oder OData-Service mit festem Ein- und Ausgabeformat. Der MCP-Server ruft ihn nur auf.
4. Jede Z-Schnittstelle bekommt einen Zweck. Fachlich begründet, mit Obergrenzen und ohne generischen Zugriff. Damit bleibt sie auch nach FAQ 27 erklärbar.
5. Test im Qualitätssicherungssystem mit realistischem Datenstand und Fachbereich, bevor irgendetwas produktiv geht.

Welche Architekturwege gibt es, mit und ohne SAP BTP?

Für ECC on-premise gibt es drei tragfähige Architekturwege: über die SAP BTP mit Cloud Connector und dem MCP Gateway der Integration Suite, ohne BTP über eigene Netzkomponenten wie SAP Web Dispatcher, Azure API Management oder das On-Premises Data Gateway von Microsoft, oder regelbasiert ohne KI-Planung im Zugriff.

Zwei Dinge gehen in Gesprächen oft durcheinander. Erstens: Der Cloud Connector gehört zur BTP. Wer „ohne BTP“ sagt, braucht einen anderen Netzweg. Zweitens: Ein Netzweg allein macht noch keinen anerkannten Weg im Sinne der Policy. Azure API Management oder ein Web Dispatcher lösen Erreichbarkeit, Drosselung und Protokoll, die Policy-Frage für den MCP-Server dahinter bleiben. Die Policy untersagt in Ziffer 3 ausdrücklich, ihre Kontrollen über Zwischendienste, Proxies oder Gateways zu umgehen.

Mit wessen Rechten greift der KI-Agent auf ECC zu?

Der KI-Agent sollte mit den Rechten des Menschen zugreifen, der fragt, nicht mit einem technischen Sammelnutzer. Nur so sieht jede Person in der KI-Antwort genau das, was sie auch in ECC sehen dürfte, und nur so bleibt im Protokoll nachvollziehbar, wer was abgefragt hat.

Warum der Sammelnutzer verlockt und trotzdem falsch ist. Ein technischer RFC- oder Service-Nutzer ist schnell eingerichtet. Danach sieht jeder, der den Assistenten benutzt, alles, was dieses Konto sieht: Gehälter, Konditionen, gesperrte Lieferanten. Die Berechtigungsprüfung von ECC läuft dann ins Leere. Für reine Testsysteme mit anonymisierten Daten kann ein Sammelnutzer reichen, produktiv nicht.

Principal Propagation. Der saubere Weg heißt Principal Propagation: Die Identität des angemeldeten Nutzers wird bis zum SAP-System durchgereicht und dort einem ECC-Benutzer zugeordnet. Über die BTP übernimmt das der Cloud Connector, der die Identität per kurzlebigem X.509-Zertifikat oder Kerberos weitergibt (SAP Help: Principal Propagation). Ohne BTP verweist Microsoft für Azure API Management auf veröffentlichte Richtlinienbausteine für Principal Propagation zu SAP ECC oder S/4HANA.

Was im Server dazukommt. Das SAP Architecture Center verlangt für eigene MCP-Server einen Token-Austausch nach RFC 8693 mit Agent- und Nutzerkontext statt eines durchgereichten Nutzertokens, keine langlebigen Zugangsdaten und ein Protokoll jedes Werkzeugaufrufs (SAP Architecture Center). In ECC selbst gehören die Rollen eng geschnitten: Berechtigungen für genau die RFC-Bausteine und OData-Services, die die Werkzeuge brauchen, nicht mehr.

• Rechte des FragendenPrincipal Propagation statt Sammelnutzer, sobald echte Daten im Spiel sind.
• Eng geschnittene RollenNur die Bausteine und Services der freigegebenen Werkzeuge, keine Tabellenanzeige, keine Entwicklungsrechte.
• Lesen zuerstSchreibende Werkzeuge gibt es im Lese-Server gar nicht, nicht nur gesperrt.
• Protokoll je AufrufNutzer, Werkzeug, Parameter (personenbezogene Werte geschwärzt), Ziel-Schnittstelle, Status, Laufzeit.

Wie die Absicherung des MCP-Servers selbst aussieht, beschreibt der Ratgeber MCP-Server: Sicherheit und DSGVO. Warum SAP-Fehlertexte und Freitextfelder nicht ungefiltert ins Modell gehören, steht im Ratgeber zu Prompt-Injection.

Wie überlebt ein ECC-MCP-Server die Migration nach S/4HANA?

Ein ECC-MCP-Server überlebt die Migration, wenn seine Werkzeuge nach Geschäftsvorgängen geschnitten sind und nicht nach ECC-Schnittstellen. Der KI-Assistent kennt dann nur „Auftragsstatus lesen“ mit festen Feldern. Ob dahinter ein ECC-BAPI oder eine S/4HANA-API aus dem Business Accelerator Hub antwortet, entscheidet ein austauschbarer Adapter.

Konkret heißt das für den Aufbau:

• Stabiler Werkzeugvertrag: Name, Beschreibung, Eingaben und Ausgabefelder sind fachlich formuliert und versioniert. Das entspricht auch der Forderung des SAP Architecture Center nach versionierten Werkzeugbeschreibungen.
• Adapter je System: Pro Werkzeug ein ECC-Adapter heute, ein S/4HANA-Adapter morgen. Beide liefern dasselbe Ausgabeformat.
• Z-Logik bewusst behandeln: Was in ECC nur über Eigenentwicklung geht, kommt auf die Liste für die Migration. Der S/4HANA Simplification Item Catalog und der Bericht /SDF/RC_START_CHECK zeigen laut SAP-FAQ (Frage 10), welche genutzten Objekte in S/4HANA wegfallen oder sich ändern.
• Protokoll als Migrationshilfe: Das Aufrufprotokoll zeigt, welche Fragen Ihr Team wirklich stellt. Das ist eine belastbare Grundlage dafür, welche Auswertungen und Schnittstellen in S/4HANA zuerst stehen müssen.

So wird der MCP-Server vom Übergangsprojekt zum Teil der Migrationsplanung. Ihr Team gewöhnt sich an die Arbeitsweise mit dem KI-Assistenten, während das ERP darunter wechselt.

Wie läuft ein ECC-MCP-Projekt ab?

Ein ECC-MCP-Projekt beginnt mit der Klärung von Weg und Policy-Frage und erst danach mit Code. Wir gehen in vier Schritten vor:

1. Klären: Anwendungsfälle, vorhandene Schnittstellen, Architekturweg, Berechtigungskonzept und die Frage an Ihren SAP-Ansprechpartner, als Entscheidungsvorlage für IT, Datenschutz und Betriebsrat.
2. Ein lesender Anwendungsfall: zum Beispiel Auftrags- und Lieferstatus, im Qualitätssicherungssystem, mit Rechten des einzelnen Nutzers und Protokoll.
3. Pilot mit dem Fachbereich: echte Fragen, echte Rückmeldungen, danach Feinschliff an Werkzeugbeschreibungen und Obergrenzen.
4. Erweitern: weitere Werkzeuge, schreibende Vorgänge nur mit Freigabeschritt durch einen berechtigten Menschen.

Den Zeitplan legen wir nach dem KI-Check fest. Er hängt vor allem an Freigaben und Berechtigungen, weniger am Code.

Häufige Fragen

Gibt es einen MCP-Server für SAP ECC?

Ja, ECC 6.0 lässt sich per MCP anbinden. Der Server stellt feste Werkzeuge bereit, die OData-Services über SAP Gateway, BAPIs per RFC oder eigene Z-Schnittstellen aufrufen. SAP selbst bietet für KI-Agenten das MCP Gateway der Integration Suite als anerkannten Weg, ein eigener MCP-Server ist laut SAP-FAQ zulässig, wenn die Nutzung mit Vertrag, Dokumentation und API Policy vereinbar ist.

Braucht ECC SAP Gateway für einen MCP-Server?

Nicht zwingend. OData über SAP Gateway ist der bequemste Andockpunkt, ab SAP NetWeaver 7.40 ist die Komponente SAP_GWFND laut SAP im Standard enthalten. Alternativ ruft der MCP-Server BAPIs oder eigene Funktionsbausteine per RFC auf.

Gilt die SAP API Policy auch für ECC on-premise?

Ja. Laut SAP-FAQ ist die API Policy Teil der Dokumentation des gesamten On-Premise-Portfolios. Für KI-Agenten zählt vor allem Ziffer 2.2.2, die KI-Systeme, die API-Aufrufe selbst planen oder auswählen, auf von SAP anerkannte Wege beschränkt.

Darf ein KI-Agent unsere eigenen Z-Schnittstellen nutzen?

Eigene Schnittstellen im Kundennamensraum sind laut Policy und FAQ-Frage 27 nicht per se verboten. Was sie intern aufrufen, muss aber der Policy folgen, und sie dürfen keinen Weg für nicht anerkannte KI-Agenten oder Massenextraktion schaffen. Das ist eine Einordnung, keine Rechtsberatung.

Wie lange wird SAP ECC noch gewartet?

SAP hat 2020 Mainstream-Wartung für SAP ERP 6.0 bis Ende 2027 angekündigt, optional erweiterte Wartung von 2028 bis Ende 2030. Welche Phase für Ihr System gilt, hängt an Release, Erweiterungspaket und Vertrag, maßgeblich sind die SAP Product Availability Matrix und Ihr Wartungsvertrag.

Lohnt sich ein MCP-Server auf ECC kurz vor der S/4HANA-Migration?

Ja, wenn die Werkzeuge nach Geschäftsvorgängen geschnitten sind und nicht nach ECC-Schnittstellen. Dann bleiben Werkzeugbeschreibungen, Berechtigungskonzept und Protokoll erhalten, nur die Adapter darunter wechseln zu S/4HANA-APIs.

Brauchen wir SAP BTP für KI auf ECC?

Nein. Über die BTP laufen Cloud Connector und das MCP Gateway der Integration Suite. Ohne BTP erreicht ein eigener MCP-Server ECC etwa über SAP Web Dispatcher, Azure API Management oder das On-Premises Data Gateway von Microsoft. Die Policy-Frage für den eigenen Server bleibt dann zu klären.

Mit wessen Rechten greift der KI-Agent auf ECC zu?

Mit den Rechten der Person, die fragt. Dafür sorgt Principal Propagation, über die BTP mit dem Cloud Connector, ohne BTP etwa über Azure API Management. Ein technischer Sammelnutzer ist nur für Testsysteme mit anonymisierten Daten vertretbar.

Kann der KI-Agent in ECC auch buchen oder Aufträge anlegen?

Technisch ja, über BAPIs oder OData. Wir starten trotzdem lesend und bauen schreibende Werkzeuge erst, wenn Weg, Policy-Frage und Berechtigungen geklärt sind, und dann mit einem Freigabeschritt durch einen berechtigten Menschen.

Wer baut MCP-Server für stark angepasste ECC-Systeme?

Ein Team, das ABAP-Eigenentwicklungen lesen kann und MCP, Berechtigungen und KI-Sicherheit beherrscht. Wir kapseln kundenspezifische Logik in eigenen Funktionsbausteinen oder OData-Services mit festem Format und rufen diese aus dem MCP-Server auf.