DocsHooking
Application hooking is an invasive automation technique for retrieving data from a graphical application. It involves injecting executable code into the target application's memory space in order to feed back information. Whilst technically invasive, this technique has no effect on the target application's behaviour.
The process of feeding back data can be summarised as follows: Blue Prism anticipates where the application will send data, it listens for data in that place, intercepts and observes the data, and then passes it on to its intended destination. A more technical description of this process is outlined below.
How hooking works
The following description requires some technical knowledge.
Blue Prism replaces the implementation of functions within the target application's copy of the windows user32, Kernel32 and gdi32 libraries. The new implementations take note of any parameters passed, making this information available to Blue Prism, and then invoke the original implementation, in order that the application continue to behave as before.
Examples of functions replaced include DrawTextA and SetWindowPos, allowing Blue Prism to know about any text rendered on the screen, and any windows created within the application (respectively).
Blue Prism collates this information into an object model, remembering each piece of information gathered and how each piece of information relates to the whole. The model is updated in real time, with out-dated information discarded and new information always observed, meaning that Blue Prism is always aware of the current state of the application and ready to report on it.
This functionality allows Blue Prism to interact with the target application from Object Studio, waiting for an anticipated feature in the object model for example, or reading data from the model to be used in a business process.
Uses
Hooking is usually used as a last resort, when no better form of integration is available, (where "better" means a more platform-specific method such as Java integration).
Typically, hooking is used when the target application is implemented against a framework which reimplements features provided by the Windows API. For example instead of creating a button via the windows API, the framework may render its own button on the screen. As a result, when Blue Prism attempts to inspect the application using Windows integration techniques all that can be seen is a single window, rather than a window containing several individual components such as buttons, edit fields and combo boxes. In this case, hooking allows Blue Prism to observe the text drawn on the button meaning that the button's location can be inferred.
Examples of frameworks for which hooking is suitable include Smalltalk, GTK+, and Qt.
Advantages
Hooking technology is useful because it boasts key features above traditional macro-based approaches to automation:
- Reliability
Macro-based automation relies on a "click and pray" approach which consists of naively sending mouse click messages at predetermined screen coordinates. Such techniques are error prone and notoriously unpredictable. In particular, they fail if any visual aspect of the application changes, be it due to a software upgrade, a change in screen resolution, or differing themes/skins used across different PCs. This can result in a non-functioning macro or, even worse, a macro which has unintended behaviour, causing data corruption.
- Ease of data retrieval
Macro-based automation has no fail-safe method of retrieving data. At best, it can focus an element of interest via a (naive) mouse click, send keyboard shortcuts to select all text, and copy the selected text to the clipboard. Thus data is easily missed and often incomplete. In contrast, hooking has all of the data captured in real time, and can even detect the presence of the data – see "detecting readiness" below.
- Detecting Readiness
Macro-based automation is usually based on naive pauses (timed waits) to ensure that the application is ready to receive input, or that data is present and available for reading. For example after clicking a "Get Details" button, it may be necessary to wait for a reply from a remote database before the application can display some data on the screen. The time taken to complete this operation is unpredictable and can vary greatly, according to the load on the database server. As a result, a macro can often exhibit unintended behaviour, because it moves on to the next stage before the target application is ready.
In contrast, Blue Prism's hooking model has details of the target application's state. The model contains information about which components and which pieces of information are present. For example, if data is presented in a pop-up window, Blue Prism is capable of waiting as long as is necessary for the window to appear, and indeed for the data within that window to appear. This ability to wait is as opposed to a fixed wait of 30 seconds (for example) in a macro, which is hoped to be long enough for the pop-up window to appear in "most" cases.
- Speed
As described above, Blue Prism has sophisticated waiting capabilities for detecting readiness in the target application. This means that it only need wait as long is as necessary at each stage. Consider again the example of waiting for the pop-up window. A macro may decide to wait 30 seconds in each case in order to guarantee (perceived) reliability in 99% of cases, when in fact 5 seconds is the typical waiting period necessary. Hooking allows automation to continue as soon as the application is ready, leading to superior performance.
In summary, hooking technology makes automation feasible and desirable in situations where automation might not previously have been considered suitable.
Disadvantages
Whilst hooking is an advanced technology, it is a technology designed to make the most of a bad situation where (as described above) there is no obvious or direct mechanism that allows easy automation. For this reason, it appears to be deficient when compared to some of these other preferred techniques. These caveats are listed below.
- Less control over how the application is launched
For technical reasons inherent in the nature of the technique, hooking can only be done by Blue Prism when the application is launched. For this reason the application must be launched by Blue Prism – the application can not be attached to once already running, as with alternative integration techniques.
- More work involved in creating business objects
The user will have to do some work to ensure that certain data in the object model are not confused. For example, Blue Prism has no way of knowing whether a piece of text obtained via hooking is part of a button say, or part of a nearby combo box. The user will have to exercise some care to avoid problems
For this reason, the user may be required to be inventive about how they interact with the target application, based on how it appears to work and what information happens to be available to Blue Prism via the hooking method – the information available will vary from application to application.
- No ready-made convenience methods
Because hooking does not act with respect to a specific toolkit and its features (in contrast to Blue Prism's Java Automation technology for example), it cannot provide a specific set of features designed for interacting with specific types of user interface element. Thus the user will have to do some manual work for simulating the selection of a combo box item (for example), whereas with a windows application Blue Prism can do the work of selecting a combo box item instead – the user need only issue the instruction via a Navigate stage.
When should I choose to use hooking?
In short: hooking is a last-resort technique. Use a more specific technique such as browser automation or Java Automation if available and applicable.
