Application Modelling and Integration
Modelling approaches
Applications can be integrated through the UI (spying and surface automation), APIs (REST/SOAP), database access, command line, or file exchange. Prefer the most stable and supported interface: API over UI, database over screen scraping, where permitted and governed.
Spying and attributes
When modelling a UI, choose stable attributes such as element IDs or automation IDs over positional or text-based attributes. Test against different screen resolutions and states. Handle dynamic elements, waits, and modal dialogs explicitly rather than fixed sleeps.
Traps
Questions often test whether to use surface automation for Citrix or remote desktops: it is possible but brittle, so prefer published APIs or virtual channels where available. Another trap is assuming an API is always better; if the API is undocumented or rate-limited, UI may be the pragmatic choice. Also watch for authentication differences between UI and API paths.
File and data exchange
When exchanging files, define formats, encoding, validation, and archive rules. Avoid shared folders without locking; use queues to coordinate.
Rule of thumb
Rank integration options by stability and support: API, then database, then command line, then UI, then surface automation.
Worked example
A mainframe has no API but supports terminal emulation. Model it with the terminal connector and stable screen coordinates, add explicit waits for screen-ready conditions, and wrap each transaction in a block with recovery.