SR-B38157 · Issue 301486
Added post-upgrade compatibility for agent tracing
Resolved in Pega Version 7.3
After upgrade, tracing agents was not working due to a change between versions in the method of tracing rules in rulesets of a remote requestor. Previously, rules were traced in the rulesets of the current requestor who initiated the trace; in newer versions, rulesets are fetched for batch requestors so all rules in rulesets accessible to browser requestor are not traced. In order to resolve this, a traceAllRulesets flag has been added for agent tracing so that all rulesets are traced and a note has been added to the settings window stating that in case of agents, all rulesets are traced.
SR-B38248 · Issue 293250
Rule search works after indexer cancel
Resolved in Pega Version 7.3
If the indexer was canceled from within the engine, the rule search function would not work until node restart. This was an error in the method used to call the cancel API, and has been corrected.
SR-B38330 · Issue 297411
Added code to ensure cursor closes on null-pointer exception
Resolved in Pega Version 7.3
Open cursor issues were occurring with out-of-the-box queries.SPPR_SYS_RESERVEQUEUEITEM_B Stored Proc when an exception was raised. Code has been added to ensure the cursor is closed in this situation.
SR-B38578 · Issue 295917
Fixed null-pointer exception in external DB extract
Resolved in Pega Version 7.3
When using a class which maps to a table in an external database, running an extract caused a database permission error when trying to access the pr_log table in the PegaRULES database. This exception was caught and logged but then processing continued, resulting in a NullPointerException being thrown. To correct this, the sequence number generator has been modified to use the pr_log table instead of the class on which extract is defined.
SR-B38578 · Issue 272419
Fixed null-pointer exception in external DB extract
Resolved in Pega Version 7.3
When using a class which maps to a table in an external database, running an extract caused a database permission error when trying to access the pr_log table in the PegaRULES database. This exception was caught and logged but then processing continued, resulting in a NullPointerException being thrown. To correct this, the sequence number generator has been modified to use the pr_log table instead of the class on which extract is defined.
SR-B39476 · Issue 297525
addCalendar() RUF logic updated
Resolved in Pega Version 7.3
The addCalendar() RUF logic has been modified to correctly set the operator time zone and correctly add the given years, months, days etc. This fix will be active based on a DASS setting as addCalendar() cannot be directly changed due to backward compatibility with DateTime issues.
SR-B39528 · Issue 303927
Node startup modified to support very large clusters
Resolved in Pega Version 7.3
Node startup was failing if the cluster had more than 50 nodes. This issue was caused by the query to the "pr_sys_statusnodes" table only returning 50 records; this limitation has been removed.
SR-B40706 · Issue 297501
Unmapped columns from an external table skipped in DDL query generation.
Resolved in Pega Version 7.3
The OBJ-SAVE method was generating a query in which unmapped columns were also getting updated. As these columns were not mapped, DB columns were being updated with the value NULL. This was due to the Obj-Save function always saving the entire object, causing an issue when only part of a table is mapped to a class. To correct this, new prconfig and DASS settings have been added to exclude unmapped columns of an external table as part of DDL query generation.
SR-B41030 · Issue 298187
Branch Merge Wizard shows up to 200 ruleset versions
Resolved in Pega Version 7.3
In the rule:pzGetVersionsForMerge List View, the page size has been changed from the previous limit of 50 to the new value of 200.
SR-B41398 · Issue 303897
Improved exception handling for "reset logging to default"
Resolved in Pega Version 7.3
After enabling debug level logging to a file, clicking "Reset all loggers to default settings" did not actually do so despite presenting a confirmation message. This was traced to incorrect handling for an exception, and has been fixed.