SAP GUI Scripting overview

Classic SAP transactions still carry a large share of daily work in most SAP S/4HANA Private Edition and on-premise systems: VA01, VL02N, MIGO, FB60 and hundreds more. To automate them you need a way to drive SAP GUI for Windows from a program. SAP provides one: the SAP GUI Scripting API, an automation interface built into SAP GUI for Windows.

SAP's security guide for the interface describes its purpose in two halves. End users can automate repetitive tasks by recording and running macro-like scripts; administrators and developers can build tools for server-side application testing or client-side integration. SAP's own eCATT uses it: eCATT's SAPGUI command records transactions with UI controls and requires scripting support to be installed and active.

What the server sees

The most important fact about GUI Scripting is in the first page of SAP's security guide: from the SAP server's point of view there is no difference between SAP GUI communication generated by a script and communication generated by a user. A script therefore has exactly the rights of the user who starts it, and the same data validation rules apply. The script does not bypass authorizations, and it cannot see data the user cannot see. It can, however, act much faster than a person and run unattended, so a bad script can create bad data quickly.

The object model

The API exposes SAP GUI as a tree of objects. At the top sits the application object, which is the scripting engine of the running SAP GUI. Under it are connections (one per system you are logged on to through SAP Logon), under each connection the sessions (the separate windows you open with "new session"), and under each session its windows: the main window and any popups. Each window contains areas such as the menu bar, the system and application toolbars, the title bar, the user area holding the screen fields, and the status bar. Controls such as fields, buttons, tabs, table controls, grids and trees sit inside those areas.

IDs: how a control is addressed

Every object has an ID that describes its path in this tree. A full ID looks like /app/con[0]/ses[0]/wnd[0]/usr/ctxtVBAK-AUART: application, first connection, first session, main window, user area, and then a control. The control part combines a short type prefix with the control's name. For classic screen fields the name usually comes from the ABAP Dictionary, such as VBAK-AUART for the sales document type. Where a name is not unique, an index is added in square brackets. Scripts usually call a "find by ID" method on a session object with a relative path that starts at the window, such as wnd[0]/usr/ctxtVBAK-AUART.

You do not have to work out IDs by hand. SAP GUI's script recorder writes scripts in VBScript or JScript, and a recorded script is the quickest way to see the IDs on a screen. Treat recordings as a source of IDs and a first draft, not as finished tests; later lessons explain why.