Lesson 4 of 5
Dynamic behavior
10 min
Listen to this lesson
A recorded script assumes the screen sequence it saw on the day of recording. Real SAP sessions vary: a warning appears for one customer and not another, a popup asks whether to save, a credit check blocks the order, the item table has two rows today and twelve tomorrow. Robust GUI automation expects these variations and handles them deliberately.
Popups
A popup appears as a new window, usually wnd[1], on top of the main window. A recorded script either contains the popup step (and fails when the popup does not appear) or lacks it (and fails when it does). The robust pattern is to check whether a popup exists after each step that can produce one, read its title or text, and decide: handle an expected popup, fail on an unexpected one. Never close every popup blindly; an unexpected "credit limit exceeded" dialog is a test result, not an obstacle.
- Did the step open a new window (wnd[1] exists)?No → continue · Yes → read its title and text
- Is it an expected popup for this step, such as "Save changes?"Yes → answer it as the test case defines · No → next question
- Is it a known, harmless information popup?Yes → confirm it and log it · No → stop, capture evidence, fail the step
Status bar messages
Most SAP feedback arrives in the status bar at the bottom of the main window. Through the scripting API the status bar exposes the message text and properties such as the message type (S success, W warning, E error, I information, A abort), the message class and number, and its variables. A common beginner error is to compare the visible text to a letter like "E"; check the message type property instead. In many transactions a warning appears in the status bar and the user must press Enter to continue, so a script must recognize a warning and decide whether it is acceptable for this test.
| Message type | Typical meaning in a dialog transaction | Script response |
|---|---|---|
| S (success) | Step completed, often with a document number | Read the number from the message variables; continue |
| W (warning) | Processing can continue after confirmation | Accept only if the test case expects this warning; log it |
| E (error) | Input rejected; the user must correct it | Fail unless the test expects this error (negative test) |
| I (information) | Information, sometimes as a popup | Log and continue if expected |
| A (abort) | Transaction terminated | Fail and capture evidence |
Responding to status bar message types.
Variable rows and screen variants
The number of rows in an item table, a schedule line overview or an ALV list changes with the data. Read the row count from the control and loop, as the previous lesson showed. Screen layouts also vary: transaction variants and screen variants can hide or prefill fields, user parameters can default a plant or sales organization, and personal settings can change table column order. Make the test user's settings part of the test environment: fixed user parameters, no personal layout changes, and known variants. Otherwise the same script behaves differently for each tester.
Timing: the update task
SAP GUI Scripting calls normally wait for the server's response to a dialog step, so a script rarely needs to sleep between screen actions. The trap comes after saving. Many SAP transactions assign the document number in the dialog and write the database changes in the update task, which can finish moments later. A script that saves an order and immediately checks follow-on data can occasionally see nothing. Wait for a condition, such as the document being displayable, with a timeout, rather than adding a fixed delay.
- T+0sSaveScript presses Save in VA01
- T+0.5sMessageStatus bar shows the order number; the dialog step is complete
- T+1–3sUpdate taskDatabase updates finish asynchronously; output and follow-on steps may lag further
- VerifyPoll with timeoutScript checks until the order can be displayed or times out with a clear failure
What would you do?
Contoso's order-creation script passes for most customers but, for Great Lakes Fleet Services, occasionally stops with a warning that the credit limit is nearly reached. Maria confirms the warning is correct business behavior. What should the script do?
- Check for popups after steps that can produce them; handle expected ones, fail on unexpected ones.
- Read the status bar's message type, class and number, not just its text.
- Control test user settings: parameters, variants and layouts.
- After saving, wait for a condition with a timeout, because the update task finishes asynchronously.
Check your understanding · not graded
Lesson check
1. What should a script compare to detect an error in the status bar?
2. How should a robust script treat an unexpected popup?
3. Why can a follow-on check right after saving fail intermittently?
4. Why should test users have fixed parameters and layouts?