Business Objects and Application Integration
The object as a contract
A Business Object is a reusable contract between the process and an application. Its public Actions should be business-meaningful (for example, "Create Case" rather than "Click Button 3"), and each action should have defined inputs, outputs, and a clear description. Internal Functions hold shared logic such as login, navigation to a home screen, or element readiness checks.
Application Modeller in depth
Understand application types and their launch/attach semantics: Windows applications, web browsers, mainframe terminals, Java applications, and Citrix or region-based surfaces. Know the Identify and Highlight tools, how attributes are captured, and how match modes affect reliability. Understand that a browser application can attach to an existing session by title or URL, and that region mode is the fallback when no accessible element tree exists.
Element and wait strategy
Robust objects wait for readiness rather than sleeping. Understand Wait stages with timeout and interval, and how to check for element existence before interacting. Know that timeouts should raise a business-relevant exception rather than silently continuing.
Traps to watch for
Questions often test whether you know that an object should not contain process-specific business rules, that actions should be idempotent where possible, and that hard-coded sleeps are a design smell. Another trap: confusing an Action stage inside an object (calling another object) with a Function call within the same object.
Rule of thumb
If two different processes would need the same screen interaction, it belongs in the object. If only one process needs it, it may still belong there - but the action name should still describe the business intent.