Published Release Notes

Data schema error on z/OS split schema upgrades from versions before Pega 7.1.8

When upgrading to a split schema on Pega 7.x with IBM DB2 for z/OS, you see an error during the data schema upgrade when the system tries to drop the PRPC_Updatescache procedure. Because triggers on rules tables use PRPC_Updatescache, you must use the ZOSDisableTriggerScripts to disable these triggers before you update the data schema.

1. Follow the instructions in the Pega 7 Platform Upgrade Guide to upgrade the rules schema, but stop immediately before you upgrade the data schema with the upgrade.bat or upgrade.sh script. The Pega 7 Platform Upgrade Guide is on the Support > Deployment Guides page.
2. Copy the contents of the <distribution>\ResourceKit\ZOSDisableTriggerScripts directory into the <distribution>\scripts\ directory.
3. Run fixZosTriggers.bat or fixZosTriggers.sh with the following arguments:
   --action preupgrade
--dataschema <data schema name>
   --oldrulesschema <old rules schema name. If you are upgrading from a single-schema system, this is the data schema name.>
   --newrulesschema <new rules schema name>
   --automaticddl <Optional. Set to true to automatically apply the disable trigger SQL scripts.>

   For example:
   fixZosTriggers --action preupgrade --dataschema pegadata --oldrulesschema pegarules --newrulesschema newrules --automaticddl false

4. If you did not set --automaticddl to true in the previous step, run the <distribution>\schema/disable.sql script to manually disable the trigger SQL scripts.
5. Run the data schema upgrade as described in the Pega 7 Platform Upgrade Guide.

Batch database processing improvements

Batch database processing has been enhanced to ensure that a constraint violation does not occur when you save transactions to a table with a foreign key dependency. Because batch processing changes the order of save operations, it is disabled for transactions with foreign key dependencies. Disabling batch processing ensures that a record with a foreign key dependency on another record will not be written before the record on which it is dependent.

For more information about how batch database processing works and how to enable and disable it, see Batch processing during database write operations.

Improve cluster security by limiting concurrent operator sessions

You can increase the security of a Pega^® Platform cluster by limiting the number of concurrent sessions allowed for each operator. Because operators typically do not require multiple concurrent sessions for performing their work, limiting the number of sessions reduces the chance that an unknown or untrusted person could access systems in the cluster. Use the new setting Number of concurrent sessions allowed for each operator on the Production tab of the System Data Instance form to configure the number of concurrent sessions for operators. You must restart your system when you change this setting. You can also create a list of operators by using the presence/maxsessions/operators/whitelist Dynamic System Setting, to which the maximum number of concurrent sessions setting will not apply.

For more information, see System form - Completing the Production tab.

New System Queue Management landing page

You can manage your system queues from the new System Queue Management landing page. You can use this landing page to quickly and efficiently debug applications without exiting Designer Studio. In addition to viewing items in a queue, you can defer, remove, and requeue items in a queue, stop items in progress, and view an item's XML.

As a result of this enhancement, the Broken Queue landing page has been removed.

For more information, see System Queue Management landing page.

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.

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.