Published Release Notes

Flow action and attachment category rule types moved to Process category

The flow action and attachment category rule types now appear in the Process category within the Record and Application Explorers. Previously, they were in the User Interface and Security categories, respectively.

Adaptive Decision Manager installation changes to support delayed learning

To support delayed adaptive learning, Adaptive Decision Manager (ADM) has been enhanced with database schema changes and no longer relies on Hibernate. This change has an impact in the way ADM is set up in the Decision Management service layer: the jdbc/admDataSource resource is now superseded by jdbc/adm7DataSource.

Additionally, Pega 7.1.7 further simplifies the ADM deployment by providing a single enterprise application or web archive:

• Single EAR deployment archive that can used when deploying ADM on IBM WebSphere and Oracle WebLogic
• Single WAR deployment archive that can be used when deploying ADM on Tomcat and JBoss

Maintainable warning, error, and tip information

Use the redesigned Message form to define warning, error, tip, or custom category information in your application. Encapsulating these details in a message makes them easier to maintain and review. After you have created a new warning, you can quickly add it to a rule in your application using the new pxAddGuardrailMessage function.

For more information on the tabs and available fields on the Message form, see About Message rules.

Report Viewer provides simplified user experience

In the Report Viewer, improvements simplify the user experience when working with reports. Column headers display initial sort order and type, and you can hover over a column header to display and use its context menu, which includes options for ad-hoc sorting and filtering. Developers can specify various pagination modes and set an option to keep the header in view while users scroll through the report.

For more information, see Report Viewer.

Easy-to-browse warning catalog

All Pega 7 warnings have been converted to Rule-Message instances, each with a clearly written, risk mitigation path. This allows you to use the Records Explorer to browse through all warnings in the system, organized by category. To view warnings associated with specific rules in your application, refer to the Application Guardrails landing page.

Enhanced BIX file naming

To help clarify file names, BIX extract output files and manifest files can now contain parameters. Parameters can include the rule name, the extract's run time and date, and a unique run sequence number. Special characters such as spaces, hyphens, or number signs (#) in the output or manifest file name are converted to underscores. In addition, the pxExtractIdentifier and pxExtractDateTime columns have been added to the .csv output file.

For more information, see Extracting data with BIX and Extract rules - completing the File Specification tab.

Communicate guardrail compliance with the pxAddGuardrailMessage function

Now that guardrail warnings are in the model, you can easily attach them to rules in your application using the new pxAddGuardrailMessage function. Call this function to display warnings to your application users when they do not adhere to guardrails or best practices. Adopting this function in your application allows you to:

• Use localizable Rule-Message instances that are categorized by severity and application impact.
• Add dynamic warnings to your rules by passing parameters to a standard or custom message.
• Stop using and maintaining hard coded strings.

Design time view of warning messages

Run time view of an attached warning

This function supersedes the addWarning function, which has been deprecated. You can continue to use the CheckForCustomWarnings extension point, but it is recommended that you convert hard coded strings to messages and migrate any dependencies on addWarning to pxAddGuardrailMessage.

For more information on message attaching techniques, see Working with messages.

Improved full text search

In Pega 7.1.7, Elasticsearch is used to provide full-text search functionality for rules, work, and data content, replacing the existing Lucene search functionality. In addition to providing search results two to five times more quickly than with Lucene Search, Elasticsearch is more scalable: with multi-threaded bulk and incremental indexing, it provides enhanced information about the search queue, the ability to host index files on multiple nodes, a more robust and expressive search parser, the ability to configure thresholds for alerts and search query time-outs, and automatic handling of replication and failover.

The search management user interface, where you can see length of queue and age of entries, which node hosts the search index, and where it is located.

After upgrading to Pega 7.1.7, the system administrator must manually migrate search functionality from Lucene Search to Elasticsearch. Note that during the switch-over and until the indexes are rebuilt, Lucene search continues to function and there is no interruption in search functions. For more information, see the Pega 7.1.7 Upgrade Guide.

Track custom details with extensible messages

The customizable Message form gives you the freedom to expand upon default categories, store application specific data in a message, and enforce specialized validation. Leveraging these options makes it easier for you to identify a specific variety of message and incorporate new properties into your existing message processing logic.

For more details on which rules to override, see How to extend the Message form.

Collections more effectively model business decisions

Use the redesigned Collection form to model business logic or implement rule engine patterns in your application. This form is now located in the Decision rule category.

You can add response actions to each collection step to process return values transparently, and simplify your implementation by calling a function alias or when condition instead of an activity. Use one of the supported Stop methods to cease processing in the current collection or all collections in the call stack.

For more information on the available features on this rule form, see About Collection rules.