Published Release Notes

Support for encrypted communication between nodes

Communication between nodes can now be encrypted for systems that use Ignite clustering. Encryption is useful when compliance rules require all intracluster communication to be encrypted, for example, to comply with HIPAA regulations. To support encryption, the underlying clustering technology has been changed from Hazelcast to Ignite.

For information about enabling encryption between nodes, see Enabling encrypted communication between nodes.

Data encryption across search nodes

You can now encrypt communication among search nodes. Encryption secures the data that is transferred across nodes so that it cannot be accessed by unauthorized hosts. Encryption is enabled by default for new installations and upgrades from Pega^® 7.1.6 or earlier to Pega 7.3. Encryption is not enabled by default for upgrades from Pega 7.1.7 or later to Pega 7.3. You can enable and disable search encryption from the Search landing page or by using the indexing/distributed/enable_inter_node_encryption Dynamic System Setting.

For more information, see Enabling and disabling encryption for communication among search nodes.

Upgrade/update fails if PostGIS is applied to PegaRULES or PegaDATA schema

If you use the PostGIS extension to a PostgreSQL database, upgrading or updating the Pega 7 Platform fails if the extension has been applied to either the PegaRULES or PegaDATA schema. PostGIS can be applied to any other schema.

Primary key constraint error when using JBoss

A primary key constraint violation exception might occur in the following situation: you use JBoss EAP 6.4 and SQL Server 2012 with a JDBC 4 driver, and you use two or more file listeners or JMS MDB listeners with concurrent threads that create work objects that use multiple files. If a primary key constraint violation exception occurs in this situation, update the data source configuration file to set the jta parameter to true. For example, set <datasource jta="true" jndi-name-"java:/jdbc/PegaRULES>.

Node classification

By using the node classification feature, which segregates nodes by their purpose, you can now configure one node with multiple node types. When you start a node with multiple node types, the node runs a set of agents and listeners that are associated with the specified node types. From the Node Classification landing page, you can view and configure the agents associated with node types, view listeners associated with node types, and open Agent rule forms, agent schedules, and Listener rule forms.

For more information, see Node Classification, Configuring node types for agents and listener and Node classification.

Support for Couchbase Server NoSQL database

Pega^® Platform can now read data from and write data to a Couchbase Server database. Couchbase is a NoSQL database that you can use when a NoSQL database better meets your scalability and processing requirements.

For a list of supported and unsupported features, see Couchbase Server support.

Node types renamed after upgrade from Pega 7.2.2 to Pega Platform 7.3

If you used node classification in Pega^® 7.2.2, when you upgrade to Pega 7.3, node type names are automatically changed to a new name when you start a node with a node type.

• UniversalNode becomes Universal
• WebUserNode becomes WebUser
• BackgroundProcessingNode becomes BackgroundProcessing
• BIXNode becomes BIX
• SearchNode becomes Search

If you created agents in Pega 7.2.2, agent schedules are also automatically updated with a new name during the upgrade. For more information, see Customized agent schedules for standard Pega Platform agents must be updated after Pega 7.2.2 to Pega Platform 7.3 upgrade and the appropriate Deployment Guide.

SystemCleaner agent is split into node-level and cluster-level agents

The Pega-RULES:SystemCleaner agent has been split into node-level and cluster-level agents to avoid database performance issues. The new node-level agent, Pega-RulesEngine:NodeCleaner, runs on all the nodes in the cluster, while the new cluster-level agent, Pega-RulesEngine:ClusterAndDBCleaner, runs on only one node in the cluster. If you customized the agent schedules of the Pega-RULES:SystemCleaner agent, you must manually update the agent schedules of the new agents because customized schedules are not retained.

For more information, see Agent schedule data instances – Completing the Schedule tab.

Greater cluster stability with client-server clustering topology

You can now deploy Pega^® Platform in the new client-server clustering topology that uses Apache Ignite, which increases stability in large clusters and provides independent scalability for both servers and clients. This technology separates the client nodes, which are responsible for Pega Platform processes, from the server nodes, which are responsible for cluster communication and distributed features. If your production environment consists of more than five nodes in the cluster, it is recommended that you switch to the new client-server topology.

For more information, see Apache Ignite client-server clustering topology and the appropriate Deployment Guide.

Create pre-import and post-import steps

To take specific actions based on archive metadata, add pre-import and post-import action steps to collections. For example, you can configure a pre-import activity to automatically verify that an archive meets certain criteria before you import the archive. If the archive does not meet the criteria, Pega^® Platform does not import the archive.

For more information, see Pre-import and post-import collections.