SAPFX

Automating SAP means juggling two worlds that have nothing in common: the SAP GUI desktop client and the Fiori web. Two tools, two skill sets, and tests that break at the slightest change of screen, id or language. Maintenance ends up costing more than writing.

The idea

Write the test once, in business language. The same keyword works on the SAP GUI, on Fiori or through the OData API. Underneath, three Robot Framework libraries (SapEccLibrary, SapFioriLibrary, SapApiLibrary) and machinery built not to break for the wrong reasons: waits track the real SAP state, assertions are language-independent, locator self-healing is always logged.

Go To Transaction    VA01           # SAP GUI
Open App             Sales Order    # Fiori

The project on video

What it does

• One vocabulary, three channels. The same test reads identically whether it drives the GUI, Fiori or the API.
• Tests that do not break for nothing. Real SAP waits, language-independent assertions, no technical identifiers in the tests.
• AI-native, under control. Agents plan, write and repair tests by driving the real system; every generated step is executed live before being written.
• Maintenance becomes preventive. Screen drift sentinel, visual assertions, telemetry of drifting locators.
• Commercial-suite capabilities, open-source cost. No license, no vendor lock-in.

Live, not on slides

Proof, not promises

Figures observed at version 0.7.0 (August 2026). Measured coverage: 94%, CI floor: 85%. UI5 compatibility proven from 1.60 to 2.0. Bilingual French/English documentation.

The same campaign, two SAP releases

A suite that passes on a single system mostly proves that this system has not moved. In August 2026 the Fiori launchpad exploration campaign was therefore replayed as is against two ABAP servers, one serving SAPUI5 1.71 and the other 1.120, with the same page object and not a single condition on the version number: 22/22 scenarios validated live on one side, 20/20 on the other.

• Identical on both sides: the catalogue that gets rendered, namely 2 catalogues, 67 tiles and 62 intents of which 61 actually resolve.
• Different, and kept in variables: the user actions menu changes both its name and its control type; the dialog that refuses a navigation gains a button, so acknowledging at the first position copies the message instead of closing the window; the number of controls rendered on the home page drops from 184 to 134, enough to break any threshold written as a constant.
• The trap the second release exposed: the probe that read the 1.71 tiles kept answering on 1.120, without an error, with empty titles. Scenarios would have gone green on nothing at all. The failure now has a name.

Both servers remain demo images, not a production S/4HANA with its own custom developments. What is established is that a campaign survives a release change without being rewritten. On a customer landscape, that will have to be measured again. Both suites are in the repository.

Where it stands

Commercial SAP testing suites are mature and complete, with vendor support and a codeless mode that SAPFX does not have; their licenses run from tens to hundreds of thousands of euros per year. The historical open source is single-channel: RoboSAPiens covers the SAP GUI only, wdi5 the UI5 web only, outside Robot Framework. SAPFX covers all three channels inside Robot Framework, with a single report, for free.

The SAPFX frequently asked questions live on the site's FAQ page.