Robotic Process Configuration

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.

Toolbar

In the upper right-hand corner of the robot configuration page, we can find different icons for the actions to perform upon the robot.

Icon Description
rpa-send-icon.png 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.
2232918.png 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.
2232889.png Copy the selected robot's settings to another robot
2232893.png Download robot configuration. Download a ZIP file containing the robot configuration, so it is possible to import it to the same or other consoles.
rpa-execute-icon.png Execute the robotic process
2232770.png Delete the robotic process

Change history

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.

rpa-change-history.png

Through these arrows we can navigate back and forth through the configuration versions that have been saved previously.

General information

The main information in this section is also shown as a summary on the manual execution screen.

rpa-general-info.png

  • Robotic process: Technical identifier assigned to the robot. This value is defined when creating the robot, assigned by the developer, and cannot be changed. This name will be used for creating folders both on the server and with the client, so therefore this is usually a technical name.
  • Name: Functional name for the robot, which will be displayed on every window and will be the name by which the user will identify the robot.
  • Spoken name: Name used when referencing the robot through voice commands.
  • Work items: Word that defines or identifies the items to be processed by the robot, such as bills, certificates, employees, customers, etc. Although not required, it is advised to define this section for each robot, to make it easier to understand the statistics by the user.
  • Priority: Execution preference of the robot with respect to the others waiting for resource availability. In the event of a tied priority, the first robotic process to be executed will be the one that was launched first.
    • 2232745.png Highest.
    • 2232705.png Very high.
    • 2232739.png High.
    • 2232734.png Normal (default).
    • 2232704.png Low.
    • 2232747.png Very low.
    • 2232699.png Lowest.
  • Default color: Color assigned to the robot by default to be shown in the schedule page, where you can see finished executions.
  • Description: Main characteristics of the process. This appears on the Execution page when someone launches the robotic process.
  • Integrated applications: Systems or applications taking part in the process.
  • Expected input: Description of the input that will be used by the robot. This input is set up on the "Instructions" section of this screen.
  • Expected output: Description of the output that the robot will produce as a result of the execution.
  • Disable new executions: By enabling this checkbox, the robot is disabled, preventing any scheduled execution.
  • Test executions: By enabling this checkbox, all robot executions are marked as test executions, unless it is changed when launching the execution.
  • Trace level: Refers to the minimum trace log level to be written into the robot execution log.
  • Simultaneous executions (queued and running): Maximum number of robot executions that can happen at the same time, both in status executing or queued.
  • Allow executions only at these days/hours: by enabling this checkbox, a scheduler is shown to set up the days and hours when the robot can run. Outside these days/hours, the robot will not run, and if you try to run them, the system will initiate an event to notify such a circumstance. To schedule the executions, specify a time range:
    • Days: you can choose on a day-to-day basis or select the days of the month.
    • Hours: you can select any or all hours of the day (00-23).
  • Remove old artifacts (days): Number of days after which artifacts generated by executions are removed in order to free disk space. The list of artifacts affected by this option are:
    • Inbound (instructions)
    • Images
    • Files of results
    • Video

Items

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.

Workflow

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:

rpa-workflow-example.png

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.

Actions

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:

  • Initial: this is the first action, the starting point of the workflow.
  • Generic: this is an action by which the robot must perform some specific task before continuing with the next action.
  • Conditional: this action represents a fork in the workflow. Based on the input, the workflow could proceed in different ways.
  • Final: this is the ending point of the workflow.

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:

Icon Description
2232766.png Add an informative note to the workflow. It does not affect to the workflow itself.
2232702.png View and associate Appian RPA libraries to the workflow.
2232714.png Create a start/end action.
rpa-task-icon.png Add a generic action (task).
2232755.png Add a conditional action (decision).
2232749.png Download a workflow image in SVG format.
2232721.png Save the changes made on the workflow.
2232754.png Undo the last action made on the workflow.
2232768.png Select all actions of the workflow and their relations.
2232711.png Export the selected actions and relations of the workflow.
2232732.png Import actions and relations into the workflow.
2232733.png Import from file.
2232701.png Reset the workflow's size.
2232722.png Set the workflow's zoom level at 100%.
2232685.png Zoom out of the workflow.
2232684.png Zoom in on the workflow.
2232763.png Aligns to the left all the selected elements in the workflow.
2232718.png Centers horizontally all the selected elements in the workflow.
2232771.png Aligns to the right all the selected elements in the workflow.
2232767.png Aligns to the top all the selected elements in the workflow.
2232774.png Centers vertically all the selected elements in the workflow.
2232725.png 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 951643.png to resize the action.

Once all this is done, our workflow should look like the following:

data-provider-workflow-1.png

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 2232768.png.

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:

  1. With the initial element selected, click on any of the connector points.
  2. Drag and drop on the destination element.
  3. The editor will assist you in "pasting" the arrow to the destination action.

To save the changes made on the workflow, click on the Save icon 2232721.png. You can undo the changes at any time by clicking on the Undo icon 2232754.png.

There are four groups that can be assigned to the different actions in the workflow:

  1. Sections: if the workflow contains subsections, the way to indicate it in the main workflow is by choosing this section.
  2. Methods: they are the methods written in the robot's code, specifically in the class annotated with \@Robot.
  3. Modules: this is a way to select methods not developed directly by an Appian RPA developer. They can be seen as default actions upon the elements the robot interacts with: Robot, Server, Keyboard, Execution, Smart delay, Window. Each of these methods explain what they do and those requiring parameters enable fields to be informed. rpa-action-detail-module.png
  4. Libraries: contains custom methods written by Appian RPA developers that are shared across multiple robots.

