Deploying Rules Packages

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 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:

1. Select the Tenant to which the rule package belongs from the drop-down list.
2. In the Explorer Tree, select the name of the rule package.
3. 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.)

Important

When you create a snapshot, you can choose to check the Run as Background Task option. For very large rule packages, it can take a long time to create a snapshot. When this option is checked, this operation will be completed in the background. This allows you to do other things or log off. When the snapshot is complete, it appears under Package Snapshots.

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:

1. Select the package snapshot, or the LATEST version (if available).
Important
The LATEST version is available only if configured in Genesys Administrator. Your organization may choose not to make it available because its contents may vary over time, for example between scheduled deployments.
2. Click Deploy Now in the Outstanding Deployments tab.
3. 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.
4. Enter some comments about the deployment (these will appear in the Deployment History).
5. 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:

1. Click Schedule Deployment in the Outstanding Deployments tab.
2. 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.
3. Enter the date and time you would like the package snapshot to be deployed.
4. Enter some comments about the deployment (these will appear in the Deployment History).
5. 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 on 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 on 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:

1. Click on the Failed/Successful/Partial link in the Status column.
2. 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).

Important

The time zone for scheduled deployments is always the time zone of the server on which the Genesys Rules Authoring Tool is installed.