SR-A99141 · Issue 270060
Class visibility of System-Ruleset-Index made Tenant Only
Resolved in Pega Version 7.2.2
The class visibility of System-Ruleset-Index has been modified to Tenant Only.
SR-A99858 · Issue 266990
Added config for size of Hazelcast async thread pool
Resolved in Pega Version 7.2.2
The default size of the async thread pool was calculated by Hazelcast as a multiple of the number of CPU cores, so on vary large servers (which support many JVMs) each JVM had many more threads than necessary and performance issue were noted. To resolve this, an enhancement has been added to allow the maximum asynchronous thread pool size to be configured through a prconfig.xml setting called "Hazelcast/async/thread/count".
SR-B2504 · Issue 272623
pxCommitDateTime BIX extraction more robust
Resolved in Pega Version 7.2.2
The exported XML file was not including the pxCommitDateTime column even when that column was included in the BIX extraction. This was traced to the site trying to perform the commit on the same work object more than once: performing the commit the second time caused the previous value to be overridden by the new commitdatetime. That led to the pxCommitDateTime not being stored in the BLOB, and since BIX extracts the data from source table's BLOB, it cannot extract the value of pxCommitDateTime. To resolve this, the source query that BIX uses has been modified to get both pzPVStream and pxCommitDateTime (if the column is present in the source table) and use the value of pxCommitDateTime from the resultset while writing to the output file.
SR-A98078 · Issue 270393
FlowActionPlayback supports Activity with class name
Resolved in Pega Version 7.2.2
The logic in FlowActionPlayback has been updated to support a pyActivity parameter that also contains the class name. The classname will be trimmed and the primarypage class name only will be used for further activity resolution.
SR-A95046 · Issue 263375
Master Agent exception resolved
Resolved in Pega Version 7.2.2
The Master Agent generated an exception while expanding a property with backreferences on a ReadOnly ClipboardPage while trying to estimate the size of all Node level data Pages. This has been fixed.
SR-B380 · Issue 270771
New round function for Expression Builder
Resolved in Pega Version 7.2.2
The round(...) function in Expression Builder was not working as expected due to the engine not supporting the use of "Number"(Java type) as an input parameter. In order to resolve this, a new RUF has been provided: pzRound--(BigDecimal,BigDecimal), which will change the Number parameter to BigDecimal/ int, which is a parameter supported by the engine.
SR-A92264 · Issue 268673
Handling added for Connection Closed exception in Rule Search index
Resolved in Pega Version 7.2.2
The Search Index process was completing for Work and Data instances but stopped for Rules at around 65,000 records. This error occurred when Pega returned a database Connection back to the JDBC connection pool once the current request processing is complete: Pega checks if auto commit is marked to the appropriate value before returning the connection back to the pool, but an error occurred. The code now handles the Connection Closed Exception and removes the bad connection from the pool when appropriate.
SR-A85931 · Issue 254345
Class loader resource workaround for CyberArk
Resolved in Pega Version 7.2.2
The use of CyberArk (a 3rd party password manager) to secure database connections resulted in an infinite loop while trying to obtain a db connection. The CyberArk client "walks" the call stack and tries to obtain the URL of each class (resource) in the call chain to verify that all jars referenced are "authorized" to obtain the password, and it is not possible to disable this logic. The loop issue happened because the Pega 7 class loaders read the database during the process of generating the URL for a class, causing another db connection to be requested and starting the validation process again. In order to provide a workaround for the lack of customization in CyberArk, the class loaders have been modified to optionally bypass reading the database when a URL is requested for a CLASS resource (all other resource types must still go to the database to check for existence). The new behavior is enabled by setting the Java system property -Dcom.pega.prminiloader.avoiddbforgetresource=true. (The flag must be a Java system property because it has to be read before any database operations are performed.)
SR-A85937 · Issue 254344
Class loader resource workaround for CyberArk
Resolved in Pega Version 7.2.2
The use of CyberArk (a 3rd party password manager) to secure database connections resulted in an infinite loop while trying to obtain a db connection. The CyberArk client "walks" the call stack and tries to obtain the URL of each class (resource) in the call chain to verify that all jars referenced are "authorized" to obtain the password, and it is not possible to disable this logic. The loop issue happened because the Pega 7 class loaders read the database during the process of generating the URL for a class, causing another db connection to be requested and starting the validation process again. In order to provide a workaround for the lack of customization in CyberArk, the class loaders have been modified to optionally bypass reading the database when a URL is requested for a CLASS resource (all other resource types must still go to the database to check for existence). The new behavior is enabled by setting the Java system property -Dcom.pega.prminiloader.avoiddbforgetresource=true. (The flag must be a Java system property because it has to be read before any database operations are performed.)
SR-A89181 · Issue 257344
Connect-Wait made more robust for timeouts and multiple calls
Resolved in Pega Version 7.2.2
To check an asynchronous thread running for a long time, a connect-wait was given multiple checks for the same pool id. On first execution of this connect-wait, it was unexpectedly timing out before hitting the timeout settings in the parameter. For all of the subsequent calls to connect-wait, it was waiting for the asynchronous thread to complete, i.e. exceeding the timeout limit. Normally Connect-Wait is called once and the wait time defaults to the point where data page load finishes. In this particular use case, when connect-wait hit the timeout due to a user-specified value, the system considered it an error state and cleaned up the pool ID from the thread. The subsequent waits were failing due to the mapping for the pool ID being removed when first Connect-Wait call ended with timeout. To support this use, better handling has been added for the user-specified timeout, and the system will not clear the mapping for the pool ID if Connect-Wait ended due to timeout. In cases where another Connect-Wait request does not come, the mapping will be cleared when the thread terminates.