|This content applies solely to Appian RPA, which must be purchased separately from the Appian base platform.|
A digital worker needs a workspace, just like a human worker does. The environment in which the digital worker completes the robotic process is known as a resource. A host machine can be a physical machine, such as a separate computer, or a virtual machine on a cloud server.
To start an execution, the resource needs certain data or information from the server. The resource communicates with the server through an agent, which is a program you'll install on the resource. Agents are required to be up and running for robotic processes to execute properly and communicate the results back to the console.
This page describes the Resources tab in the Appian RPA console, which you'll use to setup and monitor resources.
Required role: Administrator
Create a resource for each physical or virtual machine (VM) that will run robotic processes. Every resource has a corresponding agent, which can only be used on one machine.
Multiple resources can map to the same machine. For example, if you connect your personal computer to both your development and staging environments for testing purposes, you will create two resources.
Avoid trying to run multiple robotic processes on the same machine at the same time because they will likely conflict with each other.
When running your robotic processes in a production environment, we recommend using a dedicated machine, whether that be a provisioned virtual machine (VM) or physical machine, as the resource.
To add a resource:
To execute a robotic process on a new resource, remember to install the agent.
Be sure to add the resources to your Appian environment's firewall allow list, if applicable. The robotic process may not be able to execute successfully if the firewall blocks communication between the agent, resource, and server.
You can use a VM as a resource to run robotic processes. By default, VMs may timeout and become unavailable after a period of inactivity. To ensure the resource remains available, you may want to complete additional configuration when creating a VM resource.
Microsoft Remote Desktop users can configure the following to prevent VM resources from timing out:
Additionally, ensure that the agent you have downloaded on the resource has administrator privileges to allow them to unblock sessions as needed.
Required role: Any
The List of resources table contains all resources available to you based on your permissions. You can access the details of a resource by clicking on any of its columns.
The resources are listed in alphabetical order in a grid with the following information:
|Production||A production resource has no restriction at all.|
|Development||A development resource is not permitted to execute robotic processes that take more than 2 hours.|
|Development without restrictions||In the same console there can be, at most, one resource of this type.|
|Remote development||A resource specifically configured to remote development, where the resource is the one connecting to the developer.|
|Windows resource||The agent is executed on a Windows operating system.|
|Linux resource||The agent is executed on a Linux operating system.|
|macOS resource||The agent is executed on a macOS operating system.|
You can perform several actions on resources in the list. Available actions depend on the resource's connectivity, whether the agent is started, and on whether its status is "Online" or "Offline."
|Switches off a resource with connectivity and "Online" status.|
|Switches on a resource with connectivity and "Offline" status.|
|Removes the session currently associated with the resource. Useful when we do know that the session doesn't exist anymore, but the console needs more time to be sure of that.|
|Allows you to assign permissions to the resource.|
Required role: Developer or Administrator
RPA components rely on shared permissions for security. Users, robotic processes, and resources must have tags in common to see and interact with each other. To assign or edit permissions for a resource, see Assign or Edit Permissions.
Looking to edit permissions for multiple resources? Save time by modifying resource permissions in bulk.
Required role: Any
Depending on whether the resource has connectivity, and on whether its status is "Online" or "Offline", different icons will be available.
|If the resource is offline and its license has not expired, you can download the agent to install it on your computer.|
|Launch the remote-control screen for a resource with connectivity. If the resource was disabled, it may look like it is "Offline" but even so you can access it remotely.|
|Disables the local plugins of the agent. It only works if the agent, in the moment of its creation, plugins was added in it and these are enabled.|
|Enables the local plugins of the agent. It only works if the agent, in the moment of its creation, plugins was added in it and these are disabled.|
|Lock the input from the keyboard and the mouse on a resource with connectivity. Only available if the agent is executed on the resource using an administrator profile.|
|Unlock the input from the keyboard and the mouse on a resource with connectivity. This action works only if the agent is executed on the resource using an administrator profile.|
|Send an agent for remote debugging. A new executable is downloaded on the resource, named jidoka-remote.exe, specifically designed for debugging robots remotely when you cannot debug them directly on the port involved.|
|Execute the agent for remote debugging.|
|Stop the agent from remotely debugging (only on the resource under remote debugging).|
|Executes the agent for remote debugging (JJDWP). This debugging is less common and requires its own execution setup. By clicking on this icon, a pop-up window will ask you for the IP, port and timeout for the connection.|
|Stops the agent from remotely debugging (JJDWP). Unlike the non-JJDWB version, this debugging must be stopped from the resource that launched it, and not from the resource being debugged.|
|Restart the agent, so that it can initiate itself and prevent, among other things, low memory problems in the computer where it is running, that is, the resource.|
|Completely remove the resource from the console. This action cannot be undone and is only available for "ADMIN" profiles.|
This feature has been deprecated and may be removed in a future release.
In the Container configuration section, you can configure two different types of containers for a resource: Docker and VirtualBox. Once the configuration is done, the console is able to integrate with the container to start and to stop it.
Additionally, it is possible to use Kubernetes as a Docker containers manager.
For Docker, you have to fill the following fields:
Using these configurations, the console generates a Docker command to send to the machine to start or stop it.
For VirtualBox, you have to fill the following fields:
Using these configurations, the console generates a VirtualBox command to send to the machine to start or to stop it.
Required role: Developer or Administrator
You can remotely visualize and operate the desktop on which the robot is running.
To start monitoring, click on the Monitor icon (), which will show you a set of icons that allow you to perform certain actions on the desktop where the robot is executing.
|Take a screenshot|
|Request the log file. It allows you to download the local error log.|
|Open the scripts editor Groovy. It allows you to execute Groovy code on the client.|
|Control remotely. It will show the position of the mouse pointer on screen, allowing you to click and drag elements on the desktop as usual. By enabling it, you will also see a text box where you can send text to the resource as well as the coordinates of the mouse pointer.|
It is important that you click on the Monitor icon again after you have finished monitoring the resource. This way the agent will consume fewer resources while there is no need for monitoring.
When you restart services, a request is sent to the agent for it to try to restart the open connections with the console. This functionality should only be used under maintenance tasks of the agent, as it is more advisable to relaunch the agent from the console and manually restart the agent, in this order, when you detect any issue with its operation. You can also restart the resource automatically.
The agent's requirements for RAM memory are low. However, depending on the version of the operating system, RAM available, the number of robots in execution, and maximum memory assigned to the agent, memory usage may increase too much. To avoid this situation, you can make a resource to restart automatically when a specified percentage of the total memory is exceeded.
For example, suppose you want to specify on a 2GB memory resource, that the agent should restart whenever the memory used by the agent exceeds 1.6 GB, that is, 80% of the total.
On the resource details, enter that percentage of memory not to be exceeded. This will trigger an event to restart the agent whenever it is exceeded. Events are explained in detail on the Monitoring page.
In the event the server goes down unexpectedly, administrators can configure Appian RPA to disable resources upon restart of the RPA server to ensure robotic processes will not run until an administrator has verified the resource is in a clean state.
To allow Appian to disable unclean resources on start up:
On This Page