Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Configuring Pega Robot Manager version 5

Updated on April 5, 2022
Note: This content mentions the Pega Express Delivery approach, which formerly referred to App Studio. The Pega Express Delivery approach now unifies our low-code experience strategy with our delivery methods. You can find the Pega Express Delivery approach described here.

Use Pega® Robot Manager to:

  • Manage and deploy automation packages to both robotic desktop automation (RDA) and robotic process automation (RPA) virtual machines (VMs)
  • Monitor the performance, health, and throughput of your RPA VMs

Pega Robot Manager version 5 requires a minimum platform version of Pega 7.4. To download Pega Robot Manager from Pega Exchange, go to the Pega Robot Manager page.

Pega Robot Manager version 5 also requires version 8.0.1084 or later of Pega Robotic Automation Studio and Pega Robotic Automation Runtime.

For information about using Pega Robot Manager, see Using Pega Robot Manager.

See the following topics for information about configuring Pega Robot Manager:

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.
  5. If you are upgrading Robot Manager from a previous release, run the pxMigrateRobotLogEntriesToV5 activity to upgrade rendering of the following pages and widgets:
    • Workgroups and Users > Robots pages
    • The page that is displayed when you click a robotic VM
    • The page that is displayed when you click a work queue
    • The Robot status and Automation alerts over time widgets
  6. In Designer Studio, search for pxMigrateRobotLogEntriesToV5.
  7. In the dialog box that displays search results, click the pxMigrateRobotLogEntriesToV5 activity to open it.
  8. Click Actions > Run.
Depending on the volume of historical RPA audit data in your database, this activity might take some time to complete.

Banker Pro sample application

Pega Robot Manager includes the preconfigured Banker Pro sample application that demonstrates how you can incorporate Pega Robot Manager into a new or existing Pega application. The Banker Pro application includes several case types that are configured for traditional, straight-through RPA processing. Each case type has a single stage and a single processing step, which queues a new assignment to a VM by using the Assign to robot queue advanced shape.

The application also includes preconfigured work groups and work queues. Use Work groups to segment your RPA VM population into groups of VMs that perform similar types of work. The Banker Pro application includes work groups for Banking and Customer service.

Updating Banker Pro operator ID credentials

Before you can log in to the Banker Pro sample application, you must update credentials for the admin@bankerpro and BankingAdministrator operator IDs.

  1. In Designer Studio, search for admin@bankerpro.
  2. In the dialog box that displays search results, click the admin@bankerpro operator ID to open it.
  3. On the Operatorrule form, click Security.
  4. Clear the Disable Operator check box.
  5. Click Save.
  6. Click Update password.
  7. Enter a password according to the security standards of your organization.
  8. Clear the Force passwordchange on next login check box.
  9. Click Save.
  10. Repeat this procedure for the BankingAdministrator operator ID.

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. In the Pega Express Delivery approach, create the application by using the New Application wizard. Your application will be automatically configured to be built on the UIKit 11.01 application layer.
  2. In Designer Studio, 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 02.01.01.
  4. Click Save.
  5. Open your operator access group.
    1. In Designer Studio, click on Operatoricon > AccessGroup
    2. In the Available portals section of the access group, add pyRoboticConsole to the list of portals.
    3. 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 11.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 11.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 02.01.01.
    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 Profile tab on the Operator ID form.

VM registration

A VM must successfully register with Pega Robot Manager before it can begin running automations. A successful registration will result in the VM being assigned into the correct workgroup with the appropriate access groups and roles. To start registration, VMs use a shared set of administrative credentials, which are used only to establish an initial connection with Pega Robot Manager. You can create this administrative operator by completing the following steps:

  1. Create a new operator record in the Designer Studio
    1. Click +Create > Organization > OperatorID.
    2. Enter a short description and identifier, and click Create and Open.
    3. Fill out the details of the administrative operator.
    4. In the Applicationaccess section of Profile tab, add an access group which includes the PegaRULES:RoboticAdministrator access role.
    5. Click Save.

You can also refer to the BankingAdministrator operator that is included in the Banker Pro sample application layer.

Configuring work group precedence

A VM can request to join a specific work group. If a specific work group is not specified by the VM, Pega Robot Manager will attempt to find a work group that the VMs should join from the pyGetWorkGroupForRobotByRequestorOperatorID decision table. You can configure Pega Robot Manager so that either method of work group registration takes precedence over the other; if one method does not work, then the other method is applied.

  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: Use this setting if you have configured your VMs to request a work group in their registration requests. Pega Robot Manager attempts to assign the VM to the work group that is specified in the request. However, if the registration request contains an invalid workgroup, Pega Robot Manager will then assign the VM to a work group that is specified in the pyGetWorkGroupForRobotByRequestorOperatorID decision table.

    • false: Use this setting if you want Pega Robot Manager to automatically determine the work group for each VM. Pega Robot Manager will attempt to match the administrative credentials to a valid work group by using the pyGetWorkGroupForRobotByRequestorOperatorID decision table. However, if the work group that is specified in the decision table is not valid, Pega Robot Manager uses the work group that is specified in the registration request of the VM.
  4. Click Save.

