The agent is a software component that must be running on the machine where the robots are to be deployed and executed. It keeps the communication with the server to interact with the robotic process from the console. You can also start the execution of a robotic process directly from this component.
This page covers the steps to set up the agent and use it to monitor activity on the connected resource.
The steps we must follow to start up the agent are the following:
Appian RPA allows the deployment, configuration, and robots execution in one or several resources. A resource is a PC or virtual machine where robots are executed and requires an agent in execution in order to work.
Although the same PC could be used for developing and executing robotic processes, it is advisable that the development and the execution machine be different. That is, having another machine, physical or virtual, where the agent runs.
Since Appian RPA is compatible with the leading virtualization systems (Citrix, VMware or VirtualBox), the recommendation is to create a virtual machine (VM) in any of these systems to be a resource and execute robots.
If this second machine is not available or a VM could not be created (not recommended), it is possible to use development machine as the execution resource too and run there the first robot. We have to bear in mind that this setup must never be final.
To download the agent, we need to have access to the console to check if we have a resource available.
The steps to download the agent are the following:
The only requirement to run the agent on a resource is to have Java virtual machine (JVM) version 8 or higher. If it is not installed, consult the Manual Configuration topic.
If can't install JVM, it is possible to make the agent work using a version downloaded and located beside the agent itself. In this case, contact the Appian support team so they can provide a resource adapted to your needs.
To check that the agent is running, we must do it both from the resource and the console.
The agent icon color in the system tray appears red when the agent is connected to the console.
You can also select Element inspector in the menu to check whether the connection is established or not.
From the Resources tab, you can also confirm in the console that the resource's status is Online.
Once the resource is configured, the agent is running and ready to execute robotic processes.
Right-click on the agent's icon in the taskbar to view its menu.
The Robots menu will show you the list of available robots for this resource. Click on a robotic process to execute it. You should only run robots that do not have required input variables on their setup. If you launch a robot with required input variables, the process will require initial values before being executed. Without these values, the robot will not run properly.
Another option available in the context menu is the Element Inspector, which shows information that will help you develop your robotic process.
The Element Inspector is a tool that shows detailed information about the application elements with which your robots are going to interact (buttons, text fields, menus, etc.). The data provided are different depending on your robot's development strategy: keyboard commands, Windows API, image recognition (Falcon), etc.
Additionally, it informs you of the connection status of the resource with the server, the position of the mouse pointer on the screen, and information about the active windows and controls. This window is very helpful for finding out the position of any control that your robotic process needs to press.
By using the API, your robots can handle Windows controls by using their IDs. The Element Inspector can give you these values. To do so, you should place your mouse pointer over the control on the window (the active window), and its ID will be shown in the section Control > Identifier. With this value, you can use the ID to obtain a reference to that control from a robot and use it to read or enter data.
Note that IDs may vary depending on the operating system version. When you use this feature of the API, you should make sure you are running your robotic process in resources that use the same operating system version as the one used for its development.
Likewise, sometimes the component's ID cannot be retrieved, due to incompatibility with the operating system or the application itself. In these cases, you should avoid using Windows controls.
The Protect Desktop option in the context menu allows the desktop where the agent is running to be protected, covering the screen so no one will be able to see what's happening.
The window that appears covering the screen is an "invisible" window, meaning if the user right-clicks, he would see the desktop menu. To disable this window, we have to click in the zone where the taskbar should be and it will appear, allowing you to click in the agent again.
Select Password encryption in the menu to obtain a hash from a password in plain text. This feature enables you to include encrypted passwords in the configuration file jidoka.l4j.ini, if necessary. The client can detect if it is an encrypted password and will process it accordingly, thus protecting sensitive information.
The configuration file is optional, but if it exists, it must be in the same folder as client's executable file. Both the client and the file must share the same name, ignoring the extensions: <name>.exe for the client, and <name>.l4j.ini for the file.
The aim is to be able to customize client's JVM with values that are unknown at the time of being used, or with values that are expected to change throughout the robot's life. It is basically a properties file, in which each property takes up one line, with the same format as system properties definitions (-D<name>=<value>) when you launch a Java program from the command line.
Here are the most common parameters used in this file:
The agent is also able to unlock the resource's session where it is being run in two ways:
This master resource works performing a simple RDP connection to the resource to be unlocked. This unlock can be configured to be made automatically using the local plugins embedded into the agent.
When you launch a robotic process, the agent communicates with the server and downloads the libraries and resources needed for execution. This download will be done only for the first execution of that robotic process, since at that time no library has been downloaded. In subsequent executions, these libraries should be available on the resource on which the agent is running, and they will be downloaded only if they are not found. The number of libraries to download depends on the dependencies and modules used in our robotic processes' development.
It is important that the agent is in a folder whose full path has no blanks to prevent it from any problem during robotic processes' executions.
Let's assume the agent is in the folder C:\Jidoka. Within this folder, you can find the following files and folders.
├───anotherRobot (specific support files for the robot "anotherRobot")
.jidoka-cache: this is the folder in which the necessary libraries for the robot's proper operation will be stored.
Jidoka-workspace: this folder contains the individual directories of each robot. Within the folder Jidoka-workspace there will be as many subfolders as robots have been executed in that resource. A robot called Example will have an associated subfolder in C:\Jidoka\Jidoka-workspace\example, which is the folder where all components required for its specific execution will be downloaded, and the files created during its execution will be stored. The Appian RPA platform provides easy access to this folder programmatically, as you will see later.
On This Page