In Kofax RPA, you can create Robots that can automate website interaction, as well as work processes involving Windows and Java applications on your networked computers. Design Studio has a dedicated workflow language and steps for this purpose.

Robots

The workflow of a robot 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. To use a Robot , you need to call it from a Basic Engine Robot with a dedicated action step named Call Robot.

A Basic Engine Robot can contain multiple Call Robot steps, each with their own workflow. A single Robot can be reused by Basic Engine Robots, which significantly saves time when you work on multiple robots at the same time. The robot with a Call Robot step can be executed as any other Kofax RPA robot from a schedule, via the API, via Kapplets or manually during development or testing.

Workflow

The workflow is edited in Design Studio. In Design Studio, you can see a view of the robot and the applications being automated along with details on the robot state and a dedicated toolbar with buttons to control the robot manually. See Edit Robot for details.

On the menu, the Help button is available that includes links to the respective documentation and the Getting Started guides that walk you through the process of building a robot.

Steps

Steps are the basic building blocks of a workflow in a robot. In the Robot, 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 Robot Steps.

Steps 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

One of the purposes of a Robot 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 automation by connecting to Desktop Automation Service running on remote devices, unless the device is running a terminal or other built-in driver, where the connection is direct from the robot. For details about handling devices and setting up the agents, see Configure Desktop Automation Service.

Application Tree

Kofax RPA provides several ways to populate the application tree. By default, Kofax RPA detects the type of application the robot is working with (such as a Windows application, terminal, built-in browser, and so on) and automatically forms the tree for this application. For some Windows applications, Kofax RPA provides extended support. For example, when working with Internet Explorer in Design Studio, Kofax RPA turns on extended Internet Explorer support to retrieve DOM (Document Object Model) tree as it provides a more accurate result in the application tree.

To distinguish between attributes that Kofax RPA receives directly from the applications and attributes that Kofax RPA adds, a set of "derived attributes" is provided. This is done to prevent name clashes between different attributes. Kofax RPA adds the bounding box (x, y, width, height ) as derived attributes. Derived attributes are displayed in the tree prefixed with "der_" and can be used in finders and for extraction.

The following table lists and describes derived attributes that can be used in the application tree.

Derived attribute	Description
For all elements
der_x	X coordinate of the upper left corner of the element.
der_y	Y coordinate of the upper left corner of the element.
der_width	Width of the element (bounding box of the element).
der_height	Height of the element (bounding box of the element).
der_rendered	Set to "y" (for "yes") when the element is rendered on the page.
der_isOffscreen	Set to "true" when the element is not visible on the screen. The page should be scrolled to make the element visible.
For form control (input) elements
der_value	Used for the "email," "text," "number," "range," "tel," "time," "url," "search," "date," "datetime-local," "week," "color," "month," and "textarea" input elements.
der_checked	Used for the “radio” and “checkbox” input elements. Can be "true" or "false," depending on whether the element is selected or cleared.

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

Robots Compared to Basic Engine Robots

Kofax RPA 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, Robots are designed to automate new dynamic websites and remote applications where the state resides in the application. In this case, the state is external to the robot.

Execution of steps in Robots moves forward only. When automating a remote computer, the state of the execution is on the remote device and it is not possible to undo by going back in the workflow, except for a group of Extract Value and Convert Value steps. As a consequence, when designing your workflow, newly inserted steps are not executed until you explicitly select to do so in the Edit Robot.

Important Branching, as it is designed in Basic Engine Robots, does not exist in Robots. It only occurs as part of composite steps.

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

In Robots, 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 Robot, 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.

Robots have 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 robot 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 and finders are described in Finders.

See Get Started to begin process automation and Robot Steps for the list of action steps.