If the neither of these options results in a valid work group, the VM registration fail.

Assigning a work group by request

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.

Assigning a work group by using a decision table

If you want Pega Robot Manager to automatically assign each VM to work group, you can customizethe pyGetWorkGroupForRobotByRequestorOperatorID decision table to map the user credentials to work groups in your application. For example, if you use Kerberos authentication, your decision table would map the Microsoft Windows user principal name (UPN) from a valid Kerberos ticket to a work group in your system.

  1. In Designer Studio, 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 precedence of work group registration for single sign-on.

Assigning an access group to a VM

After the VM registration sequence determines a valid work group for a VM, Pega Robot Manager must also identify an access group to which to map the work group. You can customize the pyGetAccessGroupForRobotByWorkGroup decision table to map a valid work group to a an access group. Each access group can have different access roles so that you can customize the access rights of each VM in your application. If the decision table does not map a work group to a valid access group, VM registration fails.

You can view the decision table in the BankerPro application layer for an example of how to customize the access group.

User roles

Users with different roles use Pega Robot Manager. User roles are associated with the following access roles::

  • Administrator (AutomationPackageManagement:Admin) – Administrators can perform all actions in Pega Robot Manager. Only these users can deploy packages to the Production deployment level.
  • Developer (AutomationPackageManagement:Developer) – Developers can publish and manage automation packages.
  • User admin (AutomationPackageManagement:UserAdmin) – UserAdmins can manage runtime users and the organizational heirarchy.
  • Runtime user (AutomationPackageManagement:RuntimeUser) – Runtime users cannot log in to Robot Manager. Runtime users are typically case workers who merely fetch their automation package assignment from the Robot Manager

The following table summarizes the tasks that each type of user can perform.

Task

Role

 

AutomationPackage
Management:
Admin

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

 

 

Requeue failed assignments from dashboardx   

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.

Configuring authentication for new users

Users can be configured to authenticate with Pega Robot Manager in different ways. You should configure the authentication mechanism for each user role before you begin creating users in Pega Robot Manager. By default, Pega Robotic Automation Runtime users authenticate with Pega Robot Manager by using single sign-on (SSO) authentication; users with all other roles authenticate using basic authentication. You can customize this by configuring Dynamic System Settings in Pega Platform.

When you create user accounts in Pega Robot Manager, the authentication mechanism that is assigned to each user is determined by their specified role and the Dynamic System Setting that is associated with the specified role.

  1. In Designer Studio, click Records > Sysadmin > Dynamic System Settings.
  2. To specify the authentication that is 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

Access groups and access roles determine the permissions of each user in your Pega application. 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.

Enabling automatic cleanup of disconnected VMs

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

Enable this agent by completing the following steps:

  1. Click Records > Sys Admin > Agent Schedule.
  2. Select the Pega-Robotic-AutomationPackageManagement 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 automatic cleanup of stale automation assignments

The RoboticAssignmentProcessing agent finds stale automation assignments that have been in a work queue of a VM for longer than expected and moves them to the list of automations that have timed out. You can view automations that have timed out on the Time-outs tab of the Automation alerts dashboard widget.

​Enable this agent by completing the following steps:

  1. Click Records > Sys Admin > Agent Schedule.
  2. Select the Pega-Robotic-AutomationPackageManagement 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.

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 work group into which a VM registers.
  3. Setting the order of work group registration.

Configuring service packages to use Kerberos

Configure the API and RoboticsSSO 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.

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 by 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) by 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 [email protected] /princ

HTTP/[email protected] /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/[email protected] KerbServUser

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

Setspn.exe -A HTTP/[email protected] 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 be mapped only to one user.
To display the SPNs for a user, use the command: setspn –l<user_name>
  1. Enable delegation for users by clicking Trust this user for delegation to any service (Kerberos only) in Active Directory.
  2. Configure the Kerberos policy to use AES-128 bit encryption on both the domain controller server and on the system running the Apache Tomcat server.
  3. Enable AES-128 bit encryption for the user.
Enabling the AES-128 Kerberos group policy on the domain controller server can cause the existing 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. 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.

Configuring the pyCompleteAutomation flow action

In Pega Robot Manager version 5.2, the pyCompleteAutomation is marked as an Extension. Its default behavior is to consider the automation status as "Complete" and move the flow to the next stage of the case life cycle. It is strongly recommended to customize the default behavior of pyCompleteAutomation flow action to better suit the needs of your organization.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us