Scripted UI testing for an ERP add-on, driven through SAP's own interface thread

Problem

Testing a SAP Business One add-on usually means someone opens screens and types by hand. Every time a module is touched the same walkthrough has to be repeated, and it gets repeated worse: the tester skips steps that already worked last week.

Solution

I extended the add-on bridge with around thirty automation commands: read and write fields, walk matrices, wait for a value to change, answer dialog boxes and open master records. That is enough to script a full functional walkthrough and replay it.

The delicate part was not the protocol, it was the thread. SAP's UI API is COM and lives on the desktop client's interface thread; a call made from the thread serving the request appears to work most of the time and hangs the client the rest, with no visible pattern. So every command is queued and executed inside the real interface thread, and the result travels back the way it came.

The second decision was not to automate by coordinates. SAP controls are addressed by form and item identifier, so a script stays valid when a screen is resized or moved.

Architecture

Why it is built this way

Everything enters through SAP's real interface thread. A COM call from another thread hangs the client now and then, and an intermittent hang costs more to track down than a clear error.

The commands are closed. A script cannot ask the add-on for anything it does not already know how to do.

Waits are on a condition, with a time limit. Fixed pauses work on your machine and fail on the client's.

Dialog boxes get their own command, because a modal message stops the whole walkthrough and has to be answered from inside.

Controls are addressed by identifier rather than coordinates, so a script survives someone moving a screen around.

Result

A full functional walkthrough over the ERP interface can be scripted and replayed with no manual input, with thread-related hangs removed at the source.