Ein MCP-Server über Datasphere und HANA — praktisch umgesetzt
Stand 2026-09-25
Der praktische Bau hinter dem Analytics-Agenten aus M350 und den MCP-Konzepten aus M327: ein gouvernierter MCP-Server, der SAP Datasphere und SAP HANA Cloud als Agenten-Tools bereitstellt. Beginnt mit der Korrektur eines realen Risikos — SAP liefert keinen fertig gepackten Datasphere- oder HANA-MCP-Server; was als Community-Open-Source-Projekte existiert, ist nicht supportet und ungeprüft. Baut stattdessen auf dem eigenen MCP-Server-Artefakt von SAP Integration Suite auf: dessen drei Quelltypen (API, HTTP-Endpunkt mit OpenAPI, RFC), die Grenze von 30 Tools pro Artefakt, die Integration-Cell-Laufzeitanforderung und SAPs eigenes API-Komposition-zuerst-Tutorial-Muster. Behandelt den Zugriff auf Datasphere über dessen dokumentierte OData-Catalog- und Consumption-Services (dreistufiges OAuth 2.0, Standard-OData-Abfrageoptionen) sowie den direkten Zugriff auf HANA Cloud über hdbcli, wenn noch keine View existiert, und anschließend die Registrierung des Servers als MCP-fähige BTP-Destination für Joule Studio. Schließt mit der Identitätsfrage: was Principal Propagation ändert und was eine Destination mit festem technischem Nutzer nicht schützt.
Was Sie lernen
- Korrekt feststellen, dass SAP keinen fertig gepackten Datasphere- oder HANA-MCP-Server liefert, und die gouvernierte SAP-Alternative (das MCP Gateway von Integration Suite) benennen
- Für eine gegebene Datasphere-, HANA-Cloud- oder S/4HANA-Anforderung zwischen den drei Quelltypen des Integration-Suite-MCP-Gateways (API, HTTP-Endpunkt mit OpenAPI, RFC) wählen
- Ein komponiertes MCP-Tool entwerfen, das die Grenze von 30 Tools pro Artefakt und die Integration-Cell-Laufzeitanforderung einhält
- Ein MCP-Tool an die OData-Konsumtions-API von Datasphere (dreistufiges OAuth 2.0, $select/$filter/$orderby/$top/$skip) oder an HANA Cloud über hdbcli mit einer engen, parametrisierten, lesenden Fläche anbinden
- Erklären, wie die Identität des aufrufenden Nutzers je nach gewähltem Weg bis zum Backend erhalten bleibt oder nicht, und was Principal Propagation daran ändert
- Einen funktionierenden MCP-Server als MCP-fähige BTP-Destination registrieren, damit ein Joule-Studio-Agent ihn nutzen kann
Für wen dieses Modul gedacht ist. M327 hat Ihnen erklärt, was MCP ist. Dieses Modul baut einen: einen gouvernierten MCP-Server, der SAP Datasphere und SAP HANA Cloud als Tools bereitstellt, die ein Agent aufrufen kann — die Tool-Schicht, auf die der Analytics-Agent aus M350 angewiesen ist. Lesen Sie den ersten Abschnitt vor allem anderen: Er korrigiert eine Annahme, die der Modultitel nahelegen könnte.
1. Der ehrliche Ausgangspunkt: SAP liefert keinen „Datasphere-MCP-Server“
Suchen Sie nach einem, und Sie finden mehrere: Open-Source-Projekte auf GitHub, Glama und mcpmarket, die einen KI-Client mit den Metadaten, dem Katalog und den OData-APIs von Datasphere verbinden, sowie separate Community-HANA-MCP-Server mit Dutzenden SQL-Tools. Keines davon ist ein SAP-Produkt. Sie lohnen die Lektüre als Ideengeber — eines dokumentiert 45 Tools mit OAuth 2.0 und PII-Maskierung, ein anderes kapselt hdbcli hinter 34 SQL-Tools —, aber keines trägt SAP-Support, keines wurde für dieses Modul geprüft, und keines ist ohne eigene Sicherheitsprüfung auf einen Produktions-Tenant zu richten. Behandeln Sie jedes davon genau wie jede andere Open-Source-Abhängigkeit eines Drittanbieters: Lesen Sie den Code, bevor Sie ihm die Zugangsdaten eines Kunden anvertrauen.
Voraussetzungen
- M327 — MCP und A2A für SAP-Systeme (Protokollgrundlagen)
- Praktische Kenntnis von OData v4 und OAuth 2.0
- Sicherheit im Umgang mit einer HANA-Cloud-Verbindung (hdbcli oder ein gleichwertiger Client) und grundlegendem SQL
- Empfohlen parallel zu M350 (der Analytics-Agent, dem dieser Server dient) und Zugang zu einer Datasphere- oder HANA-Cloud-Testversion für die Übungen
Lernergebnisse
- Einen Kunden korrekt darüber briefen, was SAP für MCP über Datasphere/HANA liefert und was nicht, ohne ein Community-Projekt als SAP-Produkt darzustellen.
- Einen Quelltyp des Integration-Suite-MCP-Gateways für eine reale Anforderung wählen und begründen.
- Ein komponiertes, gut beschriebenes Tool entwerfen, das innerhalb der 30-Tools-Grenze und einer engen, parametrisierten Abfragefläche bleibt.
- Pro Tool angeben, welche Identität tatsächlich das Backend erreicht und ob das für die betroffenen Daten akzeptabel ist.
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.