How to automate SAP, when “SAP” is four different products and three of them break the standard advice.

Automating SAP means having a machine perform the data entry, validation, and posting work that a human is doing today inside one of SAP's applications (classic SAP GUI for Windows, S/4HANA Fiori, Business One, or ByDesign). The four real ways to do that are server-side function calls (BAPI, RFC, OData), SAP GUI Scripting (VBScript through SAP's COM interface), selector-based RPA (UiPath and similar driving the rendered controls), or accessibility-tree AI agents (recording an operator once and replaying through the OS-level UI Automation tree). The right one depends on your SAP version, your Basis approvals, and whether the workflow stays inside SAP.

Yes, the licensed user that the automation runs as still counts as a named user under SAP's licensing model, regardless of which approach you pick. BAPI and RFC require a dialog or system user with the right authorizations. SAP GUI Scripting, selector RPA, and accessibility-tree agents all run as a logged-in user against the same SAP instance. The licensing question is less about the automation tool and more about how many concurrent SAP sessions you intend to run, which feeds the user-type decision (named, communications, system) on your contract.

It is still the most-cited answer in older content, but in regulated environments it is increasingly not the default. SAP GUI Scripting requires Basis to enable sapgui/user_scripting=TRUE on the application server and a per-client allow flag, both of which security review treats as a privilege-escalation surface. It also only applies to classic SAP GUI for Windows; Fiori, B1, and ByDesign each have a different answer. For mid-market and regulated customers we more often see selector RPA (UiPath, Power Automate Desktop) or accessibility-tree agents (Mediar) chosen over GUI Scripting because they don't require the Basis change.

BAPI is hours to days when the BAPI exists and you have an ABAP developer. SAP GUI Scripting is a couple of days for a one-screen flow once Basis has enabled scripting and the script author has the field mapping. Selector-based RPA on a single transaction is typically two to six weeks per developer, dominated by selector tuning and exception handling. Accessibility-tree agents sit in days because the recording pass writes the workflow file and the runtime is deterministic replay; we have shipped F-02 journal-entry workflows in under a week of total elapsed time. The number you should care about is not first-deploy time, it is what re-tuning a workflow costs after a support pack.

Yes. ABAP is only required for the BAPI/RFC path. SAP GUI Scripting is VBScript. Selector-based RPA uses the vendor's visual designer (UiPath Studio, Power Automate Desktop) and a low-code expression language. Accessibility-tree agents like Mediar record the operator's actions and emit a TypeScript workflow file; you can read and edit it without writing ABAP. The trade you make by skipping ABAP is that you are driving SAP through its UI rather than its server-side function modules, which is fine for most transactional data entry and not the right tool for batch migration loads.

Yes, materially. SAP GUI Scripting does not exist on Fiori; it is a web app. BAPI is replaced by OData services, and the catalog is different. Selector RPA needs a web automation pack rather than a desktop one. Accessibility-tree agents read Chrome's accessibility tree on Fiori, which is the same surface a screen reader uses on any web page. The cleanest part of the answer is that the same tool can cover both classic GUI and Fiori in one workflow if it can target both surfaces with one primitive; the messy part is that almost no enterprise actually runs only one of the two, so any plan that picks a tool that handles only classic GUI will need a second tool for the Fiori work.

RISE complicates two things. First, RFC users are subject to the hosting agreement, and you may not be allowed one at the volume you need. Second, the desktop on which SAP GUI runs is often a Citrix or Azure Virtual Desktop session managed by SAP or by a partner, and getting a desktop agent installed requires their cooperation. Selector RPA and accessibility-tree agents both work over remote desktop because the accessibility tree passes through, but the install path is contract negotiation rather than a download. BAPI / OData where allowed is usually the cleanest path on RISE precisely because it does not require local install rights.

Three habits matter. First, do not pin selectors to absolute pixel position; SAP shifts controls between rows on patch level changes. Second, prefer multi-strategy resolution: try the recorded automation id, then the window-relative bounds, then the visible text label, then the parent-window fallback, and only flag the step for re-recording when all of them miss. Third, instrument every workflow run with a structured failure trace (parent window title, surfaced text, unresolved step id) so you can fix the broken step in minutes instead of debugging a black-box failure for hours. The accessibility-tree approach is friendlier to all three habits than pixel matching.

Depends on which architecture you pick. Vision-loop tools (OpenAI Operator, Anthropic Computer Use, Browser Use) call a model on every step at runtime, which makes the workflow non-deterministic and is usually unacceptable on a regulated finance flow. Mediar's architecture runs the model exactly once during recording: the model reads the captured event stream, infers the workflow, and writes a TypeScript file. After that, the runtime is deterministic Rust against the Windows UI Automation tree with no LLM in the hot path. A grep of the executor crate at github.com/mediar-ai/terminator finds zero references to OpenAI, Anthropic, or Gemini SDKs at runtime. Two identical inputs produce two identical action sequences. That is the bet that lets a finance team sign off on the workflow.

BAPI is mostly an ABAP developer's time plus the SAP-side licensing change to add a system or communications user. SAP GUI Scripting is mostly script-author time plus the Basis hour to enable it. Enterprise selector RPA is per-bot licensing (UiPath sits in the high four figures per attended bot per year, plus Orchestrator) plus implementation. Accessibility-tree agents like Mediar price by runtime minute ($0.75/min on the standard rate) with a $10K turn-key program fee that converts to credits. The honest cost comparison is not list price; it is total cost of ownership including the maintenance hours you will spend re-tuning selectors after support packs.

BAPI requires SAP-side credentials and an ABAP environment, which is a heavier ask. SAP GUI Scripting requires Basis to enable scripting in a sandbox before you can write a useful script. UiPath has a community edition that lets you build a single SAP automation locally. Mediar runs a turn-key program on a paid pilot, but the open-source Terminator SDK at github.com/mediar-ai/terminator (MIT license) is what the runtime uses to type into SAP fields, and a developer can prototype against their own SAP instance with it before talking to anyone.

Mediar is the accessibility-tree AI agent option. The recording pass writes a TypeScript workflow file, the runtime is deterministic Rust calling the Windows UI Automation tree, the same primitive that types into saplogon.exe also types into Chrome on Fiori, and no SAP-side change is required. We are usually the right answer when (a) Basis will not enable sapgui/user_scripting, (b) the BAPI does not cover the transaction or the workflow leaves SAP, (c) you cannot afford UiPath's per-bot licensing or the implementation timeline, or (d) you have classic GUI and Fiori in the same workflow and need one tool that crosses both. We are the wrong answer when there is a clean BAPI for your transaction and you have ABAP capacity; in that case write the BAPI call.