SR-131266 · Issue 199637
Cleared exception during import of RAP by prpcUtils
Resolved in Pega Version 7.1.8
When attempting to import a RAP file through command line by using prpcUtils.sh, the build was successful and all the rules were imported but an SQL exception was generated related to the execution of Stored Procedure. The RAP file did not contain any code to execute stored procedure, so the execution was found to have been done internally by prpcUtils.sh. To prevent this, prpcUtils has been updated to use the data schema as the default schema for the connection while running against either of the DB2 dbs.
SR-131347 · Issue 198661
Changed Dependency Checker table-based cataloging to be case insensitive
Resolved in Pega Version 7.1.8
After updating, the Dependency Checker and Packager functions for v5 items in the table-base catalog features were not finding existing cataloged items that contained mixed case IDs. To resolve this, the dependency checking code has been modified to be case insensitive.
SR-132265 · Issue 200632
Improved hotfix detection
Resolved in Pega Version 7.1.8
Migrating from ML6 to ML7 was failing with an error reporting the system contained hotfixes that were generated after the release of ML7. This was due to the ML Readiness step incorrectly identifying pre-7.1 rules as having been updated after the upgrade to 7.1.6. This happened when the revalidate and save was run after the release of ML7, which updated the pxUpdateDateTime for the rules in question and led to them being caught by the validation. This was meant to catch hotfixes, and the handling has been improved to avoid this error.
SR-A87552 · Issue 257706
Implicit privileges do not generate warnings
Resolved in Pega Version 7.2.2
RARO with implicit privileges was generating warnings that affected the compliance score. There is a particular format for declaring implicit privileges. i.e. Classname:ruleName, and the system has been updated with a check for this so implicit privileges will not be adding any guardrail warnings.
SR-A101006 · Issue 272734
JDBC password handling corrected
Resolved in Pega Version 7.2.2
After upgrade, a JDBC database connection on WebSphere 8.5/Oracle 11G indicated success on test connection, but a username/password "connection could not be obtained" error was thrown when attempting to save the connection. This was due to the handling of the encrypted password, and has been fixed.
SR-A101808 · Issue 269472
WebSphere deployment documentation updated to clarify JVM configuration advice
Resolved in Pega Version 7.2.2
The deployment guides for WebSphere have been updated to clearly distinguish between Oracle and IBM JVM when providing JVM configuration advice.
SR-A24989 · Issue 248910
WebSphere deployment guide updated to clarify scope settings
Resolved in Pega Version 7.2.2
The WebSphere Deployment Guide has been updated to indicate that the scope must be "server". If this is not set correctly in a split schema installation, the defaultSchema namespace bindings are defined at the cell level and will not be picked up at start, and the database user in the jdbc/PegaRULES datasource will not have the necessary privileges to run the system. Please see WAS deployment guides on the PDN for further information.
SR-B599 · Issue 270485
Flow Dependency queries performance improvements
Resolved in Pega Version 7.2.2
Case dependency queries executed by PEGA have been tuned to improve system performance when mid flow dependencies are getting fulfilled.
SR-A98702 · Issue 270066
Minor update to help doc for property optimization run time
Resolved in Pega Version 7.2.2
The help file for Property optimization using the Property Optimization tool has been updated with non-critical corrections to the phrasing regarding the length of time that might be required to perform background processing.
SR-A103064 · Issue 270247
Schema Change Tracking query performance improvements
Resolved in Pega Version 7.2.2
A query which was used in Schema Change Tracking (Designer Studio -> System -> Database -> Schema Change Tracking) was causing high CPU usage. This was due to the query having a full table scan which was using Information_schema, and the query has been rewritten for better efficiency.