Maintaining Robot Manager History Tables for Robot Manager V8.3.1 and earlier

Maintaining Robot Manager History Tables for Robot Manager V8.3.1 and earlier

Description	Describes how to manage history data in Robot Manager to prevent system issues.
Version as of	8.3.1
Application	Pega Robotic Process Automation
Capability/Industry Area	Robot Manager

Summary

Robot Manager v8.3.1 and earlier you need to manually maintain the robot operator work history in an environment. If the maintenance is not performed on an environment, overtime it will lead to significant slowness while interacting with Robot Manager Dashboard and increase in completion time of robotic API service call like the registration, and heartbeat.

In v8.4 and later of Robot Manager has an out-of-the-box scheduled job that will perform the maintenance periodically in the background. Therefore, this process can be ignored for those versions.

NOTE: This is only true for an environment using Robot Runtime in RPA mode. The history tables don’t grow exponentially for an RDA Robot Runtime environment that would be a cause of concern.

Classname (pxobjclass)	Table	Purpose
History-Data-Robot-Automations	pr_data_robot_automation_audit	Automation work history
History-Data-Robot-Events	pr_data_robot_event_audit	Robot audit history
History-Data-Admin-Operator-ID	pr_history_data	Robot and RPA Service operator heartbeat calls history

Run the following command to check the count of rows for each of the table:

SELECT COUNT(*) FROM $TableName

If an environment uses Pega Diagnostics Cloud (PDC) the table information can be retrieved from the Database tab.

Cleaning up the Robot Manager history tables

You can maintain the Robot Manager history through the following means:

• Run the out-of-the-box activities periodically through a background agent/job scheduler.
• Run a backend database job that periodically purges/archives the table based on their use case.

Out-of-the-box activities that run through background agent/job scheduler

pxArchiveRobotAutomations (ClassName: History-Data-Robot-Automations)

Moves the automation history of a robot from pr_data_robot_automation_audit  to pr_data_robot_automation_audit_archive table

pxArchiveRobotEvents (ClassName: History-Data-Robot-Events)

Moves the robot audit rows from pr_data_robot_event_audit to pr_data_robot_event_audit_archive table

pxPurgeRobotOperatorHistory (ClassName: History-Data-Admin-Operator-ID)

Deletes the robot operator history from the pr_history_data table

Archived data are moved to a different table, so the information is not actively fetched by Robot Manager interaction.

Information on creating the job scheduler task and background agent is available on Pega Community.

Backend Database Job

Schedule a backend database job with assistance from the DBA that identifies the rows to be purged based on the business requirement.

A business solution that automates workflows in your organization. Multiple, unrelated applications can be hosted in the same system. You create an application by running the New Application wizard.

An action that does not require human involvement but can instead be done programmatically.

One of the following UI elements:

- A centralized workspace that displays operational information about your application and key performance indicators, such as the number of assigned items or the average time to resolve a case. A dashboard can include charts, reports, worklists, and other widgets.

- A single webpage that shows the current status and ongoing trends of your organization’s behavior. This data helps you to make informed decisions and guides you to specific investigations or outcomes.

An action that does not require human involvement but can instead be done programmatically.

An application user that is identified by the user name, password, and other details. Each operator has a role, such as caseworker or customer service representative, that determines what actions the user can perform.

An internal background process that operates on the server that runs activities on a periodic basis. In a multinode cluster, an agent can run on multiple nodes.

Actual work that is performed by application users and automations that consists of a sequence of tasks and leads to an intended business goal. An example of a case is a process of hiring a particular job candidate, where an HR worker collects necessary documents, a hiring manager conducts a job interview, and an application sends an automated email with onboarding information after the candidate is approved. To create a case, you first build a template of your business process that is a case type, and then apply the template in multiple cases, for example, to review applications from many candidates.

A data storage that is superseded by the local data storage feature. Click Convert for each data table that is displayed on the Data Tables landing page to convert it to the new format.

Used to generate legacy document types. A requirement is an event, condition, or function that must be satisfied and tracked by an application. Requirements can be functional (a capability) or non-functional (a quality or constraint). One or more requirements can be used to define the criteria for the successful implementation of a specification.