SAP-Tests mit Python automatisieren

Klassische SAP-Systeme (R/3, ECC, S/4HANA mit SAP GUI) lassen sich mit Python programmatisch ansteuern. Das eröffnet einen direkten Weg zur SAP-Testautomatisierung: Tests gegen SAP-Transaktionen schreiben, Testdaten über RFC laden, Regressionstests in die Pipeline einbinden. Drei Ansätze stehen zur Wahl, jeder mit anderen Voraussetzungen und Trade-offs.

RFC-Aufrufe mit PyRFC

PyRFC war der offizielle Python-Connector für die SAP NetWeaver RFC Library. Die Bibliothek übersetzte ABAP-Funktionsbausteine in Python-Aufrufe: Strukturen wurden zu Dicts, Tabellen zu Listen von Dicts, Typkonvertierung lief automatisch. Damit liessen sich BAPIs aufrufen, Tabellen lesen und Testdaten direkt auf der Applikationsschicht manipulieren.

Ein typischer Testaufbau: Verbindung öffnen, über RFC_READ_TABLE den Soll-Zustand einer SAP-Tabelle lesen, per BAPI eine Buchung auslösen, Ergebnis erneut lesen und gegen den erwarteten Zustand prüfen. Das funktioniert headless, läuft auf Linux und lässt sich in jede CI/CD-Pipeline integrieren.

Seit Januar 2025 ist PyRFC archiviert. SAP hat das Repository unter SAP-archive/PyRFC auf read-only gesetzt, alle PyPI-Releases sind als yanked markiert. Python 3.13 wird nicht mehr unterstützt. SAP hat keinen offiziellen Nachfolger angekündigt. Bestehende Installationen funktionieren weiterhin, aber Sicherheits-Patches und Bugfixes bleiben aus.

Wer PyRFC produktiv einsetzt, sollte die Abhängigkeit als technische Schuld bewerten. Das SAP NetWeaver RFC SDK (Pflichtvoraussetzung, proprietär, Download nur mit S-User) wird weiterhin gepflegt. Der Connector dazu fehlt.

SAP GUI Scripting per COM-Schnittstelle

SAP GUI für Windows enthält eine COM-basierte Scripting-API. Python greift über win32com.client (Paket pywin32) auf die laufende SAP-GUI-Sitzung zu und steuert sie fern: Transaktionen starten, Felder füllen, Buttons drücken, ALV-Grids auslesen. Das Prinzip entspricht Browser-Automatisierung mit Playwright, nur eben für den SAP-Client.

Für die SAP-Testautomatisierung ist dieser Ansatz relevant, wenn kein RFC-fähiger Funktionsbaustein existiert. Manche SAP-Transaktionen sind nur über die GUI erreichbar. In diesem Fall bleibt GUI Scripting der einzige programmatische Weg.

Der Einstieg ist niederschwellig. SAP GUI kann Benutzeraktionen als VBScript aufzeichnen. Das aufgezeichnete Skript lässt sich nach Python übersetzen. Stefan Schnells Scripting Tracker (tracker.stschnell.de) zeigt die Objekt-Hierarchie als Baumstruktur und identifiziert Element-IDs per Hover.

Die Einschränkungen wiegen für Testautomatisierung schwer:

Nur Windows. Kein headless Betrieb, kein Einsatz auf Linux-CI-Runnern
Der SAP-Basis-Administrator muss den Parameter sapgui/user_scripting auf TRUE setzen. Viele Unternehmen deaktivieren Scripting aus Sicherheitsgründen
Element-IDs ändern sich bei SAP-Customizing, Screen Personas oder Upgrades. Tests brechen ohne Codeänderung am System under Test
Timing-Probleme: Python sendet Befehle schneller als die COM-Schnittstelle verarbeitet. Ohne time.sleep() nach Bildschirmwechseln laufen Skripte in Fehler
ALV-Grids laden nur sichtbare Zeilen. Für vollständige Tabellenprüfungen muss das Skript explizit scrollen

