|This content applies solely to Appian RPA, which must be purchased separately from the Appian base platform.|
Appian's automation framework is built for speed and flexibility, enabling your application and robots to act on information immediately. To make it even easier, you can integrate and orchestrate your robotic workforce within your application's process model workflows. Assign individual units of work, launch multiple executions at once, assign execution priority, and configure retry behavior in one place. You can build process models to handle exception logic and manage data passing to and from the robotic process to support a sophisticated human-in-the-loop automation practice.
This page recommends patterns for integrating Appian process models and robotic processes. The low code patterns described below are designed to be fast, scalable, and reliable ways to communicate and process data.
In order to design robotic processes efficiently and in low code, it's essential to understand which pieces and steps of the robotic process should be in Appian as process models or expressions and which ones should be within the robotic process workflows.
If a step or action can be designed in low code in Appian and exposed as expressions or process models, use Appian expressions or process models. Otherwise, use Appian RPA.
The patterns below are broken in different categories:
As documented in Ways to Execute a Robotic Process, a robotic process can be started using either the Execute Robotic Process smart service, the Call Integration smart service, or the Execute Robotic Process integration object.
To simplify the workflow design, it is recommended to start robotic processes using the Execute Robotic Process smart service. This smart service executes robotic processes synchronously and allows designers to save the outputs of the robotic processes in process variables. Launch a single robotic process execution using this smart service, and use it to retrieve the results in Appian.
In the process modeler, this pattern appears as shown below:
When interacting with external systems, it is common for a robotic process to perform calculations and business logic, such as validating the data being displayed or calculating data to be entered in the next step of the robotic process.
To perform these calculations and logic, use Appian expression rules invoked using the Evaluate expression action in the Appian Services menu.
Creating an expression rule, as opposed to writing the logic directly in the expression field of the Evaluate expression action, provides additional benefits such as reusability and unit testing.
Use the Evaluate expression action to execute an expression rule that was previously created in Appian.
Due to the fragile nature of front-end automations, it is likely that your robotic processes will sometimes run into unplanned issues during execution. For example, the target application to interact with may run into intermittent bugs for certain executions. In these circumstances, you can use your process models to orchestrate the exception behavior, retrying the execution or notifying a user of the issue.
To manage unplanned exceptions, the process model must use a variable to record the end result of the RPA execution. The Execute Robotic Process smart service provides a
Success output variable by default, which you can use to route the process model workflow based on whether or not the RPA execution was successful. For more granular exception handling, you may find it useful to build additional exception logic based on the part of the robotic process that was unsuccessful. To do this, you'll create a robotic process variable to track each action's success or failure.
In your robotic process, create a robotic process variable:
As you build the robotic process workflow and configure actions, store results in this variable. For example, when the robotic process successfully signs into an application, you could update the status to say
"login successful". Configure subsequent actions to update the same variable to describe the state as the execution proceeds.
This information can be returned to the Appian process model and used to build exception logic to address when a specific action in the robotic process fails.
For example, if the robotic process isn't able to access a web portal, it might be that the website didn't load in time. Build an exception route in the process model to retry the execution. Alternatively, if the execution fails at a point in the process that requires human intervention, you can build a route in the process model to send a user input task to manually manage the exception.
When a robotic process runs into a business exception, such as manual approval is needed or data is missing, the robotic process must terminate and notify a user of the exception.
To do so, the robotic process must return the exception and related data to the Appian process model so that the user is notified with relevant information.
In your robotic process, create two robotic process variables:
These robotic process variables are the same ones used to manage other exceptions as documented in the previous pattern.
Populate these two robotic process variables before terminating the robotic process to indicate a business exception.
In the Appian process model, use an XOR gateway to evaluate the values of the status flag returned by the robotic process and route the workflow accordingly. Below is an example where a business exception in the robotic process triggers a task to a user for further troubleshooting.
Appian's low code data management capabilities extend to robotic processes that process items from a list. Use an Appian process model to loop through items and use the Execute Robotic Process smart service to start robotic processes sequentially or in parallel.
Launch individual executions from a process model using the Execute Robotic Process smart service with multi-node instances (MNI), where one robotic process execution = one item processed. Depending on the configuration of MNI, robotic processes can be started sequentially or in parallel.
When started in parallel, the robotic processes are queued in Appian RPA until a compatible resource becomes available. The robotic processes execute based on their assigned priority, which can also be configured in the Execute Robotic Process smart service.
If you have a set of many items to process in parallel, you can design a process model that uses MNI to spawn multiple sub-processes once called.
To get started:
The MNI implementation has a 1000-node limit. If you have more than 1000 items to process, we suggest breaking them into increments of 1000 or less and building additional logic in your process model to handle them.
When launching multiple consecutive robotic processes, you can use the Skip setup and clean up for consecutive executions option in the Execution settings to speed up each execution after the initial one.
With traditional RPA tools, the robotic process needs to use custom code or custom libraries to perform tasks not strictly related to third party system interaction such as sending emails, invoking web services or other APIs, and generating documents.
With Appian RPA, the robotic process leverages the low-code power of the Appian platform to perform these tasks through the execution of Appian process models or Appian expressions:
To execute a process model from a robotic process, use the Start Process action in the Appian Services menu. After selecting the Process Model to execute, provide the necessary process parameters and save the process instance identifier returned by this action.
Note that the Appian process is started asynchronously. After launching the Appian process, the robotic process continues to the next step in the robotic workflow.
To execute an Appian expression from a robotic process, use the Evaluate expression action in the Appian Services menu. The action returns the outputs of the expression which can be saved in robotic process variables for future use.
Depending on the third party system to interact with, this interaction may require additional software that is not installed on the resources such as emulators for mainframe systems or desktop applications. In this scenario, a robotic process must be executed on the correct resource or set of resources in order to work properly.
Use RPA permission tags to pair robotic processes and resources. A robotic process can only be executed on a resource that shares the same permission tags.
Any robotic process you create can also be run as a robotic subprocess of another robotic process. Appian recommends using robotic subprocesses for any functionality common to your robotic processes.
At the start of an automation project, consider if you plan to build robotic processes that share any actions. If you find there are multiple robotic processes with the same actions, this might be an opportunity to use a robotic subprocess. You can use the robotic subprocess in multiple robotic processes, which makes overall development faster and maintenance easier.
Robotic subprocesses are easier to configure, maintain, and troubleshoot. You won't have to run it within the context of the larger overall process as you build and debug. Instead, you'll be able to run and debug the robotic process on its own, which saves time. Additionally, robotic subprocesses make the overall robotic process easier to maintain. By keeping distinct actions together, you'll be able to isolate any issues to find and fix them faster.
To implement a robotic subprocess effectively and efficiently, simply build a stand-alone robotic process that includes functionality you expect to use repeatedly across multiple robotic processes. Be sure to consider what dynamic pieces of information need to be passed in from the parent robotic process, and create appropriate parameters in the robotic subprocess accordingly.
For example, consider how many of your robotic processes start by signing into a website. If you have multiple robotic processes that interact with the same website using the same credentials, you can create a robotic process that just handles the task of signing in. Then, you can call that robotic process within the context of other robotic processes that proceed to do different things, such as filling out a form or downloading documents.
To properly pass the credential information, the parent robotic process needs a robotic process variable to store the credential and the robotic subprocess needs a parameter mapped to that credential variable. See how to use credentials in a subprocess for further instructions.
Robotic subprocess or loop?
Robotic subprocesses are similar to looping design patterns because they accomplish the same task multiple times. However, there is a key difference that determines when to use either option:
For example, a robotic process is designed to tab through multiple pages on a site and get the first line item in a table. This action repeats until there are no more pages. This goal is best achieved with a loop, since it repeats within the same robotic process until a condition is met. A robotic subprocess isn't advised here unless you plan to use this tab functionality in additional robotic processes.
On This Page