This content has been archived.

Table of Contents

Pega Robot Manager version 4

Use Pega® Robot Manager to monitor the performance, health, and throughput of your robotic process automation (RPA) virtual machines (VMs).

You can do the following tasks:

  • Manage VMs and work queues, such as specifying the number of automations that can fail on a VM.
  • Configure the organizational hierarchy of departments and users.
  • Apply roles to users to define the tasks that they can perform.
  • Obtain updated automation packages and deploy them to robotic work groups, departments, and users.

For more information about configuring and using RPA with Pega Platform, see the following information:

Pega Robot Manager version 4 is supported on a minimum platform version of Pega 7.3. To download Pega Robot Manager from Pega Exchange, go to the Pega Robot Manager page.

You must also use one of the following versions of Pega Robotic Automation Studio and Pega Robotic Automation Runtime:

  • 8.0.1067 or later to use the new features in Pega Robot Manager. For more information about enhancements in this release, see Enhancements.
  • 8.0.1058 or later to use all other features, excluding the new features in this release.

See the following topics for information about Pega Robot Manager:

Enhancements

The following enhancements have been added to this version of Pega Robot Manager:

  • Support for UIKit 10

Pega Robot Manager 4 is now optimized to work with UIKit 10.

  • Support for Kerberos authentication of VMs.

You can now configure Robot Manager so that VMs log in by using either Kerberos or basic authentication. Use Kerberos to allow VMs and Pega Robot Manager to communicate with each other in a secure manner over a non-secure network.

  • New options for specifying the work group into which a VM registers.

When you use single sign-on (SSO), you can now configure a VM to register into a work group either from within the registration request of a VM, which is specified in Pega Robotic Automation Runtime, or from within a decision table in Pega Platform. You can also configure the method that the system first uses to determine the work group into which a VM registers.

Importing Pega Robot Manager

After you download Pega Robot Manager, import it to Pega Platform by completing the following steps:

  1. In Designer Studio, click Designer Studio > Application > Distribution > Import.
  2. Click Choose File.
  3. Browse for the JAR file that you downloaded.
  4. Click Submit.

Banker Pro sample application

Pega Robot Manager includes a sample application that you can use to understand how RPA solutions are configured within a Pega Platform application. The Banker Pro sample application is configured for traditional, straight-through RPA processing. The application contains work groups for Customer Service and Banking, and each group contains several work queues to hold assignments.

The Banker Pro sample application also defines several case types to perform common back-office tasks, such as updating account information, processing claims, and resolving customer disputes. Each case type has a single stage and a single processing step. Each step queues a new assignment to a VM by using the Assign to robot queue advanced shape on the Process Modeler.

Logging in to the Banker Pro sample application

After you import Pega Robot Manager, you can explore the sample application by logging in to Pega Platform with the following credentials:

  • User ID - admin@bankerpro
  • Password - rules

VM registration in the Banker Pro sample application

VM registrations are handled by the BankingAdministrator operator, which registers new VMs and assigns them to the correct access group. You must configure the credentials for this operator in each Pega Robotic Automation Runtime instance. As a best practice, when you configure RPA, give your administrative operator a unique access group with the PegaRULES:RoboticAdministrator access role.

You must also customize the pyGetAccessGroupForRobotByWorkGroup decision table to map a work group to the correct access group. Each access group can have different access roles so that you can customize the access rights of each VM in your application. This decision table has been specialized in the Banker Pro application layer.

Customizing the dashboard layout in the Banker Pro sample application

To start Pega Robot Manager, click Launch > Robotic console.

You can customize the dashboard page of Pega Robot Manager by clicking the Gear icon in the upper-right corner of the console. A default configuration is configured in the pyCaseManagerDashboards data transform, which is specialized in the Banker Pro application layer.

Configuring Pega Platform to use Pega Robot Manager

After you import Pega Robot Manager, you must configure certain settings, such as adding the console to an application and enabling agents. See the following sections for more information:

Adding Pega Robot Manager to a new application

When you create a Pega Platform application, you can add Pega Robot Manager to your application by completing the following steps:

  1. Create the application by using the New Application wizard in Designer Studio. Your application will be automatically configured to be built on the UIKit 10.01 application layer.
  2. Open the application record by clicking the application name in the Designer Studio header, and then clicking Open application.
  3. In the Edit Application rule form, In the Built on application(s) section, add the PegaRoboticAutomationConsole application to the stack:
    1. Click Add application.
    2. In the Name field, enter PegaRoboticAutomationConsole.
    3. In the Version field, enter 01.02.02.
  4. Click Save.

Adding Pega Robot Manager to an existing application that uses a previous UIKit version

​If you have an existing Pega Platform application that uses a previous version of the UIKit, you can add Pega Robot Manager to your application by completing the following steps:

  1. Open the PegaRoboticAutomationConsole application rule.
    1. Click Records.
    2. Click Application Definition > Application.
    3. Search for PegaRoboticAutomationConsole by using the Name filter.
    4. Click PegaRoboticAutomationConsole.
  2. In the header, click Definition.
  3. In the Edit Application form, in the Built on application(s) section, add UIKit 10.01 to the application stack.
    1. Click Add application.
    2. In the Name field, press the Down Arrow key and select UIKit.
    3. In the Version field, press the Down Arrow key and select 10.01.
  4. Add your application to the application stack.
    1. Click Add application.
    2. In the Name field, press the Down Arrow key and select the name of your application.
    3. In the Version field, press the Down Arrow key and select the version of your application.
  5. Click Save.
  6. Create an access group that points to the PegaRobotAutomationConsole application:
    1. Click +Create > Security > Access Group.
    2. Enter a name and description, and click Create and Open.
    3. In the Application section, in the Name field, enter PegaRoboticAutomationConsole.
    4. In the Version field, enter 01.02.02.
    5. In the Available portals section of the access group, add pyRoboticConsole to the list of portals.
    6. On the Advanced tab of the access group, add the default work pool of your existing built-on application.
    7. Click Save in the Edit Access Group form.
  7. Assign the new access group to your users. For more information, see Operator ID: Completing the Profile tab.

