If you can't find the solution in the Appian RPA documentation, contact the Appian support team.
The Appian team will provide this information when setting up your Appian Cloud site. You can also open a support case to request this information.
Our recommendation is to use a computer with 8 GB of RAM. This recommendation is especially relevant where the development machine includes a virtual machine that acts as a resource.
Yes, the agent can run on different resources, as long as it is not running at the same time.
We recommend creating robotic processes using the latest available version of Appian RPA.
The new versions are backward-compatible, meaning you can use robotic processes developed with previous Appian RPA versions.
Keep in mind that using previous versions will cause you to have fewer features since Appian RPA is continuously evolving to facilitate the development of robotic processes.
Events are triggered by the RPA console, resources, and robotic processes. All events are aggregated into the RPA console and accessible by system administrators.
To take action for a specific event type, create an action in the RPA console and map it to the desired event type. Additional configuration is available based on the action and event.
For example, you can create an action to send an email to the system administrators when a resource is running out of disk space.
Appian RPA is not offered in the Appian Cloud high availability (HA) configuration at this time. However, Appian RPA's availability doesn't affect other features in the HA configuration.
Learn more about high availability in the Appian Cloud.
You can find the complete Javadoc documentation in the Appian RPA console. Click Help > Javadoc in the console menu.
When the RPA agent starts and when robotic processes are executed, different Java libraries are loaded into memory in the Java Virtual Machine. Because these libraries are reused across the robotic process executions, they are not flagged for garbage collection. Therefore the memory usage does not significantly decrease upon completion of robotic processes.
To prevent the RPA agent going over its max amount of allocated memory, it's recommended to configure a restart when reaching a certain memory usage percentage. Refer to the question How can I take action on events in Appian RPA?
Confirm that the service account used to authenticate Appian and Appian RPA has the appropriate permissions to see the robotic process. An administrator can update these permissions in the Appian RPA Console on the Users tab.
No, it is not possible to start the RPA agent as a Windows service. It is recommended to configure the RPA agent to start when Windows starts. See how in the next question.
Yes, it is possible to add AppianRPAagent.exe to the start menu, so that when a session begins, the agent also starts.
Additionally, if you don't want Windows to ask for credentials, Windows can be configured with auto-logon. Read more information about this configuration.
Robotic processes require a started and unlocked Windows session to operate correctly.
The following options allow Appian RPA to unlock the Windows sessions in an automated way for the execution of robotic processes.
With this option, the Appian RPA agent unlocks the local session when the execution of the robotic process is about to start, and locks back the session after the execution ends.
To configure this option:
With this option, a "management" resource is used to unlock the sessions for all the other resources. Unlike standard resources, the management resource can't run robotic processes.
This kind of resource uses a plug-in that allows connection to other resources using the Windows Remote Desktop Protocol. As such, it requires connectivity with the rest of the computers where the resources are running.
To configure the unlocking plug-in, simply provide the list of resources and their credentials. These credentials can be encrypted.
Despite having these two options, we recommend connecting to the resources using a non intrusive system, such as a Virtual Network Computing system or a Remote Access Software.
Additionally, the Appian RPA Agent includes a feature that prevents locking the session due to inactivity. However, this does not prevent locking a session through a connection using RDP or by an explicit lock with Win+L or Ctrl+Alt+Del.
The execution of a robotic process requires both an Appian RPA resource and an Appian RPA console. It is not possible to run robotic processes without connectivity between the two.
Appian RPA robotic processes must be executed inside the RPA platform and the RPA framework. As such, a JUnit test framework is not a viable option to unit test robotic processes.
However, Appian RPA allows robotic process invocation through REST API. This feature, with tools like Postman, can offer an automated test system.
These tests could use unusual inputs, so the robotic process could work in different modes, testing different cases.
This means that the computer has either the Shift Lock key activated, the numeric keyboard blocked, or a key is being pressed. Under these conditions, the console can't execute the robotic process in this resource.
If a robotic process does not use the keyboard to enter data or does not move the mouse, the operating system does not register any user activity - even if the robotic process is performing calculation, reading files, etc. As such, the user's session may get locked during the execution.
To prevent the session from locking, it is recommended to use the method
windows.antiScreenSaver() when an operation can take several minutes to complete before the robotic process performs a key press or a mouse operation.
Confirm that the resource is set up properly. Two common problems are mismatched permissions or the agent isn't running and properly communicating with the Console. Take a look at the execution log to see the point in the process where the execution failed. Next time you manually execute a robotic process, enable screenshots so you can see what's happening on the resource before and when the execution fails.
Confirm that your robotic process code uses the cleanUp() method to reset the resource's environment after an execution. If the robotic process doesn't clean up after itself, the next execution may encounter conditions it doesn't know how to handle and fail.
Many modern web browsers update automatically, which can cause a robotic process to fail if it's using an older version of the webdriver. You can manually update the web driver to solve the issue. Alternatively, add the webdriver as a support file in the robotic process configuration or as a global support file if more than one robotic process references it.
More on the Appian RPA Browser module.
Appian RPA does not have a specific module for PDF handling. However, external libraries such as PDFBox can be easily integrated into any robotic process.
Add the dependency in the pom.xml of the project to access the external libraries:
1 2 3 4 5 <dependency> <groupId>org.apache.pdfbox</groupId> <artifactId>pdfbox</artifactId> <version>1.8.10</artifact> </dependency>
Appian RPA uses TLSv1.2, which is the current standard.
Credentials must be updated in the console each time they are changed in the target application.
The message can't be changed.
We recommend that the execution trace has the necessary information to know what the robotic process was doing to help show why it failed. It is better that this information is kept in the trace so it can be consulted in the future as a reference and does not depend on the email notification.
With this configuration, the robotic process continues to run as expected since you have not restricted its permissions. And because the user only has the authorization to see the objects with the permission "robot-X" , he or she only has access to this robotic process.
You can upload a ZIP file and check the "Unzip on server" option (it is checked by default). After uploading a ZIP, the tree of support files will appear as a single file. If we refresh the page, the tree will reflect the real structure.
The text of the output arrows for conditional actions are discrete values and case-sensitive. The output conditions in both the workflow and the source code need to match exactly. If the values don't match or use different cases, the robotic process will fail.
On This Page