Summary
In order for rules to be invoked by Genesys applications, you must deploy the rule package to one or more Genesys Rules Engines (or for Genesys Web Engagement, to the GWEB backend server). The deployment process (whether you choose to deploy immediately or to schedule the deployment for later) attempts to compile the rule package and informs you of the result via the Deployment Pending pop-up message. You can check on the status of your deployment by looking at the Deployment History tab, which shows the status Pending. When a deployment is in pending status, you will not be able to cancel or undo it.
This process enables you to correct any errors before deployment. In addition, if you attempt a deployment that would duplicate either;
- An already scheduled deployment or;
- An attribute of an already scheduled deployment, such as;
- The same rule package
- For the same snapshot
- For the same destination server/cluster
an appropriate message is displayed. You can then either change the attributes of your deployment, or go to Deployment History and change/delete the scheduled deployment.
To use the deployment screen, you must have deploy permissions set up in Genesys Administrator.
To deploy a rule package:
- Select the Tenant to which the rule package belongs from the drop-down list.
- In the Explorer Tree, select the name of the rule package.
- Under the rule package, select Deploy Rules. (The number of rules as yet not included in a snapshot appears in parentheses.) The Details Panel contains two tabs:
- The Outstanding Deployments tab allows you to select from a list of snapshots of the package including the LATEST version of the package (if configured by an administrator), create a new snapshot, export a snapshot (as an XML file downloadable to the user’s local file system), delete a snapshot, deploy the rule package, schedule a deployment to occur at a future time, and show the source of the package. (Show Package Source displays the actual contents of the package snapshot you are deploying. The fact model, calendar definitions, and rule definitions will be coded into the rule language and displayed.)
Even if Run as Background Task is checked, the package will first be built and validated to ensure there are no errors. Once the validation is successful, the snapshot will be queued to a background task.
You cannot delete the LATEST snapshot, and you cannot delete a snapshot for which there is a scheduled deployment.- The Deployment History tab shows details about when the package snapshot was deployed in the past, and by whom. Failed deployments also appear in the list. In addition, the Deployment History displays scheduled deployments, and allows you to cancel or change the schedule of upcoming deployments.
To deploy the package immediately:
- Select the package snapshot, or the LATEST version (if available).
- Click Deploy Now in the Outstanding Deployments tab.
- Select the Location to which the package snapshot will be deployed. Locations can include standard application clusters configured in Genesys Administrator, special smart clusters based on the Genesys_Rules_Engine_Application_Cluster application template, or the GWEB backend server for Genesys Web Engagement.
- Enter some comments about the deployment (these will appear in the Deployment History).
- Click Deploy.
A message will be displayed indicating whether the deployment was successful, failed, or partial. A partial deployment means that not all nodes in the cluster successfully received the deployed rules package.
To deploy the package later:
- Click Schedule Deployment in the Outstanding Deployments tab.
- Select the Location (the name of the Rules Engine application or application cluster, or the GWEB backend server for Genesys Web Engagement) to which the package snapshot will be deployed.
- Enter the date and time you would like the package snapshot to be deployed.
- Enter some comments about the deployment (these will appear in the Deployment History).
- Click Schedule.
A message will be displayed indicating whether the deployment was successfully scheduled.
If you wish to reschedule a previously scheduled deployment, or wish to cancel a scheduled deployment, you may do so from the Deployment History tab.
To refresh the display of a deployment history, click the Refresh button, or click in the relevant node in the Explorer Tree.
To display details of a deployment to a cluster:
If you are deploying to a cluster, you can now display a detailed report of the deployment, whether it was successful, failed or partial. This gives useful information on how a deployment has progressed: you can click the Deployment Status result to see, for example, whether a server connection was temporarily down at a critical moment, or whether a server timeout setting might need to be changed. Where a deployment shows as partial, you can click the Partial link in the Deployment Status panel to display details of individual GREs, whether and when they have auto-synchronized subsequently.
If partial deployment is NOT configured
When deploying to a cluster, GRAT uses a two-phase commit protocol to ensure that all GRE nodes running in the cluster are running the same version of the deployed rule package. If any of the nodes in the cluster fails during Phase 1, the Phase 2 is not committed.
- Phase 1 - (Deploy) All GREs in the cluster are notified about the new rule package. Each GRE downloads the new rule package and compiles it.
- Phase 2 - (Commit) Once all GREs have successfully completed Phase 1, GRAT notifies each GRE to activate and commit the new rule package.
The Deployment Status shows the detail of each node in the cluster and whether or not any errors occurred.
If partial deployment IS configured
GRAT attempts to deploy the rules package to all GRE nodes running in the cluster. If any nodes are down, or disconnected, or the deployment fails for any reason, the rules package is still deployed to the remaining nodes in the cluster. The GREs in the cluster can be configured to auto-synchronize when disconnected nodes are reconnected, or when new nodes are added to the cluster.
GRAT still uses a two-phase commit protocol. The only difference is that in a partial deployment case, we continue to Phase 2 for GREs which successfully complete Phase 1. Overall Status is set to Partial when 1 or more (but not all) of the GREs in the cluster fails the deployment.
- Phase 1 - (Deploy) All GREs in the cluster are notified about the new rule package. If any GRE fails to respond successfully, the overall deployment status is set to Partial.
- Phase 2 - (Commit) For GREs that have successfully completed Phase 1, GRAT notifies each GRE to activate and commit the new rule package.
To show the deployment report:
- Click the Failed/Successful/Partial link in the Status column.
- The details of each deploy action to each server in the cluster are displayed, including:
- The GRE Server Name
- The server status
- The success or error message generated by the server
- The Phase 1 and Phase 2 deployment times in seconds
- Whether and when the GRE was auto-synchronized and from which other member of the cluster the rules package data was received (if the auto-synchronization feature is configured).
Undeploying a rules package (8.5.303+)
For users with the correct privileges, an Undeploy button now displays on the Outstanding Deployments tab. This button lets you undeploy a rules package from a single GRE or cluster (but not from a GWE back-end rules engine or cluster).
To undeploy a rules package:
- Click the Undeploy button. This displays the Undeploy dialog.
- Select the single GRE or cluster from which to undeploy the rules package and click Undeploy.
- If partial undeployment is enabled, the details in the Deployment History tab might show where a partial undeployment has taken place. Click the Failed/Successful/Partial link in the Status column to display the Undeployment report. Partial status indicates that one or more GRE nodes were offline when the rule package was undeployed. When those nodes come back online, and if auto-synchronization is enabled, they will automatically synchronize with the other GRE nodes and undeploy the package.
If partial undeployment IS enabled:
GRAT attempts to undeploy the rules package from all GRE nodes running in the cluster. If any nodes are down, or disconnected, or the undeployment fails for any reason, the rules package is still undeployed from the remaining nodes in the cluster. The GREs in the cluster can be configured to auto-synchronize when disconnected nodes are reconnected, or when new nodes are added to the cluster.
Overall Status is set to Partial when 1 or more (but not all) of the GREs in the cluster fails the undeployment.
If partial undeployment is NOT enabled
When undeploying from a cluster, GRAT only undeploys the rules package if all the members of the cluster are active. If any node is inactive the undeployment fails and the rules package remains deployed at all nodes in the cluster.
Summary
In order for rules to be invoked by Genesys applications, you must deploy the rule package to one or more Genesys Rules Engines (or for Genesys Web Engagement, to the GWEB backend server). The deployment process (whether you choose to deploy immediately or to schedule the deployment for later) attempts to compile the rule package and informs you of the result via the Deployment Pending pop-up message. You can check on the status of your deployment by looking at the Deployment History tab, which shows the status Pending. When a deployment is in pending status, you will not be able to cancel or undo it.
This process enables you to correct any errors before deployment. In addition, if you attempt a deployment that would duplicate either;
- An already scheduled deployment or;
- An attribute of an already scheduled deployment, such as;
- The same rule package
- For the same snapshot
- For the same destination server/cluster
an appropriate message is displayed. You can then either change the attributes of your deployment, or go to Deployment History and change/delete the scheduled deployment.
To use the deployment screen, you must have deploy permissions set up in Genesys Administrator.
To deploy a rule package:
- Select the Tenant to which the rule package belongs from the drop-down list.
- In the Explorer Tree, select the name of the rule package.
- Under the rule package, select Deploy Rules. (The number of rules as yet not included in a snapshot appears in parentheses.) The Details Panel contains two tabs:
- The Outstanding Deployments tab allows you to select from a list of snapshots of the package including the LATEST version of the package (if configured by an administrator), create a new snapshot, export a snapshot (as an XML file downloadable to the user’s local file system), delete a snapshot, deploy the rule package, schedule a deployment to occur at a future time, and show the source of the package. (Show Package Source displays the actual contents of the package snapshot you are deploying. The fact model, calendar definitions, and rule definitions will be coded into the rule language and displayed.)
Even if Run as Background Task is checked, the package will first be built and validated to ensure there are no errors. Once the validation is successful, the snapshot will be queued to a background task.
You cannot delete the LATEST snapshot, and you cannot delete a snapshot for which there is a scheduled deployment.- The Deployment History tab shows details about when the package snapshot was deployed in the past, and by whom. Failed deployments also appear in the list. In addition, the Deployment History displays scheduled deployments, and allows you to cancel or change the schedule of upcoming deployments.
To deploy the package immediately:
- Select the package snapshot, or the LATEST version (if available).
- Click Deploy Now in the Outstanding Deployments tab.
- Select the Location to which the package snapshot will be deployed. Locations can include standard application clusters configured in Genesys Administrator, special smart clusters based on the Genesys_Rules_Engine_Application_Cluster application template, or the GWEB backend server for Genesys Web Engagement.
- Enter some comments about the deployment (these will appear in the Deployment History).
- Click Deploy.
A message will be displayed indicating whether the deployment was successful, failed, or partial. A partial deployment means that not all nodes in the cluster successfully received the deployed rules package.
To deploy the package later:
- Click Schedule Deployment in the Outstanding Deployments tab.
- Select the Location (the name of the Rules Engine application or application cluster, or the GWEB backend server for Genesys Web Engagement) to which the package snapshot will be deployed.
- Enter the date and time you would like the package snapshot to be deployed.
- Enter some comments about the deployment (these will appear in the Deployment History).
- Click Schedule.
A message will be displayed indicating whether the deployment was successfully scheduled.
If you wish to reschedule a previously scheduled deployment, or wish to cancel a scheduled deployment, you may do so from the Deployment History tab.
To refresh the display of a deployment history, click the Refresh button, or click in the relevant node in the Explorer Tree.
To display details of a deployment to a cluster:
If you are deploying to a cluster, you can now display a detailed report of the deployment, whether it was successful, failed or partial. This gives useful information on how a deployment has progressed: you can click the Deployment Status result to see, for example, whether a server connection was temporarily down at a critical moment, or whether a server timeout setting might need to be changed. Where a deployment shows as partial, you can click the Partial link in the Deployment Status panel to display details of individual GREs, whether and when they have auto-synchronized subsequently.
If partial deployment is NOT configured
When deploying to a cluster, GRAT uses a two-phase commit protocol to ensure that all GRE nodes running in the cluster are running the same version of the deployed rule package. If any of the nodes in the cluster fails during Phase 1, the Phase 2 is not committed.
- Phase 1 - (Deploy) All GREs in the cluster are notified about the new rule package. Each GRE downloads the new rule package and compiles it.
- Phase 2 - (Commit) Once all GREs have successfully completed Phase 1, GRAT notifies each GRE to activate and commit the new rule package.
The Deployment Status shows the detail of each node in the cluster and whether or not any errors occurred.
If partial deployment IS configured
GRAT attempts to deploy the rules package to all GRE nodes running in the cluster. If any nodes are down, or disconnected, or the deployment fails for any reason, the rules package is still deployed to the remaining nodes in the cluster. The GREs in the cluster can be configured to auto-synchronize when disconnected nodes are reconnected, or when new nodes are added to the cluster.
GRAT still uses a two-phase commit protocol. The only difference is that in a partial deployment case, we continue to Phase 2 for GREs which successfully complete Phase 1. Overall Status is set to Partial when 1 or more (but not all) of the GREs in the cluster fails the deployment.
- Phase 1 - (Deploy) All GREs in the cluster are notified about the new rule package. If any GRE fails to respond successfully, the overall deployment status is set to Partial.
- Phase 2 - (Commit) For GREs that have successfully completed Phase 1, GRAT notifies each GRE to activate and commit the new rule package.
To show the deployment report:
- Click the Failed/Successful/Partial link in the Status column.
- The details of each deploy action to each server in the cluster are displayed, including:
- The GRE Server Name
- The server status
- The success or error message generated by the server
- The Phase 1 and Phase 2 deployment times in seconds
- Whether and when the GRE was auto-synchronized and from which other member of the cluster the rules package data was received (if the auto-synchronization feature is configured).
Undeploying a rules package (8.5.303+)
For users with the correct privileges, an Undeploy button now displays on the Outstanding Deployments tab. This button lets you undeploy a rules package from a single GRE or cluster (but not from a GWE back-end rules engine or cluster).
To undeploy a rules package:
- Click the Undeploy button. This displays the Undeploy dialog.
- Select the single GRE or cluster from which to undeploy the rules package and click Undeploy.
- If partial undeployment is enabled, the details in the Deployment History tab might show where a partial undeployment has taken place. Click the Failed/Successful/Partial link in the Status column to display the Undeployment report. Partial status indicates that one or more GRE nodes were offline when the rule package was undeployed. When those nodes come back online, and if auto-synchronization is enabled, they will automatically synchronize with the other GRE nodes and undeploy the package.
If partial undeployment IS enabled:
GRAT attempts to undeploy the rules package from all GRE nodes running in the cluster. If any nodes are down, or disconnected, or the undeployment fails for any reason, the rules package is still undeployed from the remaining nodes in the cluster. The GREs in the cluster can be configured to auto-synchronize when disconnected nodes are reconnected, or when new nodes are added to the cluster.
Overall Status is set to Partial when 1 or more (but not all) of the GREs in the cluster fails the undeployment.
If partial undeployment is NOT enabled
When undeploying from a cluster, GRAT only undeploys the rules package if all the members of the cluster are active. If any node is inactive the undeployment fails and the rules package remains deployed at all nodes in the cluster.
Rule Deployment
Once you have created all the necessary rules in a rule package, you can deploy the rule package (+DETAIL) to either a single GRE or to a cluster of GREs. Once the package is deployed, it can be invoked by a client.
Rule package deployment is done using GRAT, and is independent of the individual solutions deployment features. So, you can deploy a new version of a rule package for a Genesys solution without having to redeploy the entire solution.
When a rule is created or edited and it has not been deployed, there is a checkmark in the Pending Deployment column of the rule. In addition, when a rule package requires deployment or redeployment, there will be a visual indication next to the Deploy Rules node in the GRAT navigation tree, under the rule package itself.
The deployment process (whether you choose to deploy immediately or to schedule the deployment for later) attempts to compile the rule package and informs you of the result via the Deployment Pending pop-up message. You can check on the status of your deployment by looking at the Deployment History tab, which will now show a new status of Pending. When deployment is in pending status, you will not be able to cancel or undo it.
This process enables you to correct any errors before deployment. In addition, if you attempt a deployment that would duplicate either;
- An already scheduled deployment or;
- An attribute of an already scheduled deployment, such as;
- The same rule package
- For the same snapshot
- For the same destination server/cluster
an appropriate message is displayed. You can then either change the attributes of your deployment, or go to Deployment History and change/delete the scheduled deployment.
To use the deployment screen, you must have deploy permissions set up in Genesys Administrator.
|+DETAIL Deploying Rules Packages|
From Release 8.5.2
From release 8.5.2, partial deployments to GRE clusters are allowed, Previously, any deployment to a cluster in which one node failed to update would result in the deployment being rolled back. From 8.5.2, partial deployments are allowed, and the cluster nodes can be configured to auto-synchronize so that temporary disconnects or additions to the cluster can be handled without interruption to deployments. + DETAILS
From Release 8.5.3
From release 8.5.3, GRATs can also be configured in clusters to provide greater resilience. Deployments can be amended and rescheduled by other GRAT users in the cluster, which was not possible previously. + DETAILS
From Release 8.5.303
From release 8.5.303 you can also undeploy rules packages from single GREs or clusters. + DETAILS