Methods

To associate a method with an action, click on the list icon 951644.png and pick the corresponding method from the drop-down list.

951645.png

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.

rpa-action-detail-method.png

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.

2236730.png

Modules

From the workflow editor, you can directly associate an API method with a specific action:

  1. Create the empty action
  2. Instead of associating a method of our code or a library, we must associate a method of those that appear in any of the subsections under the heading Modules.
  3. Depending on the selected method, the necessary parameters can be passed to the method for its correct operation.
  4. Remember you can link more than one module to the same action, as explained above.

rpa-action-detail-multiple.png

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.

Scripts execution

From the workflow, it is possible to call specific methods of the API to execute arbitrary code. Currently, only Groovy scripts are supported.

  1. In the Modules tree, select Robot -> Execute code or Robot -> Execute code with result.
  2. In the Language menu, only the option GROOVY appears.
  3. In the Code field, add the code to execute.

Sections

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 rpa-add-section-icon.png in the workflow header. When you add a section to the workflow, you need to specify its name. Use the Remove section icon rpa-delete-icon.png 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:

rpa-task-icon.png

Import a workflow

You can also import a workflow from a BPMN file.

To do so, click on the Import from file icon 2232733.png, 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:

Tag Workflow component
bpmn:process Section
bpmn:subProcess Section
bpmn:startEvent Init
bpmn:endEvent End
bpmn:task Action
bpmn:globalTask Action
bpmn:intermediateThrowEvent Action
bpmn:intermediateCatchEvent Action
bpmn:exclusiveGateway Conditional Action
bpmn:sequenceFlow Arrow
bpmn:dataObject Note
bpmn:dataStore Note
bpmn:dataObjectReference Note
bpmn:dataStoreReference Note
bpmn:message Note
bpmn:collaboration Note
bpmn:textAnnotation Note
bpmn:text Note

Saving a workflow

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:

  1. There are, at least, one initial action and one final action.
  2. All actions have associated text.
  3. All actions are interconnected through at least one transition.
  4. All actions have one and only one output transition, except conditional actions.
  5. All actions have one associated method.
  6. All conditional action's outputs have one associated literal. These literals must match each possible value of the return instructions present in the code of the method used. You can leave one output with no literal definition, assuming this case is the empty string option (""). When the associated conditional method returns a boolean, the literal for the connections must be either "true" or "false".
  7. Conditional actions' outputs are not repeated.

Permissions

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.

rpa-permissions.png

Instructions

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.

  • In the Instructions section, click Add instruction.
  • Choose an instruction type:
    • String: Text fields for different values that define the robot's actions.
    • Password: Text fields for passwords required during the process. Note: For passwords, we recommend that you use credentials.
    • Boolean: Checkbox that will enable or disable a specific aspect of the process.
    • Combo: dropdown field where it is possible to select one of the defined options. To define these options, you must write them, comma-separated, in the field Default value. The first written option will be the default value.
    • File: Button for attaching a file that will be used by the robot.

For example, if you choose a File instruction, when you run the robot, it will ask you to upload a file as input.

rpa-instructions.png

Enter a name for the instructions. Instruction names must start with a letter or underscore, and only contain numbers, letters, dashes (-) or underscores (_).

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.

rpa-execution-options-2.png

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.

Environment Variables

rpa-env-variables.png

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 description

rpa-sub-results.png

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:

  • CHOCOLATE ( 2236517.png ).
  • CORAL ( 2236514.png ).
  • CYAN ( 2236529.png ).
  • DARK_GRAY ( 2236511.png ).
  • INDIGO ( 2236523.png ).
  • LIGHT_GRAY ( 2236528.png ).
  • LIME ( 2236533.png ).
  • MAGENTA ( 2236526.png ).
  • OLIVE ( 2236521.png ).
  • RED ( 2236531.png ).

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).

Support files

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.

browser-module-support-files.png

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:

Icon Description
rpa-preview-icon.png By pressing on this icon, we can preview the image support files.
rpa-upload-icon.png This icon allows you to upload a new file to the server.
2232696.png 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.
rpa-rename-icon.png This icon allows you to rename a file/folder on the server.
2232700.png This icon allows you to create a new folder on the server.
2232735.png 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.

Access support files in code

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.

Global support files

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 2232759.png 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.

rpa-global-support-files.png

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:

Permission Folder Access Robot
app07 shared-folder-1 shared-folder-1 nodes.png
app08 shared-folder-1 shared-folder-1 nodes.png
  shared-folder-2 shared-folder-2 shared-subfolder-2.1 (D) robot-file-2-1.png robot-file-2.png robot-file-1.png
app12 shared-subfolder-2-1 shared-subfolder-2.1 robot-file-2.1.png robot-file-2.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.

Technical information

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

rpa-technical-info.png

In this section, you can find the technical information contained in the robot setup:

  • Technology: Technology in which the robot has been built: Java, AutoHotkey or Autoit. If you choose the latter, the form will only have fields for Executable and Version.
  • Repository: Maven repository where the robot code is located.
  • Group: Identifier for the group of the robot's Maven artifact.
  • Robotic process: Identifier for the robot's Maven artifact.
  • Version: Version of the robot's Maven artifact.
  • URL: Complete URL to the robot's Maven artifact, only necessary if previous fields are not specified.
  • Main class: The main class to be executed, that is, the input class for the robot.

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 2232766.png 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 rpa-dependency-icon.png 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.

rpa-dependency.png

Open in Github

On This Page

FEEDBACK