Skip to main content

Resolved Issues

View the resolved issues for a specific Platform release.

Go to download resolved issues by patch release.

Browse release notes for a selected Pega Version.

NOTE: Enter just the Case ID number (SR or INC) in order to find the associated Support Request.

Please note: beginning with the Pega Platform 8.7.4 Patch, the Resolved Issues have moved to the Support Center.

SR-B5672 · Issue 280747

Corrected and improved calculations for multiple page Business Calendars

Resolved in Pega Version 7.3

The Business Calendar time zone was not correctly populated when a second page was added to the calendar. This was due to the new page using the operator time zone instead of the business calendar time zone, and has been fixed. In addition, the difference calculations for calendar processing have been improved for greater accuracy.

SR-B5672 · Issue 283549

Corrected and improved calculations for multiple page Business Calendars

Resolved in Pega Version 7.3

The Business Calendar time zone was not correctly populated when a second page was added to the calendar. This was due to the new page using the operator time zone instead of the business calendar time zone, and has been fixed. In addition, the difference calculations for calendar processing have been improved for greater accuracy.

SR-B5813 · Issue 276080

DuplicateProperty checked on enqueue

Resolved in Pega Version 7.3

The enqueue() method of PRQueueManager was not honoring the "pyDuplicateProperty" value of the existing queue items which have a higher pyMinimumDateTimeForProcessing. To correct this, QueueManagerImpl has been modified so the enqueue() method uses an overloaded version of next() method which is intended to ignore pyMinimumAgeForProcessing when checking for duplicates.

SR-B613 · Issue 273665

Null check added to RecalculateAndSave

Resolved in Pega Version 7.3

A null-pointer exception occurred during an index operation within the deferred save in RecalculateAndSave due to the context page being null during declare index processing. A null check has been added for the context page to resolve this.

SR-B6244 · Issue 277566

BIX extraction config documentation updated

Resolved in Pega Version 7.3

When using command-line BIX 7.1 to extract records and write them to a secondary database, it appeared that some of the records got skipped. This was actually expected behavior: as the records got updated while the extract was running, those particular updated records got skipped as they did not fall into the time range that user was passing. To eliminate this confusion, the log message has been clarified. In addition, the information in the Guide indicated that if bix/useHistoryClasses was set to true, the generated query should always use the history table and not the actual work object table. However, it was not made clear that the BIX code does not use this option for explicit command line arguments. Therefore, the following text has been added to the BIX documentation under "Configuring the extraction environment" -> "Configuring optional prconfig.xml settings": Including class instances added during a batch run To ensure that class instances added to the Pega Platform database after a batch run begins execution are included in the extract, add the following property:

SR-B6244 · Issue 277566

Documentation and log messages updated for BIX/useHistoryClasses

Resolved in Pega Version 7.3

When using command-line BIX 7.1 to extract records and write them to a secondary database, messages from the system gave the impression that some of the records were skipped. This was due to a mismatch in the number of records reported at different points in the extraction: as the records got updated while the extract was running, those particular updated records got skipped as they did not fall into the time range that user was passing. To avoid this confusion, the text in the logs has been clarified to read: "Processing Class class name with XXXX instances (processing count may vary as records get modified before BIX extraction)." In addition, the documentation regarding the usage of the BIX/useHistoryClasses option has been updated to reflect this information.

SR-B6288 · Issue 281534

Resolved agent schedule skipping a day in some conditions

Resolved in Pega Version 7.3

When a schedule was set to recurring for specific days at a certain time, restarting the system or changing the agent schedule close to midnight from a different time zone caused the schedule run time to skip a day. This was traced to a mis-match in the calendar runtime calculation logic between the time zone and the time being set when the agent and server are configured to run on different time zones, and has been corrected.

SR-B7225 · Issue 277782

BIX documentation updated for Extract Rules

Resolved in Pega Version 7.3

The documentation outlining best practices for using BIX has been updated to reflect that when extractions are being run asynchronously there must be enough threads for each of the concurrently running extractions. The section "Running an Extract rule using a Pega 7 Platform agent" has been updated to read: "Number of concurrent extracts scheduled has to be limited based on the prconfig "agent/threadpoolsize." Set the prconfig setting agent/threadpoolsize to the max number of concurrent extractions you will be executing. The default value for this setting is 5 and the maximum value is 10.

SR-B8129 · Issue 280611

Resolved DATA-ADMIN-LOOKUPLIST authentication error

Resolved in Pega Version 7.3

After upgrade, the security access error "You lack access required to execute RULE-OBJ-ACTIVITY DATA-ADMIN-LOOKUPLIST was encountered while performing an obj-save during the creation of a Modal operator ID. This was traced to a difference in how an authentication activity was called, and has been fixed.

SR-B8133 · Issue 277199

Support added for cloning SLA agents

Resolved in Pega Version 7.3

The SLA worker agent was not working as expected based on a prior recommendation to clone agents. The cloned agents are not handling any requests. The original agent is still working, but all 3 clones do not perform any work. 6 nodes, for agents per node, and on each node only the original node is working. Cloned agents were not processing work in production if they were duplicated from SLA agents. In order to support this use, a new feature has been added to agent to allow dequeueing pages queued for another agent. This new configuration setting clones Pega-ProCom to multiple custom rulesets or creates a new agent rule in a custom ruleset with multiple rows for the ServiceLevelEvents agent in that rule. Example:

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us