Revision as of 14:55, July 14, 2015 by Alison.obrien (talk | contribs)
Jump to: navigation, search

Configuring Media Lifecycle Management

When it is time to purge old recording files, Web Services sends a purge request to the SpeechMiner database indicating which records to delete. Both Web Services and SpeechMiner need additional configuration to allow the records to purge successfully.

Web Services

To enable Genesys Interaction Recording to purge recording files, configure the Web Services node as follows:

In the backgroundScheduledMediaOperationsSettings section of the server-settings.yml file,

  • Set enableBackgroundScheduledMediaOperations to true
  • Set defaultBackupExportURI to a backup folder—for example, file:///tmp/archLocDefault is the default backup folder.

For more information about these options, see Configuring Web Services.

SpeechMiner

To enable Web Services to contact Interaction Receiver and purge the requested recordings, use a text editor to add the following to the location based setting group in the json.txt file:

{
    "name":"interaction-receiver",
    "location": "/US/CA",
    "value": {
        "uri-prefix": "http://interactionreceiver:8080/interactionreceiver",
        "userName": "interaction receiver user name",
        "password": "interaction receiver password"
    }
}
Important
The Interaction Receiver user name and password must be the tenant archiving user and password which are set when configuring Recording Crypto Server.

Execute the following command:

curl -u <user:password> -X POST -d @json.txt --header
"Content-Type: application/json" http://<Web Services-cluster-address>/api/v2/settings/speechminer

For more information on the properties of this settings group, see Web Services Settings Groups.

For more information about the location based setting group for encryption, see Encrypting and Provisioning Certificates.

Creating Rules and Schedules

Use Genesys Administrator Extension to create rules and schedules. For step-by-step instructions, see Recording Scheduler Rules.

Consider the following when creating backup and purge tasks:

  • Do not schedule backup tasks to run concurrently on the same Web Services node if these tasks back up overlapping records.
  • Do not schedule backup and purge tasks to run concurrently if they act on overlapping records.
  • Ensure that all the Web Services nodes have accurate clocks.
  • Genesys Administrator Extension's time is based on UTC.
Important
  • Do not schedule a purge task to run independently in its own rule unless you are willing to lose the associated data. Even if a backup has been scheduled, it is not guaranteed to complete successfully before the purge task is executed.
  • MLM does not support a per-tenant backup/purge policy. If you have a multi-tenancy deployment, all recordings will be processed together.
Warning

When you are scheduling rules containing purge tasks, adhere to the following guidelines to avoid an unexpected failure of Purge or Backup tasks:

  • Run only one Purge task in a rule.
  • Run the Purge task last in a rule.
  • Do not run two rules with overlapping minAge/maxAge time intervals too close together (less than 5 seconds) if the first rule contains a Purge task. Note that the interval is the time between the rules that are running (that is, the completion of one rule and the start of the next) and not between the scheduled start time of rules.

You can look at the recording.log file to determine when a rule has finished. Look for the following message:

... [] [] []  Scheduled rule [<rule name>] at location [<node path>] completed
The <rule name> and <node path> depend on the customer configuration. Note that the amount of time to run a rule depends on many factors, including call volume. The interval should be much greater than that suggested above to make allowances for day to day variations.

Configuring For Multiple Regions

The following sections describe how to configure MLM for multiple regions.

Need For An MLM Node In Each Region Requiring Backup and/or Purge

By design, an MLM node will only backup and/or purge call and screen recordings for which the metadata region property exactly matches the crRegion (call recording region) property found in the node's server-settings.yaml configuration file. This design prevents these nodes from "pulling" media between data centers.

For example, if there are two data centers defining regions "east" and "west", and the client Web Services nodes with nodePaths (in the server-settings.yaml file) /US/EAST/10.2.0.1 through /US/EAST/10.2.0.10 are in region "east", and client GWS nodes with nodePaths /US/WEST/10.2.1.1 through /US/WEST/10.2.1.10 are in region "west", and there is a requirement for deleting all call recordings after 90 days, then there will need to be at least one MLM node in each region (possibly with nodePaths /US/EAST/10.2.0.20 and /US/WEST/10.2.1.20) each with a 90-day purge rule.

Configuring SpeechMiner Purge API

If a deployment supports call recording and SpeechMiner, a deployment will need to have the SpeechMiner Purge API configured (see SpeechMiner for more information).

For a multi-region deployment that has only one SpeechMiner, the SpeechMiner Purge API should be configured with a location property value that is the nearest common ancestor of the nodePaths of all the MLM nodes. For instance, using the example above, the nearest common ancestor of nodePaths /US/EAST/10.2.0.20 and /US/WEST/10.2.1.20 is /US.

For a multi-region deployment that has one SpeechMiner per region, the SpeechMiner Purge API should be configured for the SpeechMiner of each region, using a location property value for each that is the nearest common ancestor of all the nodePaths of the region's Web Services nodes. For instance, using the example above, the nearest common ancestor of nodePaths /US/EAST/10.2.0.1 through /US/EAST/10.2.0.10 and /US/EAST/10.2.0.20 is /US/EAST, and the nearest common ancestor of nodePaths /US/WEST/10.2.1.1 through /US/WEST/10.2.1.10 and /US/WEST/10.2.1.20 is /US/WEST.

Upgrading the GIR Components

When upgrading from version 8.5.205.01 or earlier to version 8.5.206.01 or later, the GIR components can be upgraded in any order (Web Services, Recording Plug-in, Recording Processor Script, etc), but callType should not be specified in MLM tasks within the upgraded Recording plug-in until all Web Services nodes have been upgraded.

Rolling Back the GIR Components

When rolling back the components from version 8.5.206.01 or later to version 8.5.205.01 or earlier, the GIR components can be rolled back in any order (Web Services, Recording Plug-in, Recording Processor Script, etc), as long as no MLM tasks specify callType in the filter. If a callType is specified as a filter of a task, the task must be removed before rolling back Web Services to a previous version. Disabling the task is not sufficient.

Comments or questions about this documentation? Contact us for support!