GUI Scripting eignet sich für gezielte Smoke-Tests einzelner Transaktionen. Als Basis für eine Regressions-Suite ist es zu fragil.

ctypes-Direktzugriff als PyRFC-Nachfolger

Seit der Archivierung von PyRFC entsteht ein alternativer Ansatz: RFC-Aufrufe direkt über Pythons ctypes-Modul, ohne zusätzlichen Connector. Die C-Bibliothek sapnwrfc.dll (bzw. libsapnwrfc.so auf Linux) wird geladen und ihre Funktionen aus Python heraus aufgerufen.

Das Repository jdsricardo/SAP-RFC-Python-without-PyRFC auf GitHub zeigt funktionierende Beispiele. Die SAP Community dokumentiert den Ansatz in einem mehrteiligen Blog.

Der Vorteil: keine Cython-Abhängigkeit, keine verwaiste Drittbibliothek. Die einzige externe Abhängigkeit bleibt das SAP NW RFC SDK, das SAP aktiv pflegt (aktueller Patch Level 18, Stand Dezember 2025). Der Nachteil: deutlich mehr Code. C-Strukturen müssen in Python definiert werden, die automatische Typkonvertierung von PyRFC entfällt. Was in PyRFC drei Zeilen brauchte, braucht mit ctypes dreissig.

Für neue Projekte in der SAP-Testautomatisierung ist ctypes aktuell die tragfähigste RFC-basierte Option.

Robot Framework als Testsprache

Robot Framework formuliert Tests als Keyword-Tabellen in .robot-Dateien. Jedes Keyword ist in Python implementiert. Damit passen alle drei SAP-Zugriffswege (PyRFC, GUI Scripting, ctypes) als Keyword-Libraries in Robot Framework.

Für GUI Scripting existiert die fertige Library robotframework-sapguilibrary auf PyPI. Für RFC-basierte Zugriffe lässt sich eine eigene Keyword-Library schreiben, die intern ctypes oder PyRFC verwendet. Die Testlogik bleibt in Robot Framework lesbar, die SAP-Kommunikation steckt in Python.

Dieser Aufbau trennt Testspezifikation von technischem Zugriff. Wenn sich der Zugriffsmechanismus ändert (etwa von PyRFC auf ctypes), bleibt die .robot-Datei unverändert. Nur die darunterliegende Python-Library wird ausgetauscht.

Ansätze für SAP-Testautomatisierung im Vergleich

Kriterium	PyRFC (archiviert)	GUI Scripting (COM)	ctypes direkt
Plattform	Windows, Linux, macOS	Nur Windows	Windows, Linux, macOS
Headless / CI	Ja	Nein	Ja
SAP GUI nötig	Nein	Ja	Nein
Stabilität	API-basiert, stabil	UI-abhängig, fragil	API-basiert, stabil
Wartungsstatus	Archiviert, keine Patches	Von SAP gepflegt (GUI)	Community, aktiv
Lernkurve	Mittel	Niedrig	Hoch
Einsatz	Bestehende Projekte	Transaktionen ohne BAPI	Neue Projekte

RFC-basierte Ansätze (PyRFC oder ctypes) sind für Testautomatisierung vorzuziehen: headless, stabil, pipeline-fähig. GUI Scripting bleibt die Rückfalloption für Transaktionen, die nicht per RFC erreichbar sind.

Wer heute ein neues Projekt für SAP-Testautomatisierung aufsetzt, startet mit ctypes und dem aktuellen SAP NW RFC SDK. Das SDK erfordert einen S-User mit Download-Berechtigung (SAP Note 1037575). Die Berechtigung frühzeitig über die SAP-Basis beantragen.

Quellen

Sie planen SAP-Tests mit Python in einer bestehenden Pipeline? Im UTAA-Workshop legen wir Architektur, Tooling und Datenstrategie projektspezifisch fest. Mehr zur Methode oder direkt anfragen.