Enabling the ProcessStaleRobots agent

The ProcessStaleRobots agent finds running VMs that have lost connectivity with Pega Robot Manager and disables them.

Enable this agent by completing the following steps:

  1. Click Records > Sys Admin > Agent Schedule.
  2. Select the Pega-ProcessEngine instance on the node where you want to enable the ProcessStaleRobots agent.
  3. Select the Enabled? check box for the ProcessStaleRobots agent.
  4. Click Save.

Enabling the RoboticAssignmentProcessing agent

The RoboticAssignmentProcessing agent finds stale assignments that have been in the VM queue for longer than expected and moves the assignments back to the work queues from which they originated.

​Enable this agent by completing the following steps:

  1. Click Records > Sys Admin > Agent Schedule.
  2. Select the Pega-ProCom instance on the node where you want to enable the RoboticAssignmentProcessing agent.
  3. Select the Enabled? check box for the RoboticAssignmentProcessing agent.
  4. Click Save.

Configuring the work group into which a VM registers for single sign-on

If you are using single sign-on (SSO) to authentication, you configure that a VM registers into a work group either from within the registration request of a VM or by using a decision table in Pega Platform. For more information about configuring the registration request within a VM, see the Common Configuration Settings section in the help for Pega Robotic Automation Runtime.

Configure the pyGetWorkGroupForRobotByRequestorOperatorID decision table to map user names to work groups in your system. For example, if you are using Kerberos authentication, map the Microsoft Windows user principal name (UPN) from a valid Kerberos ticket to a work group in your system.

  1. Click Records > Decision > Decision tree.
  2. Click the pyGetWorGroupForRobotByRequestorOperatorID decision table in the Pega-Robot-Register class and save it to your application ruleset.
  3. Add the user names and their corresponding work groups to the decision table. For example, for Kerberos authentication, add the user principal names (UPNs) and their corresponding work groups to the decision table. For more information about decision tables, see About Decision Tables.
  4. Click Save to save the rule form.
  5. Set the order in which the system first registers VMs (either from within the registration request of a VM or through the decision table). For more information, see Setting the order of work group registration.

Setting the order work group registration for single sign-on

If you are using single sign-on (SSO) authentication, configure the WorkgroupSpecifiedInPayloadTakesPrecedence dynamic system setting to determine which method (either from within the VM registration request or through the pyGetWorkGroupForRobotByRequestorOperatorID decision table) the system first uses to determine the work group into which a VM registers. If this method is not successful, the system then uses the other method to determine work group registration.

  1. In Designer Studio, click Records > SysAdmin > Dynamic System Settings.
  2. Click the record with the pegarobotics Owning Ruleset and WorkgroupSpecifiedInPayloadTakesPrecedence Setting Purpose.
  3. On the Settings tab, in the Value field, enter one of the following values:
    • true: The system determines the work group first from within the VM registration request.
    • false: The system determines the work group first from the pyGetWorkGroupForRobotByRequestorOperatorID decision table.
  4. Click Save.

One of the following occurs:

  • If you specify that the work group is determined within the registration request of the VM, Pega Robot Manager first attempts to assign the VM to that work group. If registration is not successful, it then attempts to map the UPN to a work group in the pyGetWorkGroupForRobotByRequestorOperatorID decision table.
  • If you specify that the work group is first determined by the decision table, Pega Robot Manager attempts to map the UPN to a work group in the decision table. If registration is not successful, Pega Robot Manager attempts to register the VM into the work group that is configured within the VM registration request.

After the work group is determined for the VM, it is mapped to the access group that you configured in the pyGetAccessGroupForRobotByWorkGroup decision table when you configured Pega Platform to register VMs.

Kerberos authentication

By default, VMs log in to the Pega Platform by using basic authentication. You can configure Pega Robot Manager to use Kerberos authentication so that VMs log in to the Pega Platform by using Kerberos authentication. For more information, see Configuring Pega Robot Manager to use Kerberos authentication for VMs.

You configure Pega Platform to support single sign-on using Kerberos using SPNEGO libraries, or you can use your own Kerberos validation mechanism to authenticate traffic to Pega Robot Manager. For more information about specifying which method to use, see Specifying the Kerberos authentication method that Pega Platform uses.

Configuring Pega Robot Manager to use Kerberos authentication for VMs

VM registration is still performed in the same way when VMs use Kerberos authentication, and you still perform the same steps. However, after you configure the work queues and work groups into which VMs will register, you must configure Robot Manager to use Kerberos authentication for VMs by performing the following procedure:

  1. Configuring service packages to use Kerberos.
  2. Configuring the operator ID that registers VMs to use Kerberos.
  3. Configuring the work group into which a VM registers.
  4. Setting the order of work group registration.

Configuring service packages to use Kerberos

Configure the API and Robotics SSO service package to authenticate incoming VM requests to use Kerberos authentication.

  1. Configure the API service package.
    1. In Designer Studio, click Records > Integration-Resources > Service Package.
    2. Click the api service package.
    3. On the Context tab, from the Authentication type drop-down list, select Custom.
    4. In the Authentication service field, enter pyKerberosAuthenticationServiceForRobotManager.
    5. Click Save.
  2. Configure the RoboticsSSO service package.
    1. In Designer Studio, click Records > Integration-Resources > Service Package.
    2. Click the RoboticsSSO service package.
    3. On the Context tab, from the Authentication type drop-down list, select Custom.
    4. In the Authentication service field, enter pyKerberosAuthenticationServiceForRobotManager.
    5. Click Save.
  3. Configure the operator ID that registers VMs to use Kerberos authentication. For more information, see Configuring the operator ID that registers VMs to use Kerberos.

