SAPGUI scripting must be installed on the client. It can be selected during the SAPGUI client setup process. Once it has been installed on the client, SAPGUI scripting must be enabled on both the client and the server.
The SAPLogon process initializes the SAPGUI scripting API. This allows the recorder to attach to a COM object that offers full access to the SAP DOM where each component (control) within SAPGUI can be accessed. This COM interface also offers an event mechanism that notifies subscribers of changes in the GUI (for example, button presses, text edits) and server roundtrips (Start/End Request).
The Silk Performer Recorder is a subscriber of this event interface, so it receives notice of all changes that are made by the user in the SAPGUI user interface. Depending on recording profile settings, Silk Performer Recorder is either set for low-level scripting of API calls for each change event, or high-level scripting for API calls in which certain change events are merged with high-level calls (for example, SapGuiLogon).
When executing a SAPGUI load test, the SAPGUI user interface is automatically switched to invisible mode. There is a setting in the profile settings that allows you to execute a GUI-less TryScript run. This setting however, has no effect in load test scenarios as it does not make sense to show the UI when executing multiple users on a machine, because too many windows would be displayed; additional resource consumption would be required if each window has to render itself.
As each VUser has access to the full SAP DOM, it is possible to generate TrueLogs with rich control information.