This content applies solely to Appian RPA, which must be purchased separately from the Appian base platform. |
Although Appian RPA is currently available only for Appian Cloud sites, we understand that customers may be interested in using its capabilities in their self-managed environments. This page describes how a hybrid configuration for Appian RPA works, how to set it up, and how to use robotic tasks in your applications. We've also included tips for maintenance.
Appian RPA works best in a native Appian Cloud environment, but can be accessed from a self-managed environment using a hybrid configuration. Some Appian RPA capabilities aren't available in a hybrid configuration.
In the context of Appian RPA, a hybrid configuration refers to the connection between a customer's self-managed Appian site and a separate Appian Cloud site, where Appian RPA is available.
Customers continue to build and deploy apps in the environments they're used to, while the robotic tasks are created and executed in the Appian Cloud. The two environments are integrated using an HTTP connected system. With the connected system, business applications can communicate with robotic tasks in the customer's new Appian Cloud environment. The connected system enables you to execute robotic tasks and retrieve results.
To get started, you'll need to do some setup steps for the two environments to communicate. Developers will also need to use different design patterns to integrate Appian RPA into their applications.
Appian's Robotic Workforce Manager (RWM) solution provides you with visibility into automations across your business, including requests for new automations, automations in production, and execution results. RWM leverages Appian RPA's APIs to initiate these actions and retrieve data automatically, so you don't need to set up additional objects or processes to accomplish those routine tasks. Instead, the solution streamlines management for you.
To set up RWM, you'll need to complete tasks on your Appian Cloud site and your self-managed site.
You'll need to create a service account in your Cloud environment to authenticate with RWM.
You'll use this API key when you set up the connected system in RWM.
In your self-managed environment, install RWM to manage your robotic tasks.
As part of the RWM package, you'll find an RWM connected system you can use to authenticate with Appian RPA in the Cloud environment. You can also use this connected system object to create integrations to use in your applications.
Learn more about Robotic Workforce Manager (RWM).
The RWM application contains a connected system object you can use to establish a connection with Appian RPA based in the Cloud site.
RWM_AppianRPA
connected system object.These are the only RWM setup steps you need to complete as part of the hybrid configuration, but there are additional steps to finish setting up the RWM solution. Learn how to populate RPA vendor details and finish other RWM setup steps in the RWM documentation.
To use RPA in your applications, you'll need to create a few more design objects. Once you create the objects listed in this section, refer to the Execute robotic tasks synchronously from process models design pattern below for guidance on how to integrate robotic tasks into your applications.
You'll need to create these objects on your Appian Cloud site and your self-managed site.
First, create another service account in your Cloud environment to authenticate with the Appian RPA connected system you'll create in the next step. You'll likely want this user to be different from your RWM service account to help you manage security of what this user can accomplish. Consider having one service account per application.
To execute a robotic task or retrieve its results on the self-managed site, you'll need to create corresponding integrations in the Cloud site. To get started, first you need to create an Appian RPA connected system.
You'll use this connected system to create integrations for the robotic tasks you want to integrate in your applications.
The self-managed site will call the Appian RPA integrations using web APIs, so you'll need to set those up on the Appian Cloud site.
You should have a web API for each Appian RPA integration you created. The integrations on the self-managed site will correspond to these web APIs, so you should set them up to call the appropriate integration rules on the Cloud site. Learn more about web APIs.
To communicate with the integrations on the Appian Cloud site, you'll need to configure an HTTP connected system on the self-managed Appian site.
/suite/webapi
. For example: https://www.example.com/suite/webapi/
.If you want to create multiple service accounts or API keys, you can use these instructions to create a connected system to integrate the two environments.
Use this connected system to create HTTP integrations that point to the web API endpoints you set up in the Cloud site.
Next, you need to export the relevant CDTs from your self-managed site and import those to the Cloud environment.
In a hybrid configuration, the self-managed Appian site communicates with the Appian Cloud site to execute a robotic task and retrieve the results. Robotic tasks usually interact with Appian data in some way. Therefore, the Appian Cloud site and the self-managed site must have the same CDTs if they're being used in a robotic task. The robotic task uses the Appian Cloud site CDT in the robotic task, but once complete, returns the updated data to the self-managed site. It's important that any data used by the robotic task uses the appropriate structure so it can be sent back to the self-managed site.
You can import CDTs to the Appian Cloud environment as part of a deployment package. Learn more about deployment considerations regarding CDTs.
This section describes how to build process models in your self-managed site that communicate with Appian RPA in the Appian Cloud site.
When you develop process models that execute robotic tasks, you may want your process model to wait for the results of the robotic task before continuing. The robotic task executes asynchronously when you use two integration objects, so you have to configure the process model to wait for the robotic task to complete and retrieve the results separately before proceeding.
While you could use a polling pattern to continually check the status of the robotic task, this is not recommended because it could cause your process to reach the 1000-node limit and/or dramatically increase the size of your process history.
This pattern aims to help you develop a network of Appian objects to determine when a robotic task is complete. Most of these objects are reusable (as noted in the sections below), so you'll create them once and apply them to future robotic task and process model configurations.
Data passes between objects in the following ways:
To get started, you'll need to create a few objects. In the sections below, we include names for the objects. You can name the new objects you create anything you'd like, but keep in mind that the code referencing the example object names will need to be updated as well if you change the names.
Some objects should be created at the same time, while others can be created in sequence. The steps below start with supporting objects that are needed to create the main process model, which executes the robotic task and fetches results.
At the end of this pattern, you'll have the following objects in your application:
Create a group to secure the application objects you'll create in the following steps. Add the service account for your Appian RPA connected system to this group.
Create a process report that will look up the ID of the process instance that executed the given robotic task. To do this:
Click New Data and add two new columns: one for the process instance ID (pp!id
) and one for the execution ID (pv!executionId
). The second column will be blank for any robotic tasks from process models without this variable.
It's important that this report only contain two columns. If additional columns exist, the query breaks in the web API (detailed below).
INSTANCE_EXECUTION_MAPPING_REPORT
. Select Document
for the constant type.Next, create the process model to send a message to the main process model when the robotic task execution finishes.
This process is started by the notifyProcessOfCompletion
web API (described below) and takes in a specific process instance ID to send a message to. The process ID is crucial here to ensure that the process-to-process message is targeted rather than just sending a massive message to any listening process model.
This process model contains three nodes: Start, Send Message, and End.
processInstance
of type Number (Integer). Parameter should be set to Yes
.DestinationProcessID
row, map the Value to the processInstance
process variable (=pv!processInstance
).After you save the process model, create a constant called SEND_COMPLETION_MSG_PM
pointing to it. You'll use this constant in the web API.
Next, create the web API object. This web API is called during the cleanUp() method of the robotic task to notify the originating process that it has completed. It is designed to be generic, so that all the developer has to pass in is the execution ID and it will determine the correct process instance to send the message to.
notifyProcessOfCompletion
.send-completion-msg
.The code below uses two constants:
INSTANCE_EXECUTION_MAPPING_REPORT
points to the process report you created in step 2. The report maps process instances with execution IDs.SEND_COMPLETION_MSG_PM
points to the Send Completion Message process model. The API initiates this process model when it receives a process ID as input.After you've created the object, use the following expression to configure the web API:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
a!localVariables(
local!processId: index(
a!queryProcessAnalytics(
report: cons!INSTANCE_EXECUTION_MAPPING_REPORT,
query: a!query(
/* Filter the query results by the execution ID */
filter: a!queryFilter(field: "c1", operator: "=", value: http!request.body),
pagingInfo: a!pagingInfo(1, 1)
)
).data,
/* Index to receive only the process instance ID */
"c0",
{}
),
if(
length(local!processId)=0,
/* If the query returned no results, there are no active processes waiting on that robotic task */
a!httpResponse(
statusCode: 200,
headers: {
a!httpHeader(name: "Content-Type", value: "application/json")
},
body: "There are no active processes to notify of the completion"
),
/* Otherwise, start the process to send a message to the process instance */
a!startProcess(
processModel: cons!SEND_COMPLETION_MSG_PM,
processParameters: {
processInstance: local!processId
},
onSuccess: a!httpResponse(
statusCode: 200,
headers: {
a!httpHeader(name: "Content-Type", value: "application/json")
},
body: a!toJson(
fv!processInfo
)
),
onError: a!httpResponse(
statusCode: 500,
headers: {
a!httpHeader(name: "Content-Type", value: "application/json")
},
body: a!toJson(
{
error: "There was an error starting the process"
}
)
)
)
)
)
Finally, set the security of the web API so that the group you created has Viewer access.
This step takes place in your Appian Cloud environment with Appian RPA enabled.
Next, you'll need to update and deploy the robotic task code so it automatically sends a message to Appian when it's complete. This is done using the cleanUp()
method.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
public String[] cleanUp() throws Exception {
/** The cleanUp() method ensures the robot is cleaned up at the end of the execution
* regardless of whether it completes successfully or not. Therefore, the web API call
* should be added to the cleanUp() method to guarantee that it will always be called
* at the end of the robotic task.
*/
// Constructs the execution ID to pass to the web API
String executionId = server.getExecution(0).getRobotName() + "#" +
server.getExecution(0).getCurrentExecution().getExecutionNumber();
// Calls the notifyProcessOfCompletion web API and passes the execution ID
IAppian appian = IAppian.getInstance(this);
IWebApiRequest request = IWebApiRequestBuilderFactory.getFreshInstance()
.post("send-completion-msg")
.body(executionId)
.build();
IWebApiResponse response = appian.callWebApi(request);
// Displays the result of the web API in the execution log for easy debugging
server.info("Response body: " + new String(response.getBodyBytes()));
return new String[0];
}
This method is designed to be reusable, so you could consider saving this modified version as a class to use across multiple robotic tasks.
Set up a connected system as described above. Remember that the service account must have the appropriate tags in Appian RPA to run robotic tasks on robots and must be in the application group you created for this to work correctly.
You'll create and use two integrations based on this connected system:
getExecutionResults
: Retrieves the execution results for the given execution ID. You can decide whether you want this to be a reusable rule or not, since it can't really vary much between applications. In the integration, create a rule input called executionId
(text) and add ri!executionId
in the Execution Id field of the integration.executeRoboticTask
: Executes a robotic task. This isn't a generic object, but rather will be application specific based on the robotic task they're calling. In the integration, two rule inputs called onSuccess
and onError
(any type) appear automatically. In the Robotic Task field, select the task you want to execute.You'll use both of these integrations in the Execute Robotic Task
process model, described next.
Finally, create the process model that starts the robotic task and waits for the results.
This process model kicks off the robotic task execution, then listens for a message indicating the execution has been completed. After it receives that message, it retrieves the results. It doesn't map to a reusable object, but represents a process model within a specific application that wants to integrate with a robotic task. You can think of this as the "main" process model.
This process model contains five nodes: Start, Execute Robotic Task, Receive Message, Get Results, and End.
executionId
and status
, both of type Text. Neither has a set value or other settings configured.executeRoboticTask
integration. On the Data tab, configure a custom output called ac!Result.executionId
. Save this output into the executionId
process variable.getExecutionResults
integration. On the Data tab, add a new input called executionId
. In the Value field, add the executionId
process variable (=pv!executionId
). Add a custom output called ac!Result.status
. Save this output into the status
process variable.Once you have all objects configured and connected, you're ready to test. Use the Start Process for Debugging option in the Execute Robotic Task
process model to get started.
If the process model doesn't proceed past the Receive Message Event, check these common issues:
executeRoboticTask
integration object to confirm the desired robotic task is selected.Send Completion Message
process model? It could be that the process report isn't set up properly. In Appian RPA, go to the robotic task's execution log. If you see a line that says "Response body: There are no active processes to notify of the completion," check the process report to confirm that the robotic task execution ID is properly matched with the process model instance.Now that your hybrid configuration is set up, you and your team can focus on developing robotic tasks. To do that, you'll need to grant developers access to your Cloud site. User accounts aren't automatically synched between your self-managed site and your Cloud site, so you may also want to evaluate the available user authentication mechanisms. Synching certain user accounts automatically can help save you time by managing user accounts in just one environment.
Routinely evaluate data integrity and security in your Appian RPA implementation. Securing data in a robotic task is an important consideration in all environments.
Consider your deployment strategy when you're integrating robotic tasks with your applications. You'll likely have development, test, and production environments for both of your self-managed and Appian Cloud sites, so it's important to have a thorough understanding of how your deployment process works with hybrid configuration in place. Learn more about deploying robotic tasks and applications.