Jump to: navigation, search

Audit Trail

The Audit Trail tab allows you to view the history of the individual rules, such as when they were updated or deployed, and by whom.

The Audit Trail tab lists the rules that exist for the selected rule package, or for the selected business context (node), depending on where you access the Audit Trail. The Audit Trail tab shows the history of the currently selected rule.

You can select the Rule ID/Name drop-down to select another rule. For each rule you can view the history of the rule, including different versions that have been saved, and the configured actions, conditions, parameters and comments.

If a particular revision of a rule was saved as part of a snapshot, the snapshot name appears in the Last Snapshot Name column. This enables you to determine the content of the rule when the snapshot was taken. You can filter the list of rule versions by Last Snapshot Name, Action (Created, Modified, and so on), and by the user name of the person who made the changes (Taken By). You can sort the list by clicking a column name, displaying the results in ascending or descending order by the selected column.

You can export the history of the rule into a file (spreadsheet format). Select the rule from the list, and click Export Rule History. You can choose to open the file that is created, or save it.

You can revert back to a previous version of a specific rule: select the version to which you would like to revert, and click Revert. The revert operation will create a new version of the rule containing the same contents as the older version that you selected. The original versions and audit history will be preserved. Revert may also be used to restore a previously deleted rule.  To do this, select the Rule ID/Name from the drop down and then revert the deleted version.

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).
    2. 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 application clusters configured in Genesys Administrator, 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.

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 succeeded or failed. This gives useful information on how a deployment has progressed: you can 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.

Important
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.

To show the report:

  1. Click on the Failed/Successful 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
Important
The time zone for scheduled deployments is always the time zone of the server on which the Genesys Rules Authoring Tool is installed.

Running Test Scenarios

Important
The Testing Scenarios feature is not available for use with the initial release of the Conversation Manager standard template and rules.

To run a test scenario (for which execute permission is needed), select a test scenario row and click Run Test Scenario.

To run all the test scenarios, click Run All.

When the tests are complete, a details view and a summary view are both displayed. The Result column will display either a pass Pass.jpg or a fail Fail.jpg. Click on either the pass or the fail icon to bring up a detailed view of the test run.

Follow these steps to create a linear rule:

  1. Navigate to the rule package to which the new rule will belong in the Explorer Tree (verify that you have selected the correct Tenant from the Tenant drop-down list). Navigate to the correct node of the business structure under the rule package, which will define the node at which your linear rule will be created. If you create the linear rule at the rule package level, it will be a global rule. Select the node in the Explorer Tree and click on the Rules tab.
  2. Click New Linear Rule.
  3. In the Rule Summary, the ID field is populated automatically. It cannot be edited.
  4. Enter a Name for the rule (for example, Gold).
  5. Enter a brief Description for the rule (for example, If the customer is a Gold member, then increase the priority).
  6. Select the Phase at which this rule will be applied (classification, prioritization, or archiving for iWD. Refer to the Genesys Rules System Deployment Guide for more information about phases).
  7. Select the Business Calendar to use with this rule (optional).
  8. The Pending Snapshot field is displayed with a tick symbol indicating that the contents of this rule have not yet been included in a package snapshot. See Deployment  for details of how to work with snapshots.
  9. Enter a Start Date and an End Date for the rule (optional). If the End Date is earlier than the current date, the rule is marked with a flag (Grs auth-tool flag.gif ) to indicate that the rule is out of date.
  10. In the lower panel, fill in the When and Then rows.
    1. To add a Condition (When), click Add Condition and select from the list (for example, a condition for this scenario might be When the customer is a Gold member). The rule condition includes the name of the rule template from which the condition is derived.
    2. To add an Action (Then), click Add Action and select from the list (for example, an action for this scenario might be Increase the priority by 100). The rule action includes the name of the rule template from which the action is derived.
    3. Insert values for the parameters into the table under the Condition and Action columns. Depending on how the parameters were configured by the rule template developer in GRDT, there may be constraints on the values that can be entered.
  11. Click Validate to validate the syntax of the linear rule. The Validate option appears in the drop-down located in the lower left side of panel.
  12. Click Save to save your changes.
    Important
    When you make any modifications to the body of a rule, you "lock" the rule, which prevents others from being able to make changes to the same rule at the same time. The unsaved icon will appear on the rule summary to alert you that you need to save your changes. For any other user, the locked icon appears on the rule summary and the Save and Cancel buttons are disabled. In addition, other users are unable to make changes to the rule because it is marked "read only".

When editing rules, be careful not to clear your browsing history or cookie data, as this might cause the rule to be stuck in a locked state. Unsaved changes could be lost.

Creating Rules Packages

