New Features by Release
New in Hot Fix 220.127.116.11
GRE Memory Monitor
The Memory Monitor is a new feature built in to GRE itself. It is designed to periodically check GRE's memory usage, and set its operational state to "over threshold" if memory usage exceeds the configured threshold. The state is reset to back to "normal" if memory usage comes back below the threshold. It also provides an option ("adaptive" strategy) to automatically adjust the configured threshold if an out-of-memory error occurs before threshold is reached (for example, if the configured threshold was set too high).
The memory monitor sets this state in two places:
- status.jsp—This .jsp provides a "health check" URL for load balancers to use. If the memory usage is above the configured threshold, status.jsp returns SYSTEM_STATUS_MEMORY_USAGE_ABOVE_THRESHOLD (HTTP 503 status). Load balancers should be configured to route requests only to GRE nodes whose status.jsp returns SYSTEM_STATUS_OK (HTTP 200 status).
- Genesys Management Layer—The Memory Monitor will also notify Genesys Management Layer if the memory is in an overloaded state by setting the status to SERVICE_UNAVAILABLE.
New in Release 8.5.2
GRS Rules Authoring REST API
In this release, API functions to manage Rule Packages, Rules, Business Calendars, Snapshots and Deployment are provided. Applications or custom user interfaces (which can run in parallel to or instead of the Genesys Rules Authoring Tool web application) can use this API to perform rule authoring and deployment. Please see the GRS REST/API Reference Guide.
Cluster Deployment Improvements for Cloud
In this release, partial deployments and auto-synchronization of rules packages between cluster members are now possible.
If GRAT’s CME Application ID is replaced (such as in the scenario in Important below), you must do one of the following for auto-synchronization to work correctly. Either:
- Redeploy all the rule packages to the cluster; or;
- Update the configuration—this may be preferable to redeploying all rule packages (for example, because of a large number of rule packages)
Redeploy all the rule packages to the cluster
If auto-synchronization is enabled and deployment to the cluster cannot be performed, follow the steps below to deploy to the GREs individually:
- Temporarily disable auto-synchronization in the GREs by setting option deployed-rules-directory-is-relative-to-shared-root to false.
- Redeploy all the rule packages to the GREs.
- Once the rule packages have been deployed to all the GREs, reset deployed-rules-directory-is-relative-to-shared-root to true.
If auto-synchronization is disabled and deployment to the cluster cannot be performed, the rule packages can be deployed to all the GREs individually without requiring any additional settings.
Update the configuration
In the Tenant configuration, update option next-id, which is available under the Annex settings section in a Script Schedule-XXXX ( where XXXX is GRAT’s configuration Application ID) corresponding to the new GRAT Application, with the value from script corresponding to the previous GRAT Application.
Option path in Configuration Manager:
Configuration > [Tenant Name] > Scripts > Rule Deployment History > Schedule-[Id of GRAT App] > Annex > settings > “next-id”
Option path in Genesys Administrator:
PROVISIONING > [Tenant Name] > Scripts > Rule Deployment History > Schedule-[Id of GRAT App] > Options (with Advanced View (Annex)) > settings > “next-id”
If the Tenant name is Environment, the new GRAT configuration Application ID is 456 and the old GRAT configuration Application ID is 123.
Using Configuration Manager:
Copy the value of option:
Configuration > Environment > Scripts > Rule Deployment History > Schedule-123 > Annex > settings > next-id
Configuration > Environment > Scripts > Rule Deployment History > Schedule-456 > Annex > settings > next-id
Using Genesys Administrator:
Copy the value of option:
Configuration > Environment > Scripts > Rule Deployment History > Schedule-123 > Options (with Advanced View (Annex)) > settings > next-id
Configuration > Environment > Scripts > Rule Deployment History > Schedule-456 > Options (with Advanced View (Annex)) > settings > next-id
Limitations in the Initial 8.5.2 Release
- The auto-synchronization feature does not include undeploy functionality.
- A GRE cannot be a member of more than one cluster. This is because GRE checks all the clusters in the Genesys configuration environment to see which one has a connection to the GRE. If there are multiple such clusters, only the first one found is considered; any others are ignored.
- GRE can operate either singly or as part of a "smart cluster", but not both.
- High Availability (HA) for the cluster shared folder is not currently implemented. If HA is required, for example in multi-site deployments, Professional Services must make sure that the shared folder is set up in HA mode.
Support for WebSphere Clustering for Cloud
In this release, it is now possible to define multiple nodes for the same host by using an additional attribute called servername in the node definition.
See also an additional WebSphere configuration change required for auto-synchronization to work.
Support for Safari 8.x
Release 8.5.2 supports the Safari 8.x browser.
Enable/Disable Business Calendars
Genesys Web Engagement did not originally support Business Calendars in its Complex Event Processing (CEP) engine. However, support is being added in release 8.5.0. Use the new GRAT enable-cep-calendars configuration option to enable or disable business calendars for rules that are based on a CEP template.
New in 8.5.1
New Features in 8.5.1 (new document)
New in 8.5.0
New Features in 8.5.0 (new document)