This page dives into how to add or modify a robotic process's configuration. The configuration contains most information regarding the process, including the workflow. A robotic process configuration also includes technical information such as the repository and technology that power the robotic process.
When you create a robotic process, you'll specify its configuration. You can edit a robotic process configuration at any time.
For any changes you make on this page, be sure to click the Save button at the bottom of the page.
In the upper right-hand corner of the robot configuration page, we can find different icons for the actions to perform upon the robot.
|Send robotic process to another console. When clicking on this icon, a pop-up window will show up where we must introduce the information about the destination console URL, as well as the credentials for a valid user in it.|
|Clone the robotic process. The new robot will keep the characteristics of the original, and then you will be able to edit them. This way, you save time in comparison to creating a robot from scratch.|
|Copy the selected robot's settings to another robot|
|Download robot configuration. Download a ZIP file containing the robot configuration, so it is possible to import it to the same or other consoles.|
|Execute the robotic process|
|Delete the robotic process|
At the top of the configuration page, after the bread crumb indicating the robot's name, we can see a set of icons with an arrow and a clock. Through this arrow, we can go back to previously recorded versions of the configuration, thus recovering old configurations that have been overwritten for whatever reason.
Through these arrows we can navigate back and forth through the configuration versions that have been saved previously.
The main information in this section is also shown as a summary on the manual execution screen.
The Appian RPA Robots operate on an item, which is the element to be processed. As mentioned above, the type of item depends on the tasks the robot must accomplish. Typically, an item is associated with an element within a set of elements with similar characteristics.
Some examples of an item could be a candidate who has sent his résumé, and whose name and contact information must be processed; the employee, for a robot that makes the payments of salaries; or a product, for a robot that checks the stock in a store's warehouse; or even a citizen for a robot that must gather data from a census registry.
In short, the item identification will depend on the business process or the task to be performed.
Robotic processes follow workflow, or a sequence of tasks. The workflow is a very important concept in the Appian RPA platform because it is the guide that leads the robot's operation, determining its starting point and with which task it should finish, driving it through a series of tasks and actions.
The workflow of an Appian RPA robotic process can be compared to a sequence of tasks performed by a human. Visually, the workflow makes it easy to monitor robot's operation from the console. It enables a global view of all execution phases and allows you to analyze what action the robot is on, when it began, its duration, and its result. The console draws the workflow as the corresponding robot operates. It allows, for example, knowing in real time what action of the workflow the robot is on.
For example, let's suppose one person should perform a task which involves gathering names and contact information from people who have sent their CV though the company's website, and saving that data on a text document, for example, by using the notepad, using one line for each name.
Assuming that the data source will always contain at least one résumé, a valid workflow could be the following:
Firstly, that person should open the notepad, then he or she should read a résumé, then he or she should write the candidate's name and contact information in one line. Then, if there were more résumés, the cycle should go back and read the next curriculum. And if there were no résumés left, then the document should be saved and the notepad should be closed, reaching the end of the whole process.
Defining the workflow is the first and one of the most important steps for building Appian RPA robotic processes. A good design will make the robot easier to develop.
In this section of the configuration page, you'll define the workflow and associate actions with the robot's code, so that each action corresponds to one method in the class that implements it. These actions can be:
When you are developing a robotic process, typically, it's in the first action where variables are initialized and everything needed for the robot to accomplish its task is prepared. Then it will go through each action in the workflow, until it reaches the last one, and the robot's execution ends. The difference between an initial action and a final action lies in their transitions. An initial action has no input transition and one output transition. A final action has at least one input transition and no output transition.
Actions connect through arrows, representing the workflow's transitions.
There are a number of actions you can create in a workflow. You'll find the create action buttons along side other options in the Workflow section:
|Add an informative note to the workflow. It does not affect to the workflow itself.|
|View and associate Appian RPA libraries to the workflow.|
|Create a start/end action.|
|Add a generic action (task).|
|Add a conditional action (decision).|
|Download a workflow image in SVG format.|
|Save the changes made on the workflow.|
|Undo the last action made on the workflow.|
|Select all actions of the workflow and their relations.|
|Export the selected actions and relations of the workflow.|
|Import actions and relations into the workflow.|
|Import from file.|
|Reset the workflow's size.|
|Set the workflow's zoom level at 100%.|
|Zoom out of the workflow.|
|Zoom in on the workflow.|
|Aligns to the left all the selected elements in the workflow.|
|Centers horizontally all the selected elements in the workflow.|
|Aligns to the right all the selected elements in the workflow.|
|Aligns to the top all the selected elements in the workflow.|
|Centers vertically all the selected elements in the workflow.|
|Aligns to the bottom all the selected elements in the workflow.|
Double click an action to name it. Click and drag on the double arrow icon to resize the action.
Once all this is done, our workflow should look like the following:
It is possible to work on two or more actions at the same time, for example when cutting, pasting, or deleting.
To select more than one action simultaneously, hold the Ctrl key (Windows) or Command key (Mac) and click each action to select. To select all actions, click the Select all icon .
You can move, delete, or copy and paste the selected actions. You can also export them, which will make the selected actions serialized, producing a string that can be stored in a file or shared by any means that allows plain text communications. You can use this string to import multiple actions at a later time. A text field will ask you to enter the values serialized by the export option.
When you import actions, their initial position in the editor is kept. Therefore, some actions could overlap with others, even hiding those previously in the editor. In these cases, you should select them and move them apart to check if the import was successful.
To transition between the actions, add the arrows to make connections:
To save the changes made on the workflow, click on the Save icon . You can undo the changes at any time by clicking on the Undo icon .
There are four groups that can be assigned to the different actions in the workflow:
To associate a method with an action, click on the list icon and pick the corresponding method from the drop-down list.
Then on the detail window, you will see a tree view of the methods available for the robot and the associated libraries that can be assigned to the action. On the right-hand side, you can view the code of the selected method before clicking on the accept button.
If the method does not yet exist, you can add it manually by writing its name. Before running the robot, you should deploy the corresponding code including the new method. You can also set "No action", assigned by default, if you don't know what method will be associated with the robot yet. Actions with such value will be ignored during robot execution.
Actions with the value "No action" selected will be displayed using a specific format on a grey background.
You can add multiple methods in one action. Click the action icon to add more. Each method to select can be can be in sections Methods, Modules or Libraries. Methods are executed in the order they appear for that action.
From the workflow editor, you can directly associate an API method with a specific action:
So, for example, in the previous illustration we would have an action waiting for the screen to appear on an image and then click on it.
From the workflow, it is possible to call specific methods of the API to execute arbitrary code. Currently, only Groovy scripts are supported.
You can define sections in your workflow. Sections allow you to break down complex actions into a set of actions, with their own workflow associated, and link them with non-conditional actions in the main workflow.
By default, every workflow has at least one section, called the main section. Apart from this main section, you can define multiple sections inside the same workflow. There are no restrictions on the number of nested sections that can be incorporated into the workflow.
Create a section using the Create section icon in the workflow header. When you add a section to the workflow, you need to specify its name. Use the Remove section icon to delete a section.
You must define at least initial and final actions, though for simplifying its operation you can assign the No action option, so that the workflow is correctly defined visually, but no code is needed for those actions.
When you associate a section to an action, the icon will change its appearance in the workflow, and will show as follows:
You can also import a workflow from a BPMN file.
To do so, click on the Import from file icon , which will show a pop-up to specify the BPMN file to import.
The console will process the file, reading the BPMN tags defined on it, making the proper transformations to generate the workflow. In the following table we can see these transformations:
When a workflow is saved, some checks are performed. These checks may send a warning message, but the workflow is still saved though, it may not be correct. Appian RPA checks that:
This is the area where you will assign permissions to the robotic process.
Permissions will determine what users will be able to view and control the process. The permissions you assign to the robotic process should also match the resource on which it will be executed. If we don't assign the proper permission, the Appian RPA Platform won't be able to find any appropriate resource to execute the robotic process and users won't be able to see it either.
By default a robot inherits the permissions of the user that created it. Learn more about permissions.
In this section, you can add input fields for the robot's execution. Each time the robotic process is launched from the console, instructions specify what the user should enter as input data.
For example, if you choose a File instruction, when you run the robot, it will ask you to upload a file as input.
The instructions can be required (by enabling the checkbox Required?), and in such case, the robot won't run unless we provide the corresponding instruction at the time of launching it.
When several instructions are defined for a robot, it is possible to manually reorder them by dragging the row containing the instruction and dropping it on the desired position.
Once we have set up an instruction from the Appian RPA Console, you can access it from our robot's code. To do so, we should obtain the appropriate values from an instance server and process them.
To access all the instructions, use the method getParameters() from the instance server and depending on whether the instruction type, we will adapt our code accordingly.
Below you can find an example of the way we could process a File instruction:
1 2 3 4 String path = Paths.get( server.getCurrentDir(), server.getParameters().get(FILE_NAME)). toRealPath(LinkOption.NOFOLLOW_LINKS).toString();
We obtain the server's parameter whose name is defined in a constant FILE_NAME. Again, by using the instance server, we obtain the current folder in which the robot is running, to access the path we need to process the file.
The files that are sent to the robot as an instruction will be available on the resource. They are saved in the corresponding robot's folder within the workspace created by the Appian RPA Agent.
The other types of instructions will be obtained through server.getParameters().get("parameter_name"). Only when we work with boolean we will have to make the conversion from String.
You can define environment variables, which are sent to the robot as "key-value" pairs. The difference is that they are sent in all the executions but they are not requested in each execution. To modify them it is necessary to modify robot settings. This facilitates having different configurations in different robot environments (development, production, etc.)
Sub-results are used to categorize the items results, making it possible to differentiate items already classified as OK or WARNING. The colors and statuses appear in the results column on the list of executions.
This items categorization is shown in the following list:
An example could be, for a specific WARNING, to know its different causes, as technical problems (sub-result CORAL) or data problems (sub-result CYAN).
In this section, you can find the folder structure containing the technical and configuration files that a robot needs for proper operation. Support files help you avoid having to add files in the robot's code as resources, so the code is leaner and helping deploy it much faster. Working this way also allows you to change the files' content (neither adding nor removing them) without affecting the robot's deployment.
Here you can upload new files to the server, even ZIP files that will create the folder structure they contain if you previously enable unzipping through the corresponding checkbox.
Files and folders will be displayed in alphabetic order. The folders will be sorted first and then the files.
You can execute the following actions in the resources in tree view that show the folder structure:
|By pressing on this icon, we can preview the image support files.|
|This icon allows you to upload a new file to the server.|
|This icon allows you to download the file or folder from the server. When downloading a folder, a ZIP file will be created with the folder and its whole content.|
|This icon allows you to rename a file/folder on the server.|
|This icon allows you to create a new folder on the server.|
|This icon allows you to delete a file or folder on the server.|
In addition, by dragging and dropping any folder or file, you can move them across different locations in the folder structure on the server.
When you upload a ZIP file, you can specify if you want it to unzip on the server, thus creating the corresponding folder structure it contains upon upload completion.
To access the support files from your Java code, you will have to proceed the way you would do to obtain an uploaded file when running a robot (see Instructions).
The following shows an example of how we could obtain the Path to access a file uploaded in this section.
1 2 3 4 5 Path path = Paths.get( server.getCurrentDir(), "folder", FILE_NAME). toRealPath(LinkOption.NOFOLLOW_LINKS);
In the previous code snippet, we assume that we have a folder called "folder", and a file whose name is defined in the constant FILE_NAME.
If you want to share files between different robots, you can access the global support files. To do so, click on the Support files icon located on the Robots window.
Essentially, this window is the same as the one displayed on the namesake section in robot setup, and hence their behavior is very similar regarding the uploading, downloading, moving and renaming operations for files and folders.
From a visual point of view, the difference lies in how you define which robots can access which files.
As you can see, there is a folder with files. To give a robot access to the global support files, it should have a permission with the same name as the folder it is trying to access. This folder will contain the folder structure and files the robot can use.
The table below shows the robots, their permissions, and the folders and files they can access, according to the previous picture:
|shared-folder-2||shared-folder-2||shared-subfolder-2.1 (D) robot-file-2-1.png robot-file-2.png robot-file-1.png|
Robots app07 and app12 can access the content of only one folder of the global support files since each of them has the proper permission. Remember that you cannot use the period character '.' in a permission tag, but you can use the hyphen character '-'. So to access the folder shared-subfolder-2.1 you should specify the permission shared-subfolder-2-1.
Robot app08, on the other hand, can access both folders. One of them contains only one file, whereas the other one contains one file (robot-file-1.png) and one folder (shared-subfolder-2.1). The latter contains, in turn, two files.
At the end of the page, you can see the definition of the repository where the project has been automatically deployed. To make this link work properly, it is necessary to have previously deployed the robot binaries in the defined Maven repository. This is done using the following instruction:
mvn clean deploy
In this section, you can find the technical information contained in the robot setup:
It is possible to select the robot's main class if the Maven artifact's information has been setup properly. To do so, click on the Select main class icon and select the main class from the list of all classes available in the Maven artifact.
In case some of the fields of the Maven coordinates associated with the artifact are not correct, an error message will show up as a warning. If no classes are shown, check that the artifacts successfully deployed to Maven, as well as the Maven configuration is correct.
Use the Check dependencies button to validate that the configuration of the robot is correct in terms of dependencies and the versions of these dependencies. A window appears that shows the artifacts that have a different version in the robot and in the agent.
On This Page