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 Microsoft Edge in Internet Explorer mode 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	Class	Description
der_x	General	X coordinate of the upper left corner of the element.
der_y	General	Y coordinate of the upper left corner of the element.
der_width	General	Width of the bounding box of the element.
der_height	General	Height of the bounding box of the element.
der_tree_mode	General	Specifies the tree mode that defines how the tree for applications is populated. Use "ISA" for ISA-generated trees, "Windows" or "None"for DAS trees, or "Auto" for other drivers.
der_original_node_name	General	Specifies the node name in the tree that is derived from the entity it describes. If this name is not XML-compliant, it is normalized and the original derived name is passed as a value of this attribute.
der_index	Table view	Specifies the column index. We recommend that you do not use this derived attribute in finders. The values of this attribute are subject to change between versions or can be generated based on dynamic sources. For example, the possible source of these fields is the output of SQL queries (and stored procedures) that can be changed by the user or their database administrator at any time.
der_rpa_type	Table view	Specifies the RPA data type best matching the data type in the database. We recommend that you do not use this derived attribute in finders. The values of this attribute are subject to change between versions or can be generated based on dynamic sources.
der_rendered	CEF	Set to "y" (for "yes") when the element is rendered on the page.
der_isOffscreen	CEF	Set to "true" when the element is not visible on the screen. The page should be scrolled to make the element visible.
der_isa	CEF	Set to "y" (for "yes") when the element is generated by ISA.
der_value	CEF	Used for the "email", "text", "number", "range", "tel", "time", "url", "search", "date", "datetime-local", "week", "color", "month", and "textarea" input elements.
der_checked	CEF	Used for the "radio" and "checkbox" input elements. Can be "true" or "false", depending on whether the element is selected or cleared.
der_visible	Windows	Used for native Windows graphical elements. Can be "true" or "false", depending on whether the element is visible or not.
der_subdriver	Windows	Specifies the Windows subdriver that generated the subtree. Possible values are "excel", "ie", "sap", or "java".
der_SubWindow	Windows	Indicates that the subtree in a Microsoft Edge in Internet Explorer mode window is generated from an external component. Possible values are "Silverlight" and "JavaApplet".
der_handle	Email	Internal reference used to identify the email. We recommend that you do not use this derived attribute in finders. The values of this attribute are generated dynamically.
der_is_big_value	Database	Set to "true" if the column is of BLOB or equivalent database type.

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.

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.