Configuring the operator ID that register VMs to use Kerberos

The authentication type of the operator ID that registers VMs determines the authentication type of the VMs that it registers.

If you are using Kerberos, the pyKerberosAuthenticationServiceForRobotManager authentication service is configured to use externally stored credentials. You must configure the operator ID that registers VMs to use external authentication by performing the following steps:

  1. In Designer Studio, search for the operator ID that registers VMs.
  2. Click the Security tab.
  3. Click the Use external authentication check box.
  4. Save the Operator ID form.
  5. Configure the work group into which a VM registers. For more information, see Configuring the work group into which a VM registers.

After operator IDs are generated for VMs, they are also configured to use external authentication.

If the operator ID that registers VMs is not configured to use external authentication, it registers a VM by using basic authentication. The VM is not configured to use external authentication but instead uses internal authentication.

Specifying the Kerberos authentication method that Pega Platform uses

Configure the EnableDefaultKerberosAuthenticationForRobotManger dynamic system setting to specify which Kerberos authentication method you want to use to authenticate traffic to Pega Robot Manager. You can either use the functionality provided with Pega Robot Manager, or you can use your own method of Kerberos authentication.

  1. In Designer Studio, click Records > SysAdmin > Dynamic System Settings.
  2. Click the record with the pegarobotics Owning Ruleset and EnableDefaultKerberosAuthenticationForRobotManger Setting Purpose.
  3. On the Settings tab, in the Value field, enter one of the following values:
    • true; Pega Robot Manager authenticates the service principal name (SPN) from a Kerberos ticket, using the default authentication using SPNEGO libraries, which you configure. For more information, see Enabling Pega Platform to support single sign-on using Kerberos.
    • false: Pega Robot Manager does not authenticate the Kerberos ticket and reads the SPN to validate the operator ID of the requesting VM to establish a session with it. You can then configure your own method of Kerberos authentication.
  4. Click Save.

Enabling Pega Platform to support single sign-on using Kerberos

On a running Active Directory (AD) server, you can enable Pega Platform, running on an Apache Tomcat server, to use Kerberos authentication. Enabling single sign-on (SSO) using Kerberos comprises the following steps:

  1. Configuring AD to use Kerberos.
  2. Configuring Tomcat to enable client systems to connect to Pega Platform.

Step 1: Configuring AD to use Kerberos

After you create users and systems inside an AD domain, you must run commands to define the Pega Platform server and configure service principal names (SPNs) for users. Kerberos uses SPNs, which uniquely identify service instances, to associate a service with a service logon account.

  1. Use either the ktpass.exe or setspn.exe command to map the Pega Platform server and Pega Platform users to their server and client systems. On the domain controller server, which is the system on which Active Directory Domain Services (AD DS) is running, do one of the following actions:
  • To run the ktpass.exe command, for example, for a KerbServUser server and KerbClientUser user, open the command line and enter the following commands, where DOMAINNAME.COM is your fully qualified domain name, and SEVERHOSTNAME is the name of your Pega Platform system:

ktpass.exe /out c:\KerbServUser_SPN.keytab /mapuser KerbServer@DOMAINNAME.COM /princ

HTTP/SERVERHOSTNAME@DOMAINNAME.COM /pass password

/crypto all /ptype

KRB5_NT_PRINCIPAL /kvno 0

This command creates the HTTP/SERVERHOSTNAME SPN and the C:\KerbServUser_SPN.keytab .keytab file for this SPN. The keytab file contains the SPN credentials.

You can use the generated .keytab file to provide login credentials to Tomcat by modifying the web.xml and login.conf files. For more information, see Step 4 in Configuring Tomcat to enable client systems to connect to Pega Platform.

  • To use the setspn.exe command to configure SPNs without using a .keytab file, open the command line and enter the following commands, ensuring that all computers and users are in the same domain:

Setspn.exe -A HTTP/SERVERHOSTNAME KerbServUser

Setspn.exe -A HTTP/SERVERHOSTNAME@DOMAINNAME.COM KerbServUser

Setspn.exe -A HTTP/SERVERHOSTNAME.DOMAINNAME.COM KerbServUser

Setspn.exe -A HTTP/SERVERHOSTNAME.DOMAINNAME.COM@DOMAINNAME.COM KerbServUser

Do not register an SPN to more than one user name. A user name can have more than one SPN registered, but an SPN can only be mapped to one user.
To display the SPNs for a user, use the command: setspn –l<user_name>
  1. Enable delegation for users by clicking the Trust this user for delegation to any service (Kerberos only) radio button in Active Directory.
  2. Configure the Kerberos policy to use AES-128 bit encryption on both domain controller server and on the system running Tomcat.
  3. Enable AES-128 bit encryption for the user.
Enabling the AES-128 Kerberos group policy on the domain controller server can cause existing the infrastructure to become inoperable, because the system might be using RC4 by default. Check with your system administrators before making any changes.
For added security, you can use AES-256. To do so, you must download the Java Cryptography Extension (JCE) Unlimited Strength security libraries from the Oracle website and place them in the jre/lib/security and jdk/jre/lib/security directories. You must also change the Kerberos group policy to use AES-256 bit encryption.

Step 2: Configuring Tomcat to enable client systems to connect to Pega Platform

Configure Tomcat with SPNEGO libraries so that client systems can connect to the Pega Platform.

  1. Create the login.conf and krb5.conf files, and add them to the $catalina_home/bin Tomcat folder.
  2. Download the spnego-r7.jar file from the SourceForge website and copy it to the prweb/WEB-INF/lib Tomcat folder.
  3. Modify the web.xml file to intercept REST endpoints to enable negotiation and authentication for RPA calls that are requested by Pega Robotic Automation Runtime and Pega Robotic Automation Studio from the Pega Platform server. Use <filter-mapping> tags only for the endpoints (requested URLs) that are available for the api and SSO service packages.

