INC-133583 · Issue 584923
Rest connector supports extended chars in attachments
Resolved in Pega Version 8.3.5
When the pyRequestAttachmentPage clipboard page was populated with a file name that contained Latin supplemental 1 unicode characters (decimal values 160 to 255 - for example an umlaut), any extended characters were being converted to question marks (?) before the call was sent, causing the web service call initiated by Pega to fail. To better support this use, an enhancement has been added to support a multipart request with extended characters in the file name. This allows the pyRequestAttachmentPage to specify pyFileNameExtendedChars, allowing RFC 6532 mode to be toggled for multipart requests with attachments. This mode allows for UTF-8 encoding in the attachment file name header, rather than the default ASCII encoding.
INC-143461 · Issue 601841
Updated JSON DT nested page property handling
Resolved in Pega Version 8.3.5
In a JSON data transform, when using an "Update page" step on a single-page property, as a child step of an "Append and map to" step where a pagelist property is given, the pagelist was populated with only one result but the single-page property was treated like a pagelist and received multiple results. This has been resolved by updating the ClipboardJSONDeserializer implementation and downstream abstractions to support "clipboard only" relations as properties in nested PageLists.
INC-139297 · Issue 601421
JSON content type update
Resolved in Pega Version 8.3.5
An update has been made to ensure the content_type is set to application/json for JSON response.
INC-107737 · Issue 544662
Oracle handling updated for upgrade DDL
Resolved in Pega Version 8.6
DDL generated for a Pega upgrade displayed the error "ALTER TABLE PC_ASSIGN_WORKBASKET DROP CONSTRAINT GETNEXTWORKINWORKGROUP" when trying to install. This was traced to a change made by Oracle for optimization, and has been resolved by updating the handling for primary key constraint and the corresponding index name.
INC-121480 · Issue 595823
EnableRedirects property added for REST connections
Resolved in Pega Version 8.6
When implementing a connector with the header “Location” which contains a redirect URI, a 303 response code was expected. Instead, a 400 or 404 error was generated. It was not possible for developers to process the code per their logic in Activity as Connect REST processed 303 responses automatically - i.e. there was no intercept points to implement the suggested approach. To resolve this, the new property "Rule-Connect-REST.pyEnableRedirects" has been added along with a checkbox for the property in "Rule-Connect-REST.pyService" in "Connection" section. Logic has been added in RESTConnector.java to take value of this property and set it on the HTTPClient being used, and a method has been added to HTTPClient interface and ComponentsHTTPClient to use the new value being passed. The default behavior is the same for the REST Connector, but a client can uncheck a checkbox on the REST Connector ruleform to stop the HTTP client from automatically following any compatible 3xx responses.
INC-122112 · Issue 599792
Updated SLA table clearance
Resolved in Pega Version 8.6
After cases were resolved, SLA entries were not getting cleared from the SLA table. This caused the SLA table to have a huge number of Overall SLA and PendFlow details present for cases that were resolved or moved to the next state, which impacted case processing via SLA Agent. This was traced to SLA queue-items not being removed by delete-deferred as expected, and has been resolved by invalidating the deferred operations and scheduling item removal.
INC-125258 · Issue 601606
Documentation updated for troubleshooting rules counts
Resolved in Pega Version 8.6
The troubleshooting documentation has been updated with extended information regarding correcting incorrect rule counts in dashboards and reports.https://community.pega.com/knowledgebase/articles/pega-platform-troubleshooting/troubleshooting-incorrect-count-rules-dashboards-and-reports
INC-125633 · Issue 589578
Optimizing helper class enhanced to handle external databases
Resolved in Pega Version 8.6
Running a BIX extract that included a manifest for a target database was resulting in a null pointer exception for the manifest extraction. Attempting to generate the DDL for the manifest table also failed. This was traced to an issue with the helper class using a hardcoded default database for forming the queries, causing it to ignore the database config/DADN/prconfig for the Oracle database and form a query using the PegaRules' database credentials. This only occurred when trying to do external database operations on a different database platform; Oracle PegaRules worked as expected with an Oracle external database and Postgres Pegarules worked with a Postgres external database, but mixing Postgres PegaRules and an Oracle external database would result in the null pointer exception. To resolve this, the helper class has been enhanced to work with external databases by passing the database name as a parameter so it will properly calculate the query based on the type of target. An error in the name of the class has also been corrected, and is now available as PerformanceHelper rather than the previous "PerformaneHelper".
INC-125972 · Issue 604081
Improved resolved rules cache
Resolved in Pega Version 8.6
When Rule resolution iterated over a candidate list to fetch a candidate, performance issues were seen on very large sites. To resolve this, an enhancement has been added that will cache the resolved virtual table entries to optimize performance in high demand use cases like DSM.
INC-128800 · Issue 592823
Additional DSS added to handle Apache client-level timeout
Resolved in Pega Version 8.6
In Connector rule, the system timed out a connection after 1 hour even after a connection time timeout was configured to be 30 seconds. Apache's refactoring of their HTTPClient in version 4.3 specifies request timeouts in two ways: on the client-level and on the request-level. Client-level timeouts are enforced prior to and during the handshake, whereas request-level timeouts are enforced after the handshake has been made. Previously, RESTConnector.java and ComponentsHTTPClient.java were configured to only set the user-specified timeout on the request, and not on the client. This caused the client-level timeout to default to "0", or an infinite amount of time. In this reported issue, the remote host closed the connection before the handshake had been completed so the connection remained open for several hours. To resolve this, the DSS "ClientLevelHTTPTimeout" has been added to allow specifying a client-level socket timeout, and ComponentsHTTPClient.java and RESTConnector.java have been amended to assign this value to the client. This DSS is set to 0 by default to preserve backwards compatibility.