| This content applies solely to Appian RPA, which must be purchased separately from the Appian base platform. |
This page contains some frequently asked questions and solutions for Appian RPA.
Additional FAQs are available for Java modules:
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.
See System Requirements for more information.
No. Every resource must have a unique agent executable file installed.
See Agents for more information.
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 capabilities 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.
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 agent as a Windows service. It is recommended to configure the 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. You can allow Appian to unlock the Windows sessions in an automated way for the execution of robotic processes.
When configured, the 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:
For more information, see the Agent and Resource pages.
The execution of a robotic process requires both a resource and a console connection. It is not possible to run robotic processes without connectivity between the two.
Robotic processes must be executed inside the RPA platform and framework. As such, a JUnit test framework is not a viable option to unit test robotic processes.
However, Appian allows robotic process invocation through REST APIs. Invoking robotic processes with APIs alongside 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 browser actions.
Robotic processes dp not have a specific actions 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>
You could also use Appian's document extraction features.
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.
See Permissions for more information.
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.