By default, SPNEGO has a backup mechanism to use NTLM on basic authentication modes if there is a failure with using Kerberos. Therefore, you can use <filter-mapping> tags as a generic method to intercept all the incoming traffic to the Pega Platform server, NTLM and basic authentication modes are applied to each request to the Pega Platform server.

  1. Add the following code to the web.xml file to intercept the endpoints that are available for the api and roboticsSSO service packages, providing the appropriate values for parameters such as the spnego-client:

<filter>

<filter-name>SpnegoHttpFilter</filter-name>

<filter-class>net.sourceforge.spnego.SpnegoHttpFilter</filter-class>

<init-param>

<param-name>spnego.allow.basic</param-name>

<param-value>true</param-value>

</init-param>

<init-param>

<param-name>spnego.allow.localhost</param-name>

<param-value>true</param-value>

</init-param>

<init-param>

<param-name>spnego.allow.unsecure.basic</param-name>

<param-value>true</param-value>

</init-param>

<init-param>

<param-name>spnego.login.client.module</param-name>

<param-value> spnego-client</param-value>

</init-param>

<init-param>

<param-name>spnego.krb5.conf</param-name>

<param-value>krb5.conf</param-value>

</init-param>

<init-param>

<param-name>spnego.login.conf</param-name>

<param-value>login.conf</param-value>

</init-param>

<init-param>

<param-name>spnego.allow.delegation</param-name>

<param-value>true</param-value>

</init-param>

<init-param>

<param-name>spnego.preauth.username</param-name>

<param-value>username</param-value>

</init-param>

<init-param>

<param-name>spnego.preauth.password</param-name>

<param-value>password_for_pre_auth_user</param-value>

</init-param>

<init-param>

<param-name>spnego.login.server.module</param-name>

<param-value>spnego-server</param-value>

</init-param>

<init-param>

<param-name>spnego.prompt.ntlm</param-name>

<param-value>true</param-value>

</init-param>

<init-param>

<param-name>spnego.logger.level</param-name>

<param-value>1</param-value>

</init-param>

</filter>

<filter-mapping>

<filter-name>SpnegoHttpFilter</filter-name>

