SR-122197 · Issue 182685
Resolved Connect SOAP header mapping issue
Resolved in Pega Version 7.1.8
In the Connect SOAP rule, a Request tab configured with a Request Header field using XML Stream option was missing the PEGA tag in the generated SOAP header. This was caused by an error in the Axis stack and has been corrected to ensure all elements defined in the MapFrom XML rule are correctly generated.
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-122230 · Issue 180223
Datetime properties format improved for backwards compatibility
Resolved in Pega Version 7.1.8
After upgrading, the search API was returning datetime properties in an incorrect format, causing a page error that was sometimes visible to an end user. The error only occurred if additional processing was happening in that page that caused the validation dictionary to launch. The root cause of this problem was a backwards compatibility defect related to Elastic Search, and it has been corrected.
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-122529 · Issue 184997
Creation and testing corrected for ATOM server connection using Alfresco 4.2
Resolved in Pega Version 7.1.8
When creating a new ATOM Server instance with Alfresco 4.2, an error was logged and shown on the screen. This process worked with Alfresco 4.0. In the process of upgrading openCMIS jars, Atom and SOAP server connectivity tests were also changed to use HTTP, and Atom Server connectivity tests should now work for all versions of Alfresco.
SR-122613 · Issue 185054
"Apply Rule" form UI updated
Resolved in Pega Version 7.1.8
After migration, the XML Configuration Rule form "Apply Rule" had inconsistent fields labels after converting the rule form to autogenerated. The UI has been updated to present the labels in the same manner as prior versions to avoid confusion.