Legacy desktop automation for SAP and Oracle, without the RPA tax

The thing every legacy-RPA guide skips

SAP GUI for Windows is a thick Win32 client. Its windows participate in the standard Microsoft UI Automation tree the same way any other Win32 process does. You can verify that in sixty seconds: open SAP Logon, run inspect.exe from the Windows SDK, hover the transaction code box. You will see the control reported as an Edit with AutomationId tbar[0]/okcd. The customer master screen reports a Pane at wnd[0]/usr. The labels report as Text elements with their German or English screen names. Every one of those is a normal UIA selector.

Oracle Forms is the awkward sibling because it is Java. Java applications publish a Swing/AWT accessibility tree, not a native Win32 one, so UIA does not see Forms controls out of the box. The standard fix is the Java Access Bridge (JAB), an Oracle/Microsoft component that bridges the Java accessibility tree into MSAA, which UIA reads. One command (jabswitch -enable), one JVM restart, and Forms controls show up as role:Text,role:Button, role:ListItem in the same UIA tree. After that, the surface is identical to driving any other Win32 app.

None of this is a hidden secret. It is just not the angle most articles take, because most articles are downstream of vendor marketing. The vendors who sell SAP connectors do not want to lead with "there is a free Microsoft API that handles this".

One locator, three legacy apps

The whole pitch is that the call shape does not change when the target app changes. The selector resolves through the same parser, the same UIA walker, the same action API.

SAP is not a plugin. It is the canonical example in the codebase.

If you are wondering whether SAP is an afterthought, it is not. SAP appears in three places inside the Terminator monorepo, all of them committed code, none of them marketing copy. First, the workflow API uses SAP as the canonical example in its JSDoc. Open packages/workflow/src/workflow.ts at line 598 and you will find createWorkflow({name: 'SAP Login'})as the doc example for the direct pattern. Second, the structured error API uses SAP as the canonical example for the business category: packages/workflow/src/types.ts at line 219 documents WorkflowError({ code: 'SAP_DUPLICATE_INVOICE', message: 'Invoice already exists in SAP', recoverable: true }). Third, the success-summary example at types.ts:549 uses # SAP Journal Entry - Success as its Markdown summary template. The framework is shaped around the kind of workflow that ends with "invoice posted" or "journal entry created".

There is also a real integration test in the Rust core: test_sap_login_scenario at crates/terminator/tests/debugger_detach_test.rs:191. The test simulates the "Login to SAP" step of a real user's workflow and reproduces the debugger-detach error they hit during it. The test exists because someone tried to automate SAP through Terminator, ran into a CDP edge case, and we wrote a regression test against the exact scenario. That is what canonical-example looks like in practice.

What the Windows session actually looks like

Below is an actual MCP session shape against an SAP Logon window. The assistant calls get_window_tree, gets back the UIA tree, picks the transaction code box by its AutomationId, typesXD03, and presses Enter. Same primitives as Playwright on a web page. None of it goes through SAP GUI Scripting; thesapgui/user_scripting profile parameter can be off the entire time.

SAP GUI Scripting versus UIA: the honest comparison

SAP GUI Scripting is fine when it is available. It exposes a tidy object model (session.findById) and it is what most RPA platforms wrap. The reason teams end up looking for an alternative is that the scripting flag is server-side, security teams gate it carefully, and the COM surface is hard to drive from a modern test runner. UIA bypasses that whole conversation.

None of this means SAP GUI Scripting is wrong. If your environment already has it on and your team owns the .NET tooling, it is the faster path. The argument here is that you should not have to choose between "buy a vendor RPA platform" and "write VBScript against COM". There is a third option: a developer framework over the accessibility tree both legacy apps already publish.

What the same approach actually covers

Anything that publishes to the UIA tree is in scope. Anything that does not, is not. That is the honest line, and it is the line I would want a reader to walk away with rather than a feature matrix.

Where this falls apart

Three places. First, when SAP GUI or Oracle Forms reaches your laptop as a video stream from a Citrix or RDP session, there is no UIA tree on your side. The framework has to run on the session host inside the published environment, not on the thin client.

Second, when an internal LOB app draws every control onto a single HWND with GDI calls instead of using a real control framework. UIA sees one giant Pane with no children. This is rare for SAP and Oracle but common for very old Delphi or custom MFC apps. Pixel and OCR are the only options there, and Terminator has them via the Windows OCR engine in crates/terminator/src/platforms/windows/engine.rs around line 763 (TryCreateFromUserProfileLanguages), but they are the fallback, not the plan.

Third, when you need an attended-bot orchestrator with a hosted job queue, formal SLA contracts, and a marketplace of pre-built activities. Terminator is a framework, not a platform. You bring the runner. If that is a non-negotiable for your org, UiPath or Power Automate is the right purchase, and using Terminator inside them as a custom activity is the better integration than rebuilding their entire control plane.

The smallest first step

On a Windows box where SAP Logon or your Oracle Forms client already runs, install the MCP agent and ask your assistant to walk the tree:

# 1. install the MCP server
claude mcp add terminator "npx -y terminator-mcp-agent@latest"

# 2. open SAP Logon (or Forms), then ask the assistant:
#    "call get_window_tree on the SAP window and find the transaction
#     code box"

# 3. read the tree it returns. role, name, AutomationId on every node.
#    that's the surface you write selectors against. nothing else to set up.

If the tree comes back with usable names and AutomationIds on the controls you care about, you have everything you need. The rest is locator() calls in a file you own.

Frequently asked