SR-122213 · Issue 184299
Cache clearing corrected for muti-tenant environments
Resolved in Pega Version 7.1.8
A problem with the caching system in a multi-tenant environment led to a situation where a change in a rule in the shared layer did not invalidate that rule's entry in the tenants' rule cache. This was caused by the clearing of the cache not being fully propagated to all tenants, and the system has been updated to ensure the SMA clear cache fully clears all shared and tenant instances.
SR-122268 · Issue 184969
Tuned handling for child requestors in unauthenticated listener services
Resolved in Pega Version 7.1.8
While executing Queue instruction through JMS listener service, the error "Rule Not Found" was logged. This exception was due to a child requestor invoking the queue activity using the PegaRULES application instead of the current application. This was a side effect of changes made to the Service API which set the requestor authentication to true when the service package is unauthenticated, a change made to run activities that have enabled 'require authentication'. However, the credentials were not passed; the requestor was authenticated and the child requestor created was still unauthenticated, causing this issue. To resolve this, the system will set the access group from Service layer.
SR-122301 · Issue 182078
Revised max datetime value for validation
Resolved in Pega Version 7.1.8
Previously, a date property could have a max set value of 31-Dec-9999. This max date was not working in some time zones due to the input date being converted to GMT for internal operations. This meant that 31-Dec-9999 in some locales was getting converted to 1-Jan-10000GMT, which then failed validation. To correct this, the datetime validity logic has been changed to use "1st Jan 00:00:00.000 10000 GMT" for validation.
SR-122313 · Issue 183428
Database Class Report properly populating Ancestors column
Resolved in Pega Version 7.1.8
When running the Advanced->Reports->Database Class Report, the "Ancestors" column was not populated for tenant level classes. The problem was with the method used to create the report querying the ClassMap using normal, tenantized APIs instead of Shared, so no data was returned. This has been corrected and the class ancestor values are now properly populated in the generated csv file.
SR-122313 · Issue 181185
Database Class Report properly populating Ancestors column
Resolved in Pega Version 7.1.8
When running the Advanced->Reports->Database Class Report, the "Ancestors" column was not populated for tenant level classes. The problem was with the method used to create the report querying the ClassMap using normal, tenantized APIs instead of Shared, so no data was returned. This has been corrected and the class ancestor values are now properly populated in the generated csv file.
SR-122387 · Issue 183319
Expanded BIX error codes
Resolved in Pega Version 7.1.8
When BIX is executed through the command line, it may not return an error code even if BIX has stopped processing because of a failure (for instance when the -f flag has been used). That is, the $? system call may return 0 when an extract has failed. The system has been updated to offer more information thorough error code returns, but when trying to programmatically capture whether a particular run of BIX was successful or not, it would still be advisable to check $? in the script, as this may be returned due to other reasons (such as a java/network/database related problem). This may be augmented by performing a parse on the PEGABIX log file and specifically checking for the text: 'Instances not extracted due to errors: 0'. At the end of each BIX this line will appear with a summary of how many extracts failed. After the BIX portion of the script has completed, it's possible to check how many occurrences of this error appear in the file. If it is one, then this meant none of the extracts produced errors. And if there are none, then either some exports did contain errors, or it didn't reach the part of the code that produces this line (hence an earlier error). This can be incorporated into a script using something like: errorfree='grep "Instances not extracted due to errors: 0" PEGABIX.log | wc -l'
SR-122732 · Issue 182663
Cleaned up error logging for Oracle split schema multi-tenant upgrade
Resolved in Pega Version 7.1.8
When upgrading a multi-tenant environment with an Oracle split schema database, the log file was filling with warning messages on all tenant IDs during Rules upgrade. While errors are expected if there are tenants in the database that are no longer valid, the failure to resolve the tenant ID was being reported twice. In order to smooth the upgrade process, the log messages in this environment have been changed from warnForced to info, and each error will only be logged once.
SR-122738 · Issue 184536
Resolved extraneous error from Case Viewer imports
Resolved in Pega Version 7.1.8
Attempting to import specifications from Excel in Case Viewer to update specifications that were checked in was showing the error 'Update Fail'. The updated specification was successfully imported, but the new change is checked out to the user. This was an error generated by the final step of the Import Specification wizard and has been resolved.
SR-122820 · Issue 177433
Passivation thread logic improved
Resolved in Pega Version 7.1.8
It was noticed that the passivation daemon was triggering thread dumps several times a day, affecting performance and disk space. This was caused by threads in the process of being passivated inaccurately being reported as long-running. This has been corrected by changing the long-running thread detection to recognize threads in the process of passivation, and to bypass them unless there is a long-running passivation problem.
SR-122820 · Issue 182133
Passivation thread logic improved
Resolved in Pega Version 7.1.8
It was noticed that the passivation daemon was triggering thread dumps several times a day, affecting performance and disk space. This was caused by threads in the process of being passivated inaccurately being reported as long-running. This has been corrected by changing the long-running thread detection to recognize threads in the process of passivation, and to bypass them unless there is a long-running passivation problem.