Published Release Notes

Using Kerberos authentication with your database

Pega 7 supports Kerberos functionality. Kerberos is a computer network authentication protocol which allows nodes communicating over a non-secure network to prove their identity to one another in a secure manner. 

To use Kerberos for authentication, you must use the command line to install or upgrade Pega 7.

To use Kerberos authentication:

1.  Change the setupDatabase.properties file.

a.  In the “Uncomment this property section” of the file, uncomment the jdbc.custom.connection.properties property.  Based on your security infrastructure, different properties may be required as parameters to this property; provide the needed properties as semicolon-delimited name/value pairs:
 

jdbc.custom.connection.properties=prop1=val1;prop2=val2;prop3=val3;
 

Example:  For an installation on a MSSQL database server from a Windows client machine (where both machines belong to the same Windows domain), using the Microsoft JDBC driver, the property may be set as follows:
 

jdbc.custom.connection.properties=integratedSecurity=true;

b.  Comment out all the username and password properties where they occur in the jdbc.custom.connection.properties file, so that they appear as follows:

# pega.jdbc.username db username
# pega.jdbc.password db password

[lines removed here]

# pega.jdbc.username=ADMIN
# pega.jdbc.password=ADMIN

2.  Set up your database to enable Kerberos functionality.  This may include additional vendor-specific JDBC driver configuration, or other setup procedures.  Check the documentation from your database vendor to determine what Kerberos setup is needed for your database.

3.  Run the command line installation or upgrade by following the instructions found in the Pega 7 Deployment guides.

Run cleanup.bat/sh script only before upgrading

Prior to upgrading the rulebase, you can optionally run the cleanup.bat/sh script to remove older rules from the database.

Run this script before you upgrade your rulebase, or the script may delete needed rulesets. For more information about running the cleanup.bat/sh script, refer to the Upgrade Guide specific to your release version.

When using Oracle 12.1.0.1, left outer joins in reports may return incorrect results

When using  Pega 7 with Oracle 12.1.0.1 , reports that use left outer joins may return incorrect results.

This is an Oracle known issue.  To resolve this behavior, upgrade to Oracle 12.1.0.2, apply the Oracle patch 16726638 by requesting it directly from Oracle, or, for Microsoft Windows installations, apply Windows Bundle patch 12.1.0.1.15 or later.

For more information in this behavior, see: https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=392085808201943&id=1957943.1

Unclear error message when saving shared class instance in tenant layer

If you attempt to save a shared class instance from the tenant layer, Pega 7 displays this message:

This record has x errors. Save Failed: There was a problem saving an instance of class: Error Code: <none> SQL State: <none> Message: <none>

You cannot save a shared instance from the tenant layer if that instance cannot be overridden.

View status of custom search indexes

Custom search indexes are special purpose indexes that are created and managed outside of Pega Platform™. You can view the status of custom search indexes on the Search landing page to see whether they are complete. This information is useful for troubleshooting and can help you determine whether to rebuild the index.

For more information, see Checking search index status.

Job Scheduler and Queue Processor rules replace agents

The Job Scheduler rule and the Queue Processor rule replace agents and improve background processing. The Job Scheduler rule is used for recurring or scheduled tasks, such as sending summary emails on weekdays. This rule can be run on all nodes or on specific node types according to your customized pattern. The Queue Processor rule is used for tasks with no recurrence-based pattern. It provides scalability and capability for immediate or delayed message processing, such as submitting status changes to an external system. You can use a standard queue processor or a dedicated queue processor, depending on your processing needs.

Pega Platform™ provides a set of default queue processors and job schedulers. Corresponding agents are no longer available.

For more information about Job Scheduler and Queue Processor rules, see Job Scheduler, Replacing an agent with a Job Scheduler rule, Queue Processor, Replacing an agent with a Queue Processor rule.

Improve application test coverage by running multiple sessions

You can improve the test coverage of your application by using a new test coverage method - Application Coverage. Multiple users can perform coverage sessions which are aggregated into a single report. By using report metrics that show the number of rules that are covered and are not covered by tests, developers can identify which areas of the application need more test coverage.

For more information, see the Test Coverage landing page.

Security fields in JFrog Artifactory repository rule form removed

The fields in the Security section of the JFrog Artifactory repository rule form, including the Secure protocol field, the Truststore field, and the Keystore field, were not functional in Pega Platform™ 7.3, 7.3.1, and 7.4. This section has been removed from the JFrog Artifactory repository rule form in Pega Platform 8.1.

Support for OAuth 2.0 authorization code grant type

Pega Platform™ now supports the OAuth 2.0 authorization code grant type, which allows Pega Platform to act as an OAuth 2.0 access token provider for native applications on mobile and other devices. By using the authorization code grant type for mobile clients, you no longer need to implement a variety of standards for various authentication providers. The authorization code grant type also supports the Proof Key for Code Exchange standard (PKCE) for securing public clients.

For more information, see Creating and configuring an OAuth 2.0 client registration.

Use client-based access control to support EU GDPR requirements

You can use client-based access control (CBAC) to satisfy the data privacy requirements of the European Union General Data Protection Regulation (GDPR) and similar regulations. By using client-based access control, you can identify the personal data of clients and automatically process requests to view, update, or remove the data in a secure manner. You can also enforce restrictions on the use of this data in application functions.

For more information, see Client-based access control.