Requires a Desktop Automation License

Device Automation lets you create robots that can automate work processes involving Windows and Java applications on your networked computers. Device Automation is a part of the overall Kapow automation capabilities. Because Device Automation is substantially different from website and database automation, Design Studio has a dedicated workflow language, editor and steps for this purpose.

Device Automation Workflow

Device Automation workflow is a sequence of steps that are executed one after the other. The steps model how a user would interact with the application that is being automated. Device Automation workflows are contained inside a single step action called Device Automation, which itself is part of a normal robot. A robot can contain multiple Device Automation steps, each with their own workflow. A robot can contain other types of steps. The robot can be executed as any other Kapow robot from a schedule, via the API, via Kapplets or manually during development or testing.

Device Automation Editor

Device Automation workflow is edited in the Device Automation Editor. The editor presents a view of the robot and the applications being automated along with details on the robot state and buttons to control the robot manually. See Device Automation Editor for details.

Steps

Steps are the basic building blocks of a workflow in Device Automation, just as they are in website Robot Language. In Device Automation, all steps have one entry point and one exit point, except for a few steps that have no exit point. Some steps are simple steps and merely perform one action such as moving a mouse or pressing a key. Other steps, called composite steps, may contain additional steps. Composite steps are used to group steps that belong together or to handle branching and other ways to control how execution proceeds. For the complete list of steps, see Device Automation Steps.

Steps in Device Automation are typically granular and handle smaller tasks. For example, there is no inherent error handling on every step type. Instead, dedicated steps exist specifically to handle errors during execution.

Devices

The purpose of Device Automation is automated control of applications. The applications run on devices (computers, servers or virtual machines) that can be remotely accessed over a network. A robot performs Device Automation by connecting with an Automation Device Agent running on the remote device, unless the device is running a terminal, where the connection is direct from the robot. For details about handling devices and setting up the agents, see Configure Automation Device.

Widget Tree

Kofax Kapow provides several ways to populate the widget tree. By default Kapow detects the type of application the robot is working with (such as Windows application, terminal, built-in browser, and so on) and automatically forms the widget tree for this application. For some Windows applications Kapow provides extended support. For example, when working with Internet Explorer in Design Studio, Kapow turns on extended Internet Explorer support to retrieve DOM (Document Object Model) tree as it provides a more accurate result in the widget tree. In order to distinguish between attributes that Kapow receives directly from the applications and attributes Kapow adds, a set of "derived attributes" is added. This is done to prevent name clashes between different attributes. Kapow adds the bounding box (x,y,w,h) as derived attributes to use in finders and for extraction. Also, the built-in browser adds "rendered" as a derived attribute. Derived attributes are displayed in the tree prefixed with "der_" and can be used in finders.

You can turn off extended application support if you experience issues working with a particular application.

Device Automation Workflows Compared to Website Robots

Kapow was originally designed for accessing HTML at a time when HTML pages were mostly static. In those cases the state of the application (web page) can be tracked internally in the robot. By contrast, the Device Automation functionality is designed to automate remote applications where the state resides in the application. In this case, the state is external to the robot.

Execution of steps in Device Automation move forward only. The state of the execution is on the remote device and it is not possible to undo by going back in the workflow. As a consequence, when designing your workflow, newly inserted steps are not executed until you explicitly select to do so in the Device Automation Editor.

Branching only occurs as part of composite steps, such as the Conditional Step. The branches are alternative branches, so only one branch is chosen when a workflow is executed. This differs from website robots where branches are executed sequentially one after the other, and the state is reverted at the start of each branch.

In Device Automation, error handling differs because it is not specified for every step. Instead, a try-catch step explicitly catches errors occurring within its scope and defines how to handle them.

In general, when designing a Device Automation workflow, think how a user interacts with the user interface of the application you are automating. For example, if you need to type some text in the text field, first click the field and then insert a step that types the text.

Device Automation has features that allow the robot designer to design the automation to gauge the external state of the application and react appropriately. For example, a click on a button can be made to wait until the button appears. Or a step can detect that an application is already started, to avoid starting another instance. When you design a workflow, guards and finders are used to wait for specific states of the application, ensuring that the robot finds the required elements and interacts with them as expected. Guards are described in the Guarded Choice Step and finders are described in Finders in Device Automation.

See Get Started with Device Automation for steps to automate remote devices.