Follow these steps to create a new rule package:

  1. Select the Tenant to which this rule package will belong from the drop-down list.
    Important
    Package names must be unique across tenants.  Package names should follow a naming convention such as including the tenant name, or company name, in their package names to avoid conflict.
  2. In the Explorer Tree, select New Rules Package under the appropriate Solution. You must have appropriate permissions for this option to display.
  3. In the Details Panel, enter a name property for the new rule package.
    Important
    There are two name properties for a rule package: Package Name and Business Name.

    Package Name must conform to Java package naming conventions. Generally speaking, the package name should be in all lower case, can contain digits but must not start with a digit, and "." should be used as a separator, not spaces. For example, my.rules and myrules1 are both valid names, but My Rules and 1my.rules are not valid package names. Each organization should establish its own naming conventions to avoid name collision. Additionally, Java keywords must be avoided in package names. For example, my.package or new.rules are not valid package names. A list of Java keywords can be found here.

    Business Name allows you to provide a user-friendly name for the rule package, as it appears in the GRAT Explorer Tree. For example, Acme Rules is not a valid rule package name, but you could use acme as the Package Name and ACME Rules as the Business Name.
  4. Select which type of rule package you are creating. The drop-down list shows which types are already in the repository for the selected tenant. As you change the type, the list of templates for that type will be displayed.
  5. Enter a description for the rule package. The available rule templates (that were created for the Tenant and match the type selected in Step 4) will appear in the table. Templates prefixed with "(*)" are templates that were created in the Environment Tenant and can be used by all Tenants. Rule developers create rule templates and publish them to the rules repository by using the GRDT.
    Important
    The access permissions configured in Configuration Server can also affect which templates are displayed.
    Important
    GRAT users can select between multiple versions of templates, which are displayed on the enhanced Template Selection dialog along with version comments created by the template developer to help identify differences between the versions.  The number of versions of a template that are displayed is configured in Genesys Administrator.

    Select the template(s) you want to include and click Save.

  6. The new rule package will appear in the Explorer Tree. Expand the new rule package, and the following options (subject to the permissions set for your user ID) will appear under the rule package folder:
    • Business Calendars
    • Test Scenarios
    • Deploy Rules
    • Search
    You will also see the business structure nodes to which you have access permission.
  7. You can now create rules for your rule package.

You must publish the template in order for it to be available to business users to create rules. Publishing is also the preferred mechanism for sharing the templates so other template developers can edit or modify the templates, if necessary. The visibility of the template is determined by access permissions. These permissions are defined in Configuration Manager or Genesys Administrator by an Administrator. Each template has a corresponding Script object in Genesys Configuration Server for which access control can be configured.

Since release 8.1.3, rule authors can select prior versions of published rule templates. You can optionally publish a version comment for a specific template in order to inform rule authors about the specific differences between individual versions of a template.

To publish the template to the repository:

  1. Select the template in the Project Explorer and right-click.
  2. Add a version comment.
  3. Select Publish.
  4. Click Next to enter a publish comment.
  5. Click Finish to publish the template.

Rule Templates are created as Projects in GRDT. The New Project Wizard is used to create new templates.

New Project Wizard

The New Project Wizard guides you through the steps to create a new Rule Template Project. This wizard can be accessed in the following ways:

  • Select File > New > Rule Template Project from the menu bar.
  • Right-click within the Project Explorer and select New > Project from the context-sensitive menu.

The wizard leads you through the following steps:

  1. The first screen prompts you to select which wizard you need that is, which type of project you wish to create. If it is not already selected, navigate to Genesys Rules System > Rule Template Project and click Next.
  2. Enter a name for the new template project. Template names must be unique within a tenant. Either use the default location, or clear the check-box and select a new location. Click Next.
  3. Verify the type of template you are creating in the drop-down list. The default template type is Stateless. To create an iWD template, select iWD. To create a template  for Genesys Web Engagement, select type CEP.
    4. Important
    CEP support requires the presence of GWE to function.
    Important
    The iCFD template type has been removed. The iWD template type is the only reserved template type. Any other new template types required can be created by using the Configure Types link (see step 4).
  4. Click the Configure Types link to create new template types or maintain existing ones.
  5. Use the Enable event support check box to indicate whether the template will support events. In templates that support events, the Fact Model editor can be used to create both facts and events.
  6. Select the appropriate Tenant, and enter a description of the template.
  7. Click Finish. The new template project will now appear in the Project Explorer.

Editing and Configuring Rule Templates

Once it is created, the rule template appears in the Project Explorer. Expanding the template displays a list of components that can be configured. Double-click the component type in the Project Explorer to open the appropriate Editor and begin configuring components.

Renaming Rule Templates

Renaming rule templates does not change the name within the repository. When you publish the renamed rule template, it will be added to the repository as a new template, and the template with the old name will still exist.

You can rename your template by right-clicking the template in the Project Explorer and selecting Rename from the context-sensitive menu, by selecting the template and navigating to File > Rename, or by selecting the F2 key on your keyboard. Many features can be accessed in similar ways.

Important
In release 8.1.2, duplicate template names are not allowed within tenants, but are allowed in different tenants. Creating such a duplicate name will rename the project, but the name as published in GRAT is set via Project/Properties/Template Properties.

Copying Rule Templates

Existing rule templates can be copied to be used as a basis for a new template. Right-click the template in the Project Explorer, and select Copy. As with renaming, there are multiple ways to access the Copy functionality, such as the  Ctrl + C keyboard shortcut, Edit > Copy, and so on.

Deleting Rule Templates

Rule templates can be deleted using the GRS Server Explorer, provided that:

  • The user has rule template delete permissions, and;
  • The rule is not used in any rule package.

GRS Lifecycle Overview

GRS Overview3.png

  1. GRDT—Rule templates are DEVELOPed and the templates are PUBLISHed to the rules repository.
  2. GRAT—Authors then create a rule package that incorporates one or more rule templates. GRAT is also where users:
    1. Create new rules packages that incorporate rule templates +DETAIL
    2. AUTHOR rules inside the rule package based on the rule templates +DETAIL
    3. VALIDATE the rules
    4. Run TEST SCENARIOS for the rules (from release 8.1.2 onwards) +DETAIL
    5. DEPLOY their rule package to the Genesys Rules Engine +DETAIL
    6. AUDIT the rules package +DETAIL
    7. GRE—Client applications (for example, the iWD business process (IWDBP)) then make requests to the Genesys Rules Engine to VALIDATE and EVALUATE the rules in the rule package at various decision points in a task's lifecycle.

    GRS Overview4.png

This page was last edited on July 14, 2015, at 13:46.
Comments or questions about this documentation? Contact us for support!