<url-pattern>/PRRestService/roboticsSSO/*</url-pattern>

</filter-mapping>

<filter-mapping>

<filter-name>SpnegoHttpFilter</filter-name>

<url-pattern>/api/*</url-pattern>

</filter-mapping>

<filter-mapping>

<filter-name>SpnegoHttpFilter</filter-name>

<url-pattern>*.jsp</url-pattern>

</filter-mapping>

<login-config>

<auth-method>SPNEGO</auth-method>

</login-config>

  1. Configure preauthorization user credentials by doing one of the following actions:
  • Modify the web.xml file and provide the values for the SPN user name and password in the following parameters:

<init-param>

<param-name>spnego.preauth.username</param-name>

<param-value>username_of_pre_auth_user</param-value>

</init-param>

<init-param>

<param-name>spnego.preauth.password</param-name>

<param-value>password_for_pre_auth_user</param-value>

</init-param>

  • Modify the spnego-server module in the login.conf file to provide information about the .keytab file. For more information, see step 6-c.
  1. Configure the login.conf file.
    1. Add the following text to the login.conf file:

spnego-client {com.sun.security.auth.module.Krb5LoginModule required;

};spnego-server {com.sun.security.auth.module.Krb5LoginModule

Required

useKeyTab=false

storeKey=true

debug=true

isInitiator=false;

};

  1. Modify the values for the spnego - client and spnego -server module names to match the values that you provided for the following entries in the web.xml file in step 3:

<init-param>

<param-name>spnego.login.client.module</param-name>

<param-value>spnego-client</param-value>

</init-param>

<init-param>

<param-name>spnego.login.client.module</param-name>

<param-value>spnego-client</param-value>

<init-param>

  1. Configure preauthorization user credentials by setting the following values:
  • useKeyTab=true.
  • HTTP/SERVERHOSTNAME is the SPN
  • C:\KerbServ_SPN.keytab is the name and location of the .keytab file.
  1. ​Configure the krb5.conf file to identify the domain realm name and the IP address of AD DS system on which the Kerberos Key Distribution Center (KDC) network service runs. Modify the following text, where DOMAINNAME is the domain name of the Kerberos realm, which is the domain over which Kerberos can authenticate users, and KDCMACHINEIP is the IP address of the AD DS.

[libdefaults]default_realm = DOMAINNAME.COM

default_tkt_enctypes = des3 -cbc-sha1 des-cbc-md5 des-cbc-crc arcfour-hmac

aes128-cts-hmac-sha1-96 aes128-cts

default_tgs_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc arcfour-hmac

aes128-cts-hmac-sha1-96 aes128-cts

permitted_enctypes= des3-cbc-sha1 des-cbc-md5 des-cbc-crc arcfour-hmac

aes128-cts-hmac-sha1-96 aes128-cts

[realms]

DOMAINNAME.COM = {

kdc = KDCMACHINEIP:88

default_domain = DOMAINNAME.COM

}

[domain_realm]

.domainName = DOMAINNAME.COM

domainName = DOMAINNAME.COM

After setup is complete, you can verify that Pega Platform is configured for SSO using Kerberos by verifying that when a client system makes a request to Pega Platform, the Authorization header starts with Negotiate, followed by a Kerberos ticket.

User management

You can create and manage your organizational structure of departments and users. The departments at the third level and below comprise one or more users who perform similar functions in an organization. For example, an organization can have a department of developers that maintain automations and a department of testers that test an automation before it is deployed to a production environment.

You also assign roles to users, which determine what actions they can perform in Pega Robot Manager.

See the following topics for more information:

Roles

Pega Robot Manager provides the following roles, which define the tasks that users can perform:

  • AutomationPackageManagement:Administrators – Users with this role can perform all actions in Pega Robot Manager. Only these users can deploy packages to the Production deployment level and promote them to different levels.
  • AutomationPackageManagement:Developer – Users with this role can publish and manage packages. They can only view users and departments.
  • AutomationPackageManagement:UserAdmin – Users with this role can manage users and departments, and they can view packages. They cannot deploy packages.
  • AutomationPackageManagement:RuntimeUser – Users with this role cannot log in to Robot Manager; they are the end users, such as case workers, who use automations in a production environment.

The following table provides information about the tasks that each role can perform.

Task

Role

AutomationPackage
Management:
Administrators

AutomationPackage
Management:
Developer

AutomationPackage
Management:
UserAdmin

AutomationPackage
Management:
RuntimeUser

General

Automation

Use Pega Robot Manager

x

x

x

View and manage work groups on the Work groups page

x

x

Departments

View departments on the Departments page

x

x

x

Create departments

x

x

Edit department details

x

x

Delete departments

x

x

Users

View users on the Users page

x

x

x

Access user features by clicking a user

x

x

x

Create users

x

x

Modify user details

x

x

Configure the maximum number of automations that can fail on a VM

x

Move users between departments

x

x

Delete users

x

Packages

View packages

x

x

x

Retrieve a package

x

x

x

Access package features by clicking a package

x

x

x

Publish package versions

x

x

Edit package details

x

x

Delete a package

x

Create deployment levels

x

x

Rename deployment levels

x

x

Move deployment levels

x

x

View deployment-level history

x

x

x

Restore packages

x

Delete deployment levels

x

Deploy a version into and promote a version to a non-Production deployment level

x

x

Deploy a package version into and promote a package to the Production deployment level

x

Create and delete package assignments

x

Enable and disable package assignments

x

For more information about roles, see Access Roles.

Roles also determine the form of authentication that is used when users log in to Pega Robot Manager. For more information, see Configuring default authentication for roles.

Configuring default authentication for roles

By default, users with the AutomationPackageManagement:RuntimeUser role log in to Pega Robot Manager by using single sign-on (SSO) authentication; users with all other roles log in by using basic authentication. You can change the default authentication type by configuring Dynamic System Settings in Pega Platform.

When you create users, they use the default authentication that you specify.

  1. In Designer Studio, click Records > Sysadmin > Dynamic System Settings.
  2. To specify the authentication used for the AutomationPackageManagement:RuntimeUser role:
    1. Click the PegaRoboticAutomationManagement owning ruleset that has the pegarobotics/DefaultAuthenticationTypeRuntimeOnlyUser Setting Purpose value.
    2. In the Value field, enter SSO or Basic.
    3. Save the rule form.
  3. To specify the authentication for all other roles:
    1. Click the PegaRoboticAutomationManagement owning ruleset that has the
      pegarobotics/DefaultAuthenticationType Setting Purpose value.
    2. In the Value field, enter SSO or Basic.
    3. Save the rule form.

Associating access groups and roles

Permissions are applied to users by using access groups on which roles are associated. When you add a user in Pega Robot Manager, you associate the access group to apply the role permissions to the user.

  1. In Designer Studio, create an access group that points to your application by clicking +Create > Security > Access Group.
  2. Enter a name and description, and click Create and Open.
  3. In the Application section, specify your application name and version.
  4. In the Available roles section, click Add role.
  5. In the field that is displayed, press the Down Arrow key and select the role that you want to associate with the access group.
  6. Save the Edit Access Group rule form.

For more information about access groups, see Access Group data instances.

You can also create an access role and add privileges to it. For more information, see Access Roles.

Adding departments

You can add multiple top-level departments, and you can add multiple subdepartments to a department.

  1. Click Departments.
  2. Click Actions > New department.
  3. Select the parent level to which the department belongs.
  4. Enter a description, and then click Submit.

Modifying departments

You can modify the name and description of a department.

  1. Click Departments.
  2. Expand the organizational tree, click the Selector Selector icon, and click Edit.
  3. Enter a name and description, and then click Submit.

Deleting departments

You can delete a department that has no users in it.

  1. If the department has users, either delete them or move them to another department. See Moving users to another department or Deleting users for more information.
  2. Click Departments.
  3. Expand the organizational tree, click the Selector Selector icon, and click Delete.
  4. Click Submit.

Adding and modifying users

You can add users to departments and specify their access groups, which are associated with the roles that define the tasks that they can perform. You cannot edit the email address for users who use basic authentication or edit the user principal name (UPN) for users who use SSO authentication.

Operator IDs are created for each user that you add, and users log in with the email address or UPN that you specify.

  1. Click Users.
  2. Do one of the following:
    1. To add a new user, click Add new.
    2. To modify a user, click the user that you want to modify, and click Actions > Edit.
  3. In the New user or Edit user dialog box, in the First Name field, enter the first name of the user.
  4. Click the Department field and select the department to which the user belongs. This department is at least the third level in the organizational hierarchy.
  5. In the Last Name field, enter the last name of the user.
  6. In the Role field, press the Down Arrow key and select the access group to which the user belongs.
  7. In the Email address field, enter the email address of the user. This field is required for user roles that use basic authentication. Users log in to Pega Robot Manager with their email addresses.
  8. In the UPN field, enter the UPN. This field appears for roles that use SSO authentication and is required.
  9. In the Status field, press the Down Arrow key and select the status of the user (Active or Inactive).
  10. Click Submit.

For users who log in to Pega Robot Manager with basic authentication, the system generates the password Pega. Users should change their passwords by clicking Forgot password? on the Pega Robot Manager login page and having an email sent to them.

Moving users to another department

You can move users to another department.

  1. Click Departments.
  2. Expand the organizational tree to find the department that contains the users that you want to move, and click the department.
  3. In the Users section, select one or more check boxes for the users that you want to move.
  4. Click Move.
  5. In the Move users dialog box, select the department to which to move the users.
  6. Click Move.

Deleting users

You can delete users, which also removes their operator IDs.

  1. Click Departments.
  2. Expand the organizational tree to find the department that contains the users that you want to delete, and click the department.
  3. In the Users section, select one or more check boxes for the users that you want to delete.
  4. Click Delete.

Pega Robot Manager dashboard

The Pega Robot Manager dashboard is a centralized workspace that displays operational information about your robotic process automations and key performance indicators, such as the status of your VMs.

See the following topics for more information:

Templates and widgets

Each dashboard uses a template that provides preconfigured layouts that define the standard size and position of widgets. Several standard templates are available.

After you apply a template to your dashboard, you can add widgets to each slot to display helpful functions in your console. Slots in a template are shown as gray rectangles.

Customizing the dashboard

The dashboard is displayed each time that you log in to your application. When personalization is enabled, you can configure your dashboard based on your individual preferences and business needs.

For example, you can add a widget that displays the number of assignments that could not be processed or the number of assignments that did not meet a service-level agreement (SLA) goal.

Click the Gear icon to display the Edit dashboard panel to customize your dashboard.

For information about configuring your dashboard display, adding and configuring widgets, and publishing your dashboard, see Configuring your dashboard.

You can only click Publish when you publish a dashboard, which displays the dashboard for your own login.

Pega Robot Manager widgets

Pega Robot Manager provides the following widgets that you can add to your dashboard:

  • Automation alerts – Displays failed robotic automations.
  • Automation alerts over time – Displays the number of failed robotic automations over a period of time.
  • Case activity – Displays the cases that were created and resolved over a period of time.
  • Cases past SLA – Displays the cases that exceeded an SLA goal.
  • Resolved cases by type – Displays the number of resolved cases by case type.
  • Robot status – Displays the VMs in each work group that have issues or that are not running.

Creating widgets and displaying them in the dashboard

You can create your own widgets to display in the Pega Robot Manager dashboard.

For example, you can create a report that displays the percentage of robotic automations on a VM that run and are successfully completed on the first attempt. The following procedure describes the general steps for creating a report widget to display in the dashboard.

  1. Create a report in Designer Studio in your application ruleset. For more information, see Creating reports in Designer Studio.
  2. Create a section in your application ruleset. For more information, see Sections - Completing the Create, Save as, or Specialize form.
  3. Add a chart control to the section and configure it so that it displays the report that you created.
    1. In the Data Source section, from the Type list, select Report Definition.
    2. In the Applies to field, press the Down Arrow and select the class to which your report applies.
    3. In the Report field, press the Down Arrow and select the name of your report.
    4. From the X-axis data field, select the property to use for the X-axis.
    5. Configure other information, as appropriate. For more information, see Harness and section forms - Adding a chart.
    6. Click Submit.
  4. Mark the section as a widget, and configure the report widget.
    1. In the Edit Section form, click Settings.
    2. In the Widget title section, enter the name of the widget.
    3. From the Category list, select Robotic process automation.
    4. Configure other information, as appropriate. For more information, see Section form - Completing the Settings tab.
    5. Click Save.

After you log out and log back in to Pega Platform and start the Robotic Console, you can select the widget and display it in your dashboard.

Managing work queues and VMs

You can use Pega Robot Manager to manage your work queues and VMs in several ways. For example, you can start and stop queues and modify the frequency of pings that are sent from your VM to your Pega Platform application.

See the following topics for more information:

Monitoring VMs

You can view information about VMs to monitor their performance. For example, you can view a history of all the assignments that VMs in a work group processed.

You can do the following actions on the Work groups page:

  • View all the work groups in your application, all the work queues in each work group, and all the VMs that retrieve assignments from those work queues.
  • Click a workbasket to view information about assignments in a work queue, such as how many assignments are in it.

A work queue displays a red icon if the number of queued items meets or exceeds the maximum number of assignments that should be in it.

  • Click a VM to view information about VM performance, such as audit trail information and how many assignments the VM could not process.

A VM displays a red icon on the Work groups and Dashboard pages in one of the following scenarios:

  • The number of run-time automations is greater than the number of automations that can be in a work queue.
  • The connection to the VM is lost (the heartbeat interval has been exceeded).
  • The last automation took longer than expected to complete.

Reprioritizing work queues

VMs retrieve assignments from work queues in order of priority. Assignments are retrieved from the work queues according to their order on the Work groups page, from the top of the list to the bottom. You can reprioritize work queues by completing the following steps:

  1. Click Work groups.
  2. Click Edit in the panel for the work group that contains the work queue that you want to reprioritize.
  3. Drag the work queue to its intended priority in the list.
  4. Click Save.

Starting and stopping work queues

You can start or stop a work queue by completing the following steps:

  1. Click Work groups.
  2. In the panel for the work group that contains the work queue that you want to start or run, click Edit.
  3. From the State list for the corresponding work queue, select RUNNING or STOPPED.
  4. Click Save.

Configuring assignment information on work queues

You can configure information about assignments that are running on VMs within a work queue. For example, you can specify the number of assignments that should be running on a VM in a work queue.

  1. Click Work groups.
  2. Click the work queue that you want to modify.
  3. Click Edit.
  4. In the Max items field, enter the maximum number of assignments that should be in the work queue at any time.

If the number of queued items meets or exceeds this threshold, the work queue turns red on the Work groups page, indicating that the VMs are not keeping pace with the incoming rate of work.

  1. In the Max automation run time (in sec) field, enter the expected run time for the assignments in this queue.

If the run time of an automation exceeds the value that is specified on its originating work queue, the VM displays a red icon on the Work groups and Dashboard pages, indicating that it might need administrative attention.

  1. Click Save.

Modifying the heartbeat and work polling intervals

Each VM sends a heartbeat, or periodic message, to your application to indicate that the VM is still running and available. The work polling interval is the period of time that a VM waits before polling its work queue for more assignments.

You can modify these intervals by completing the following steps:

  1. Click Dashboard, and then click a VM in the Robot Status section.
  2. Click the Edit icon Edit icon in the Robot Settings section.
  3. In the Heartbeat interval field, enter the heartbeat interval, in seconds, that VMs should use when they ping your Pega Platform application.

A VM displays a red icon on the Dashboard and Work groups pages if the heartbeat interval has been exceeded, indicating that the connection to the VM has been lost.

  1. In the Work polling interval field, enter the polling interval, in seconds, that the VM should use when requesting assignments from a work queue.
  2. Click Save. The new intervals are applied after the VM next registers with your Pega Platform application.

Configuring the number of automations that can fail on a VM

You can configure the number of automations that can fail on a VM. If automation failures exceed this value, Pega Robot Manager indicates that there are issues with the VM health on the Dashboard page.

  1. Click Work groups, and then click the VM that you want to modify.
  2. Click the Edit icon Edit icon in the Compliance section.
  3. In the Max failed automations field, enter the number of automations that can fail on a VM during its processing life.

If the number of failures is greater than this value, the VM displays a red icon on the Dashboard and Work groups pages to indicate that the maximum number of failed automations has been exceeded.

  1. Click Submit.

Processing failed assignments

If an assignment is not successfully processed, you can resend it to the work queue for reprocessing, or you can skip processing on the automation by manually continuing the flow in a case type.

  1. Click Dashboard, and then click View all alerts in the Automation alerts section.
  2. Click the case that contains the failed assignment that you want to process.
  3. In the Assignments section, click Begin.
  4. Do one of the following actions:
    • To manually continue the flow, select Actions > Manually continue the flow, and then click Submit.
    • To resend the assignment back to its work queue to be reprocessed by the VM that is running the assignment, do the following actions:
      1. Optional: Click Action > Edit to update a field.
      2. Click Submit.

Automation packages

When a change is made to an automation, the updated automation package can be sent to Pega Platform. In Pega Robot Manager, you can then deploy it to a robotic work group, department of users, or individual users in your organization. For example, a package can contain updates to customer service tasks, which you can test and deploy those changes to the case workers who use the application.

After the Pega Robotic Automation Studio developer updates an automation, the developer publishes the automation package to the Package Server. When a VM logs in to Pega Platform, the VM registers into its defined work group, which might be different from the one specified in Pega Platform. It retrieves the automation from the Package Server, loads it, and then begins requesting assignments.

See the following topics for more information:

Package versions

Packages can have one or more versions, and you can deploy and promote any version of a package. For example, a Pega Robotic Automation Studio developer can publish an initial 1.0 package, which has been deployed to a production level. The developer can later publish an updated 1.1 package, which you can deploy to your QA level, where you can test it and then deploy it to production users.

Modifying package details

You can modify the name and description of a package.

  1. Click Packages.
  2. Click the package that you want to rename.
  3. Click Actions > Edit.
  4. Enter a name, description, or both, and then click Submit.

Viewing package versions

You can view information about versions of a package, such as when a package was published and by whom, that are on Pega Platform.

  1. Click Packages.
  2. Click the package for which you want to view version information.
  3. Click Actions > Versions.
  4. Click Close.

Deleting package versions

You can delete a version of a package from Pega Robot Manager.

  1. Click Packages.
  2. Click the package for which you want to delete a version.
  3. Click Actions > Versions.

A Lock icon indicates that a package version has been deployed, and you cannot delete it. You must remove the package deployment first; see Removing a package from a deployment level for more information.

  1. Click Delete for the package version that you want to delete from Pega Platform.
  2. Click Close.

Deleting a package

You can delete a package from Pega Robot Manager.

  1. Click Packages.
  2. Click the package that you want to delete.
  3. Optional: If a package is assigned to a department, work group, or user, remove the package assignments. For more information, see Removing package assignments.
  4. Optional: If a package is deployed, remove the package from all levels to which it is deployed. For more information, see Removing a package from a deployment level.
  5. Delete each version of the package. For more information, see Deleting package versions.
  6. Click Actions > Delete.
  7. Click Submit.

Deployment levels

The deployment pipeline defines the levels through which an automation package moves from software development to a production environment. You deploy a package to a level and assign the deployment level to departments, users, and robotic work groups in that level so that the appropriate resources can develop, test, and use the package.

Pega Robot Manager provides the following default deployment levels:

  • Development – The level in which developers update and maintain packages
  • UAT – User acceptance testing. The level in which business users test packages to validate that a package performs as expected in real-world scenarios
  • Production – The level in which case workers use the final version of the package in a live environment

You cannot rename, change the respective order of, or delete these deployment levels.

See the following topics for more information:

Adding a deployment level

You can add deployment levels to your pipeline, in addition to the three default levels that Pega Robot Manager provides. For example, you can create a QA level, where QA testers can run performance tests before you promote the package to the UAT level.

  1. Click Packages.
  2. Click the package for which you want to add a deployment level.
  3. Click the Down Arrow of the deployment level to the left of where you want to add the new level.
  4. Click Add deployment.
  5. Enter a name, and then press Enter. The deployment level is displayed to the right of the level that you clicked.

Renaming a deployment level

You can rename a deployment level that you created.

  1. Click Packages.
  2. Click the package for which you want to rename a deployment level.
  3. Click the Down Arrow for the deployment level that you want to rename.
  4. Enter a name, and then press Enter.

Reordering deployment levels

You can move deployment levels to change their order in the deployment pipeline.

You cannot move the Deployment or Production deployment levels from their locations.

The UAT level must be located between the Development and Production levels.

    1. Click Packages.
    2. Click the package for which you want to reorder a deployment level.
    3. Drag the deployment level that you want to move to the appropriate location.

    Deleting a deployment level

    You can delete a deployment level that you created.

    1. Click Packages.
    2. Click the package from which you want to delete a deployment level.
    3. If a package has been deployed to the deployment level, you must first remove the package deployment. For more information, see Removing a package from a deployment level.
    4. Click the Down Arrow for the deployment level that you want to delete, and then click Delete.

    Deploying a package

    You deploy a package into a deployment level and then assign the deployment level and its package to the appropriate robotic work group, department, or user.

    1. Click Packages.
    2. Click the package that you want to deploy.
    3. Complete one of the following actions:
    • Deploy a package into a development level on which there is no package deployment:
    1. Click Deploy version in the development level into which you want to deploy a package.
    2. In the Available versions dialog box, click Deploy for the package version that you want to deploy.
    • Deploy a package version that has already been deployed to a deployment level:
    1. Click the Deploy icon Deploy icon in the deployment level to which you want to deploy a package.
    2. In the Available versions dialog box, click Deploy for the package version that you want to deploy.
    3. Assign the deployment level and package to the appropriate resource. See Assigning deployment levels and packages for more information.

    Assigning deployment levels and packages

    You assign a deployment level and the package that is deployed in it to a robotic work group, department of users, or individual users. For example, you can assign the Production deployment level, which contains a package so that VMs can automatically process claims, to a robotic work group.

    When you assign a deployment level and package to a department, the package is inherited by all the subdepartments and users in each subdepartment. If you later add users or subdepartments to the department, any packages that were assigned to the department are also inherited by new subdepartments and users.

    You can assign multiple deployment levels and packages to a user. For example, users inherit packages on a deployment level that are assigned to their departments, and you can also assign deployment levels and their associated packages directly to those users. If users are assigned multiple packages, they can select which package they want to use when they log in to their workstations.

    Note: You can assign only one package to a robotic work group.

    1. Click Packages.
    2. Click the package, and then click the deployment level that you want to assign.
    3. Click Assign new.
    4. In the Create assignment dialog box, assign the deployment level and package.
    • To assign a deployment level and package to a robotic work group:
    1. Click the Group radio button.
    2. In the Group field, press the Down Arrow key and select the work group.
    • To assign a deployment level and package to a department:
    1. Click the Department radio button.
    2. From the Department drop-down list, select the department.
    • To assign a deployment level and package to a user:
    1. Click the User radio button.
    2. In the User field, press the Down Arrow key and select the user.
    1. Click​ Next.
    2. Optional: If a package configuration is defined, click the configuration that you want to assign. For more information, see Package configurations.
    3. Click Next.
    4. Click Assign.

    Removing assignments

    You can remove an assignment, for example, if a case worker was inadvertently assigned to use the Development deployment level and package.

    1. Click Packages.
    2. Click the package for which you want to remove an assignment.
    3. Click the deployment level that you want to remove.
    4. In the Assigned to section, click the Delete icon for the department, work group, or user to which the deployment level is assigned.
    5. Click Submit.

    Viewing assignments

    You can view all the packages that are assigned to departments or to individual users.

    To view package assignments for a department:

    1. Click Departments.
    2. Click the department for which you want to view package assignments.

    To view package assignments for a user, click Users, and then click the user.

    The Assigned to section displays all the packages that are assigned to the department or user.

    Enabling and disabling assignments

    You can enable or disable packages that are assigned to departments or users.

    To enable or disable a package assignment for a department, which disables or enables it for all subdepartments users:

    1. Click Departments.
    2. Click the department for which you want to enable or disable a package assignment.
    3. Click the switch in the Assigned to section to enable or disable a package assignment.

    To enable or disable a package assignment for a user:

    1. Click Users, and then click the user.
    2. Click the switch in the Assigned to section to enable or disable a package assignment.

    Package configurations

    A package can contain one or more configurations, which are defined on the automation by the Pega Robotic Automation Studio developer. Configurations act as variables into which different information can be substituted as needed.

    For example, an automation developer builds an automation that retrieves parcel delivery information from an intranet website. A user must enter a tracking number in the website to retrieve parcel information.

    For performance purposes, two sites are maintained on the intranet website—one for the East Coast of the United States, and one for the West Coast, with separate URLs for each site. The automation developer can create two configurations for the automation package, with one for the East Coast and one for the West Coast. Depending on which package configuration is used, when the automation runs, it loads either the East Coast or West Coast website URL.

    In Pega Robot Manager, when you assign a package, you can assign the package configuration for the East Coast website to East Coast users and the package configuration for the West Coast website to West Coast users.

    Promoting a package to another deployment level

    After a package has been deployed to a level, you can promote the package to another level in the pipeline. For example, after business users finish testing in the UAT level, you can move the package from the UAT level to the production level.

    Package deployments are not removed from the original deployment level when you promote them to another level.

    1. Click Packages.
    2. Click the package that you want to promote.
    3. Click the package on the deployment level that you want to promote.
    4. Drag the package to the deployment level to promote the package to that level.

    Removing a package from a deployment level

    You can remove a deployed package from a deployment level.

    1. Click Packages.
    2. Click the package that you want to remove from a deployment level.
    3. Optional: If the deployed package is assigned to a department, work group, or user, you must remove the package assignments. See Removing assignments for more information.
    4. Click the Delete icon for the package version that you want to delete.

    Restoring a package on a deployment level

    You can restore a previously deployed version of a package deployment on a deployment level. For example, if you deployed a package version from UAT to Production but need to perform more testing, you can restore a previously deployed production package in the Production level.

    1. Click Packages.
    2. Click the package for which you want to restore a package version.
    3. In the deployment level for which you want to restore a package, click the Down Arrow, and then click Deployment history.
    4. Click Restore for the package deployment that you want to restore.

    Viewing package deployment history

    You can view details about a package deployment, such as which version of a package was deployed and when it was deployed.

    1. Click Packages.
    2. Click the package for which you want to view the deployment history.
    3. In the deployment level for which you want to view the deployment history, click the Down Arrow, and then click Deployment history.

    100% found this useful

    Have a question? Get answers now.

    Visit the Pega Support Community to ask questions, engage in discussions, and help others.