SAP-specific challenges

Automation engineers who come from web projects often underestimate SAP. The challenges are not exotic, but they combine: several UI technologies in one process, screen elements whose identity changes, business data that is consumed by every run, and test systems that drift away from production. This lesson names them so you can plan for them.

Two (or more) UI technologies

A single Contoso order-to-cash flow can touch an SAP Fiori app in the browser, a classic SAP GUI transaction such as VL02N, output in a PDF and an IDoc to a carrier. SAP GUI for Windows exposes an automation interface, SAP GUI Scripting, which administrators must enable on the server and client. Fiori apps are UI5 applications in a browser, so they are automated through browser-level techniques that understand UI5 controls. The same business step can therefore need two different automation approaches.

One Contoso order-to-cash flow crosses three technologies, and each needs its own automation approach.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-101

Aspect	SAP GUI for Windows	SAP Fiori (UI5 in a browser)
How automation reaches the screen	SAP GUI Scripting interface, enabled by profile parameter and client settings	Browser automation that recognizes UI5 controls
How elements are identified	Hierarchical IDs built from window, area, type prefix and field name	Control IDs, properties, bindings and labels; generated IDs can change
Typical fragility	Popups, screen variants, table rows that move	Asynchronous loading, generated IDs, responsive layouts
SAP tool examples	eCATT SAPGUI command; Solution Manager component-based test automation	OPA5 for app-level tests; Test Automation Tool for Public Edition

SAP GUI and Fiori need different automation approaches.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-101

Dynamic and unstable identifiers

A script must find each field and button reliably. In SAP GUI, an element's ID includes its position in the screen hierarchy, so a field that moves into a different subscreen or tab gets a new ID. In Fiori, many control IDs are generated at runtime and can change between releases or even page loads. Robust automation prefers stable properties, such as a field's technical name, a stable control ID set by the developer or an accessible label, over positions and generated IDs.

Data consumption

Business processes consume data. Creating a delivery consumes stock; billing consumes the delivery; a payment run clears the open item it needs. Run the script twice and the second run may fail because the first used up the stock or the open item. SAP also checks credit limits, number ranges, posting periods and blocked master data, so yesterday's perfect data can fail today because a period closed.

OrderScript creates a sales order for CMC-ALT-100 at plant 1710
DeliveryPicking and goods issue consume 10 pieces from storage location 171A
BillingInvoice consumes the delivery; it cannot be billed twice
Next runFails if stock is gone, the period is closed or the credit limit is used up
FixCreate or replenish data in the script, or reset it with a data job before each run

Why SAP test data gets consumed, and the usual fix.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-101

Environment drift and authorizations

Test systems change underneath the scripts. Transports arrive in CMQ in a different order than in production, a system refresh overwrites test data, and a key user changes a screen variant. Test users need realistic roles: a script that runs as a super-user proves nothing about whether Ana, the accounts payable clerk, can post an invoice, and it hides authorization defects. And business processes run asynchronously: output, workflow approvals, IDocs and background jobs complete later, so a script that checks too early fails for no real reason.

An outbound IDoc reaches its final status after the document that created it is saved, so a script polls for status 03 with a timeout instead of checking at once.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-101

Challenge	Symptom in a failed run	Design response
Unstable element IDs	Element not found after a support pack	Identify by stable properties; keep locators in one place
Data consumption	Second run fails on missing stock or open item	Create or reset data per run; avoid shared data between scripts
Environment drift	Works in CMQ last week, fails today with no code change	Monitor transports and refreshes; run a smoke check first
Authorizations	Passes as a super-user, fails for real roles	Run as role-based test users; check expected denials too
Asynchronous steps	Intermittent failures on output or workflow	Wait for a state, not a fixed time, with a timeout

Common SAP automation challenges and responses.

What would you do?

Contoso's automated billing script passes on Monday and fails on Tuesday with "No billing documents generated". Nothing was transported overnight. What should Priya's team check first?

Hands-on lab · ACCELQ

See how ACCELQ identifies SAPUI5 controls

UI5 apps generate many control IDs at runtime, so robust automation identifies elements by stable properties. ACCELQ offers Locator-Free identification (an AI-detected label kept in the statement) and the Smart Locator (a named element in the repository whose attributes you tune in the Element Explorer).

Practice on SAPUI5 Shopping Cart demo app (public, no login)

If you haven't set up ACCELQ yet, do the setup lab first.
Create a Context named "Cart Home" with the Shopping Cart URL as its entry page, then an Action named "Search and open product" in it, with Current Context as its Destination Context.
In the Logic Editor, start the Web Recorder from the Globe icon, open the Shopping Cart URL and choose Fluid. Type part of any product name you see into the search field, then open one result.
Read the statements. By default each element is Locator-Free: its label sits in the statement and nothing goes into the repository.
On the statement that opens the product, open its locator options, switch to Smart Locator and name the element "Search result item".
Open that element in the Element Explorer. Untick any id that looks generated (UI5 often uses a double-underscore prefix and running numbers) and keep stable attributes such as visible text or title. Check the match count is 1.
Switch to Intent and, before the step that opens the product, right-click the result list and add Wait for Web Element, which polls up to a timeout you set. Never use a fixed pause.
Play the Action back and read the Playback Console. Reload the app and play it again.

Done when You pass when the Action plays back cleanly twice, one element is a Smart Locator with stable attributes and a match count of 1, and a wait-for-element step replaces any fixed pause. Note which attributes you rejected and why. That's the judgment you'd apply to a Contoso Fiori app before a support pack moves things around.

Learn more in ACCELQ’s docs: Locator-Free and Smart Locator · Setting up Element Identification with Element Explorer · Handling dynamic elements

Start the free ACCELQ trial Matt Angerer, who runs The Sign-Off Table, works at ACCELQ. Disclosure

Key points

One SAP process can span SAP GUI, Fiori, output and interfaces, each with its own automation approach.
Identify elements by stable properties, not positions or generated IDs.
Processes consume data: create or reset data per run.
Plan for environment drift, role-based test users and asynchronous steps.

Two (or more) UI technologies

Dynamic and unstable identifiers

Data consumption

Environment drift and authorizations

Lesson check