New process for Pega Cloud customers to obtain BIX extract files
Valid from Pega Version 7.3
The process for obtaining Business Intelligence Exchange (BIX) extract and manifest files for Pega® Cloud customers has changed as a result of data security enhancements for HIPAA compliance. By default, after upgrading to Pega 7.3, you must obtain the BIX extract and manifest files from the Pega SFTP server. From within Designer Studio, you can configure the BIX extract and manifest files to be sent to a remote SFTP server by a file listener. For Pega Cloud customers who have purchased a Pega Cloud SFTP Server subscription, you can configure BIX to send the BIX extract and manifest files to the SFTP server's folders for remote SFTP client download.
For more information about obtaining files from the Pega SFTP server, see Obtaining BIX extract files from the Pega SFTP server.
For more information about having files sent to your SFTP server, see Defining SFTP-related data instances.
Adaptive Decision Manager installation changes to support delayed learning
Valid from Pega Version 7.1.7
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
Option to resume failed upgrades and updates
Valid from Pega Version 7.2.1
When you upgrade or update to Pega 7.2.1, you can opt to have the system resume the deployment after a failure to avoid restarting the deployment and to save time. The deployment resumes at the point of failure and does not repeat any successful steps. This functionality is not supported for new installations. For more details, see the Pega 7 Platform Upgrade Guide and the Pega 7 Platform Update Guide.
Improved application performance when responding to SOAP requests
Valid from Pega Version 7.2
When an application serves multiple requests, the contention placed on the ContextHash class is reduced because all threads can concurrently access the mHash instance variable, which improves performance. To experience this benefit, redeploy the prweb.war file for web tier deployment or redeploy the prpc_wls_jee4.ear file for e-tier deployment.
External data flow rules are removed
Valid from Pega Version 8.6
In previous versions of Pega Platform™, you could configure data flows to run in an external Hadoop environment. The external data flows functionality was deprecated and hidden from view in Pega Platform 8.5. The functionality has been now removed and is no longer available in Pega Platform 8.6.
For more information, see External data flow rules are deprecated.
X-Forwarded-Host field is optional for HTTP proxy servers
Valid from Pega Version 7.3
Prior to Pega® Platform 7.3, the X-Forwarded-Proto
and X-Forwarded-Host
fields were both required to deploy Pega Platform instances behind an HTTP proxy server. Some proxy servers or load balancers (for example, Amazon ELB) do not support the X-Forwarded-Host
field. Starting with Pega 7.3, only the X-Forwarded-Proto
field is required. For more information, see Deployment behind a reverse proxy.
Data model inheritance does not depend on ruleset context
Valid from Pega Version 8.6
Search and Reporting Service (SRS) in Pega Platform™ 8.6 now provides an improved method of synchronizing data model by distinct users. In applications built on earlier versions of Pega Platform, some users might encounter difficulties in indexing data. Now, the data model that the system sends to SRS does not depend on access privileges. With this enhancement, each user of your application is eligible to synchronize data.
Elasticsearch 2.4.0 upgrade
Valid from Pega Version 7.2.2
The Pega 7 Platform has been updated to use Elasticsearch 2.4.0. You do not have to reindex immediately. You can reindex at your convenience by using the FullTextindexer utility, which provides a smoother transition to the next Elasticsearch library upgrade.
Rolling upgrades are not supported. Instead, after the upgrade has been completed, shut down all the nodes in the cluster, and then restart them beginning with the indexing nodes. For more information, see the Pega 7 Platform Upgrade Guide on the Deployment Guides landing page.
Greater cluster stability with client-server clustering topology
Valid from Pega Version 7.3
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.
View and apply schema changes when upgrading or updating
Valid from Pega Version 7.2.1
When you upgrade or update, you can view the schema changes to the default work and history tables and apply the changes to your cloned tables. By applying the changes, you improve performance and can take advantage of the latest reports on those tables.
For information about viewing and applying schema changes as part of the upgrade or update, see the Pega 7 Platform Upgrade Guide or the Pega 7 Platform Update Guide.
For information about using the Designer Studio tool or the command-line tool, see Updating cloned tables after an upgrade or update.