Automating SAP Tests with Python

Classical SAP systems (R/3, ECC, S/4HANA with SAP GUI) can be driven programmatically from Python. That opens a direct path to SAP test automation: write tests against SAP transactions, load test data via RFC, hook regression tests into the pipeline. Three approaches are on the table, each with different prerequisites and trade-offs.

RFC calls with PyRFC

PyRFC was the official Python connector for the SAP NetWeaver RFC Library. The library mapped ABAP function modules to Python calls: structures became dicts, tables became lists of dicts, type conversion happened automatically. With it you could call BAPIs, read tables, and manipulate test data directly at the application layer.

A typical test setup: open a connection, read the expected state of an SAP table via RFC_READ_TABLE, trigger a posting through a BAPI, read again, compare against the expected state. It runs headless, runs on Linux, and integrates into any CI/CD pipeline.

As of January 2025, PyRFC is archived. SAP set the repository at SAP-archive/PyRFC to read-only; all PyPI releases are marked yanked. Python 3.13 is no longer supported. SAP has not announced an official successor. Existing installations keep working, but security patches and bug fixes are no longer forthcoming.

If you run PyRFC in production, treat the dependency as technical debt. The SAP NetWeaver RFC SDK (mandatory prerequisite, proprietary, download requires an S-User) is still maintained. The connector around it is not.

SAP GUI Scripting via COM

SAP GUI for Windows ships with a COM-based scripting API. Python attaches to a running SAP GUI session through win32com.client (package pywin32) and drives it remotely: launch transactions, fill fields, press buttons, read out ALV grids. The principle matches browser automation with Playwright — only for the SAP client.

For SAP test automation, this approach is relevant when no RFC-capable function module exists. Some SAP transactions are reachable only through the GUI. In that case, GUI Scripting is the only programmatic option left.

Entry is low-friction. SAP GUI can record user actions as VBScript. The recorded script translates to Python with little effort. Stefan Schnell’s Scripting Tracker (tracker.stschnell.de) shows the object hierarchy as a tree and identifies element IDs on hover.

The constraints weigh heavily for test automation:

Windows only. No headless mode, no use on Linux CI runners
The SAP Basis admin must set the parameter sapgui/user_scripting to TRUE. Many organisations disable scripting on security grounds
Element IDs change with SAP customising, Screen Personas, or upgrades. Tests break without a code change to the system under test
Timing: Python sends commands faster than the COM interface processes them. Without time.sleep() after screen transitions, scripts fail
ALV grids load only the visible rows. For full table assertions, the script has to scroll explicitly

GUI Scripting fits targeted smoke tests of individual transactions. As the basis for a regression suite, it is too fragile.

Direct ctypes access as PyRFC successor

Since the PyRFC archival, an alternative is taking shape: RFC calls directly through Python’s ctypes module, with no extra connector. The C library sapnwrfc.dll (or libsapnwrfc.so on Linux) is loaded, and its functions are called from Python.

The repository jdsricardo/SAP-RFC-Python-without-PyRFC on GitHub shows a working example. The SAP Community documents the approach in a multi-part blog series.

The upside: no Cython dependency, no orphaned third-party library. The only external dependency is the SAP NW RFC SDK, which SAP actively maintains (current Patch Level 18, as of December 2025). The downside: noticeably more code. C structures have to be defined in Python; the automatic type conversion that PyRFC did is gone. What took three lines in PyRFC takes thirty with ctypes.

For new SAP test automation projects, ctypes is currently the most viable RFC-based option.

Robot Framework as the test language

Robot Framework expresses tests as keyword tables in .robot files. Each keyword is implemented in Python. That means all three SAP access paths (PyRFC, GUI Scripting, ctypes) plug in as keyword libraries.

For GUI Scripting, the ready-made library robotframework-sapguilibrary is on PyPI. For RFC-based access, you write your own keyword library that internally calls ctypes or PyRFC. The test logic stays readable in Robot Framework; the SAP communication sits in Python.

This separates test specification from technical access. If the access mechanism changes (say, from PyRFC to ctypes), the .robot file stays untouched. Only the underlying Python library is swapped.

Comparing approaches to SAP test automation

Criterion	PyRFC (archived)	GUI Scripting (COM)	ctypes direct
Platform	Windows, Linux, macOS	Windows only	Windows, Linux, macOS
Headless / CI	Yes	No	Yes
SAP GUI required	No	Yes	No
Stability	API-based, stable	UI-bound, fragile	API-based, stable
Maintenance	Archived, no patches	Maintained by SAP (GUI)	Community, active
Learning curve	Medium	Low	High
Fits	Existing projects	Transactions without BAPI	New projects

RFC-based approaches (PyRFC or ctypes) are preferable for test automation: headless, stable, pipeline-ready. GUI Scripting remains the fallback for transactions not reachable via RFC.

If you are setting up a new SAP test automation project today, start with ctypes and the current SAP NW RFC SDK. The SDK requires an S-User with download authorisation (SAP Note 1037575). Request the authorisation from SAP Basis early.

Sources

Planning SAP tests with Python in an existing pipeline? In the UTAA workshop we set architecture, tooling, and data strategy specifically for your project. More on the method or get in touch directly.