VFC to WFE Metadata Integrator

AVAILABLE IN 9.7.7 AND ABOVE

Overview

The purpose of the VFC to WFE Metadata Integrator tool is to import call metadata, supported by switch platform and user data, from the VFC platform to the Verint V15.2 Workforce Engagement (WFE) suite. Once imported, the data is available for use by certain applications within the WFE suite. The Integrator continuously verifies the data in both VFC and WFE and carries out a one-way synchronization periodically.

This integration offers the following features:

Synchronization of call record metadata and their related audio quality, speech transcription, and screen recording metadata from VFC to WFE.
Synchronization of switch platforms, and extensions from VFC to WFE.
Synchronization of groups and users from VFC to WFE.

The data synchronized to Workforce Engagement is then available for use in certain WFE applications:

You can configure Capture Verification Collectors to collect Call Detail Records (CDRs) from the switch platforms and verify your call recording, audio quality, audio transcription, archiving, screen recording, and sensitive data masking compliance with Automated Verification.
You can create Automated Verification reports to summarize your recording compliance results.

Design your integration based on your VFC and WFE deployments using this document before installing and configuring the Integrator.

Supported switch platforms

The Integrator supports the synchronization of recording data for the following switch platforms:

Avaya DMCC/MR
Cisco Network Based
IPC Unigy
IP Trade
Zoom Meeting
Zoom Phone

Minimum software version

VFC Capture 9.7.7 or higher
Workforce Engagement V15.2

Concepts and functionality

Architecture

The Integrator connects to the VFC Media Repository through API calls to gather system information and sets up an SQL connection to the VFC database to read in the data to synchronize. The Integrator communicates with WFE services and sends data to the WFE database using API calls.

The Integrator supports the following deployments:

System	On premise	Single-tenant Cloud	Multi-tenant Cloud
VFC	Yes	Yes	Yes *
WFE	Yes	Yes	Yes

* Multi-tenant cloud VFC deployments are supported if each tenant has its own Integrator configured.

The Integrator must be installed on a VFC server. Only one Integrator can be installed on a single server.

When the Integrator first runs, it creates its editable configuration file, appsettings.<environmentName>.json. All connection details are specified in this file, along with parameters to monitor and optimize the synchronization process. The default value of environmentName is Production, otherwise, if configured, the value matches the DOTNET_ENVIRONMENT environment variable configured on the server. Any references to appsettings.Production apply to this file.

There can only be one Integrator running per VFC environment. There can be multiple idle Integrators configured for the same environment, which take over if the active Integrator fails. An Integrator and a VFC environment are associated by configuring the Environment ID in the appsettings.Production configuration file of the Integrator. If multiple VFC environments use the same VFC database, the active Integrator of each environment can connect to that database at the same time. See Resilience for more information.

An Integrator synchronizes VFC data to a single WFE tenant. The connection to the WFE installation is specified by configuring the URL of the WFE Application Server on which the WFO_ProductionDomain_ProductionServer runs. Multiple Integrators can synchronize data to a single WFE tenant, but there are parameters in the appsettings.Production file that must be unique to each connected Integrator. Refer to the Configuration Guide for more details. The tenant to which an Integrator connects is specified by creating an API token for the tenant in WFE and adding that token to the Integrator configuration.

User groups

The Integrator synchronizes all user data from the VFC database to WFE. The synchronization of all VFC users is supported, including users created by an Active Directory synchronization.

Synchronized VFC users do not have roles and privileges in WFE.

While organizations do not exist in VFC, WFE relies on organizations for enforcing user access scoping and for logically associating users and data sources. As the first step of the deployment process, the Integrator requires the creation of a parent organization in WFE. This organization can be on any level of an existing WFE organizational hierarchy. The name of the parent organization must be added to the Integrator configuration. The user groups and data sources managed by the integration are associated with the organization upon creation.

The parent organization must not be the Root organization that is created during the WFE deployment process.

You must also manually create a parent WFE group that holds all groups of VFC synchronized employees, and the name must be added to the Integrator configuration.

The parent group must not have employees assigned to it at any point in time and it must not be the Root group that is created during the WFE installation process.

Under the parent group, a default group holds all individual VFC synchronized employees, regardless of what VFC groups those employees belong to. On the same hierarchical level, under the parent group, the WFE groups matching the VFC groups get automatically created by the integrator.

The default group synchronization method creates an identical group hierarchy in WFE as the groups exist in VFC. These groups retain their names configured in VFC, but the Integrator removes special characters, and if a group name at any hierarchy level is longer than 50 characters, the Integrator does not process the group and logs an error.

If a group name is longer than 50 characters or the group needs to be synchronized to WFE with a different name, the Integrator can be configured to read in a CSV file listing the original VFC group names and the corresponding shortened or amended group names, as intended to be listed in WFE.

You must specify the full file path, file name, and extension of the CSV file in the Integrator configuration. If a file path is specified, but the file cannot be found, the process fails, and the Integrator reverts back to the default group synchronization process.

The contents of the file must be entered in the following format:

The first column must contain the group names exactly as specified in VFC.
Every unique group must be in a separate row.
The second column must contain the amended group names as they should be synchronized to WFE.
The rows and columns must not have header values.

You can list groups from any level of the group hierarchy. Duplicate group names are ignored. Any groups not listed in the CSV file are synchronized to WFE using the default synchronization process.

Example:

The top level parent group, and some sub-groups on the third level of the hierarchy have new names configured using the CSV file. Column A contains the original names in VFC, and column B lists the names intended to be used in WFE.

All VFC groups are synchronized to WFE, not just the groups listed in the CSV file. The group hierarchy remains, and the groups with new names configured in the CSV file are synchronized with their new names.

As all groups in WFE must have a unique name, VFC groups with the same name under different parents cannot be synchronized without a change to the name. To avoid skipping groups with identical names, you can choose a level in the group hierarchy to act as a suffix to all of sub-groups by setting the UniqueIdentifier parameter in the Integrator appsettings.Production file. The name of the groups on the specified level in the hierarchy get concatenated to the names of all their sub-groups with a dash.

Example:

Sales and Support exist as sub-groups in both the AMER and EMEA groups in VFC. The AMER and EMEA region group names are set as the suffix by setting the UniqueIdentifier to 1, making the group names unique.

The suffix counts towards the 50 character group name limit. Choose the hierarchy level for the UniqueIdentifier value after confirming that the resulting sub-group names will not look identical after the suffix is added.

You can limit how many levels in the VFC group hierarchy become separate groups and sub-groups in WFE by setting the HierarchyLevelDepth parameter in the appsettings.Production file. Sub-groups under the specified hierarchy depth are not created as groups in WFE, and their users get assigned to the parent group on the level specified by the HierarchyLevelDepth parameter instead. If the parameter is not specified or set to the default value, all VFC groups are synchronized to WFO as unique groups.

Example:

Four levels of VFC groups get synchronized to three levels of WFE groups by setting the HierarchyLevelDepth parameter to 3. The UniqueIdentifier is not set.

After the Integrator completes the synchronization process, the country groups contain all users for their child city groups. and the VFC Synced Users group contains all users.

Changes to users or groups that happen in VFC are applied to their WFE equivalent the next time the synchronization process runs. Changes to users or groups that happen in WFE do not apply to their VFC equivalents. If conflicting information exists in VFC and WFE, the changes in WFE are overridden the next time the synchronization process runs. However, if a non-VFC user is manually added to any of the WFE groups representing a synchronized VFC group, the user is not removed the next time the synchronization process runs.

Do not add WFE users manually to the default VFC group that holds all synchronized users.

Switches and data sources

To synchronize the required recording metadata, the switch platforms for which the Integrator is configured must be specified in the appsettings.Production file of the Integrator.

The Integrator supports the synchronization of metadata from:

recorded switch platforms, and
import sources, where VFC does not record the calls, but it ingests the recordings from the switch platform through the configured import source.

The list of supported switch platforms is listed in the configuration file, specifying the platform IDs or import source types, and the platform type that describes the WFE data source type of the platform. The integration process does not run until one or more of the supported platforms is added to the list of configured platforms in the file.

Data sources in WFE do not have to be created manually, the Integrator automatically creates them to represent the switches configured in VFC. You must configure the Integrator to create the right WFE data sources for your deployment and monitoring needs by supplying switch configuration details in the appsettings.Production file.

You must specify:

the VFC Recording Server addresses,
the platform name, describing the platform ID or import source type of the switch,
the time zone of the switch,
optionally, the extensions configured for that switch platform.

The granular configuration options in the Integrator allow for the accurate mapping of extensions to data sources in WFE.

You must add the addresses of all VFC Recording Servers that recorded calls to the data source configuration. Those Recording Servers that are not added do not have their calls synchronized to WFE.

A data source object in the appsettings.Production file can only be of one platform name, and it must be in a single time zone. However, it can represent multiple switches of the same name, in the same time zone, being recorded by one or more VFC recorders. If the extensions are configured for the data source object, the specified extension numbers are associated to the WFE data source upon creation.

The extension parameter can be omitted or left empty for a data source object, which results in all extensions recorded by the specified recorders on the specified platform name to be associated with that data source. The extensions can be configured as an array of individual alphanumeric values or number ranges, but do not support wildcard operators.

If multiple identical data source objects exist in the appsettings.Production file without extension values specified, extensions for that platform name are associated with each WFE data source.

If multiple data source objects exist in the appsettings.Production file without extensions specified but different platform names are set for them, extensions configured to record all platforms are associated to each data source.

If multiple identical data sources exist in the appsettings.Production file and some of them have extensions specified, the described extensions are associated with the corresponding data source created in WFE. The other, unspecified extensions are associated with the first data source that has no extensions added.

At a minimum, you must have one data source object without extensions per platform name. If you have data source objects with extensions specified, it is still recommended to have a data source without extensions specified to ensure that no missed extensions get excluded from the synchronization.

If a platform name has been added to the Configured Platforms parameter, but no data source objects exist in the Data Mapping section, no corresponding WFE data source is created, and no related recording data is synchronized to WFE.

The Integrator configures both the local and UTC time zone of a switch platform to the corresponding WFE data source. The Integrator configuration requires the time zone configured in the IANA time zone format <area>/<location>, but in the WFE user interface the time zone shows in both IANA and UTC/GMT-offset formats, depending on the application. For example, a switch at a site in Los Angeles is seen as America/Los_Angeles in Reports, but shows as GMT-08:00 Pacific Time (US & Canada) on the data source settings page under Recording Management.

Only a subset of IANA time zones are supported in WFE. You must configure a supported time zone value for the Integrator.
Refer to Data Mapping in the VFC to WFE Metadata Integrator Configuration Guide to select a supported time zone that represents your required time zone the closest.

For each configured data source in the appsettings.Production file, the Integrator searches WFE for an existing data source that meets the following criteria:

It has the same name as the data source platform name configured in the DataMapping section of the appsettings.Production file.
The Type matches the platform type associated with the platform name specified in the ConfiguredPlatforms parameter of the appsettings.Production file.
The Switch/sub-type is External Recorder.
The Organization associated with the data source matches the organization ID of the parent organization created as part of the Integrator deployment process.

If the Integrator finds an existing data source with matching details, it notes the switch_ID of the WFE data source. If the Integrator does not find an existing data source with matching details, it creates one.

All data sources created as part of the integration are created with the switch/sub-type External Recorder.

The Seating Arrangement property of the created data source is set to:

Hybrid for phone types,
Free for trader and application types.

The Contact Policy Type of all created data sources is set to Back office - Contact per call.

The Recorded Platform property of the created data source is set to the value of the data source platform specified in the Integrator configuration file.

Do not change the Recorded Platform or Contact Policy Type of the data source in WFE.

Recorders and call metadata

The Integrator synchronizes recording metadata to WFE by periodically checking the VFC database for new recording data and marking them for synchronization. Call marking is the process of reading in a call record from the database, evaluating it against the Integrator configuration, and sending it to the WFE database.

The Integrator only synchronizes recording metadata, not media files.

Each VFC installation is represented as a single recorder in WFE, and all synchronized call records get associated with this recorder, regardless of the number of distinct VFC recorders that captured the calls. The Integrator creates an external recorder server in WFE for each VFC installation. The Server Name of the external server must be specified in the appsettings.Production file. It is recommended the Server Name matches the host name of the Media Repository the Integrator connects to.

The way calls are recorded and stored is different in VFC and WFE. Refer to Data models for more details on the VFC call data models, and see Contacts and Interactions for information about the WFE call data models.

Due to the difference in the call record handling, the call search and replay functionality also differs in VFC and WFE. To keep the call search experience consistent across both systems for VFC users, the Integrator retains the VFC call model in WFE.

In WFE, every record in the search results under Interactions represents a single session from the WFE call model. In VFC, every record in the search results under Conversations represents a single conversation entry from the VFC call model.

If more than one record was created during a conversation, related records can be shown together by selecting the ellipsis (…) button on the record and selecting Show Related.

During the synchronization process, each VFC conversation is mapped to a WFE session, allowing for the WFE call search experience being the same as in VFC.

To maintain the Show Related functionality, sessions are related to contacts and associated records can be viewed when selecting a call record from the search results.

The call records originating from WFE remain unchanged and a single record in the Interaction search results still represents a single session.

If the time interval between the start time of the first segment of a call and the start time of the last segment is longer than 12 hours, the created sessions in WFE are not associated with the same contact.

Encrypt secrets stored in the Integrator configuration file

The WFE API key and VFC API user details can be encrypted, and the Integrator configuration file is automatically updated to only store a hashed secret that represents these freetext values. After the Integrator is installed and configured, running an installation command with the ENCRYPT parameter creates an AES256 hash of the API secrets, and and updates the appsettings.Production file with a new Secret parameter, replacing the WFE and VFC API credentials. If the configuration file contains the freetext values of these credentials, the Integrator writes warnings to the logs, but the metadata synchronization does not require encrypted secrets.

The encrypted values can only be decrypted by manually removing the Secret parameter and reinserting the WfeApiKey and VfcApiUser values in the appsettings.Production file.

If the connection credentials change after encryption and need to be updated, replace the Secret parameter with the WfeApiKey and VfcApiUser parameters containing the new values. After you verify that the connection is successful using these values, run the encryption command again.

If both the encrypted (Secret) and unencrypted (WfeApiKey and VfcApiUser) versions of the values are contained in the configuration file, the Integrator uses the encrypted values.

See Encrypt API connection credentials.

Deployment process

The VFC to WFE Metadata Integrator deployment process requires configuration in the VFC and WFE environments before the installation of the Integrator. The configuration of the synchronization details is carried out in the appsettings.Production.json file of the Integrator tool after installation.

Install server certificates

Open your browser in Administrator mode and go to your VFC Web Interface.
Follow the Server Certificates topic to download the server certificate for the VFC Media Repository server from the VFC Certificate Authority.
Install the downloaded certificate on the server that runs the Integrator service.

Create a parent organization in Workforce Engagement

In an on-premise or single-tenant WFE environment, sign in as Administrator. In a multi-tenant environment, sign in as Tenant Administrator.
Follow the Create an organization topic in the WFE User Management Guide to set up an empty organization for the synchronized VFC data.
Note the name of the organization created. You must enter the exact name in the appsettings.Production configuration file of each Integrator during the configuration process.

Do not change the organization name once it has been configured for an Integrator.

Create a parent group in Workforce Engagement

In an on-premise or single-tenant WFE environment, sign in as Administrator. In a multi-tenant environment, sign in as Tenant Administrator.
Follow the Create a group topic in the WFE User Management Guide to set up an empty group for the synchronized VFC data.

No users must be assigned to the created parent group, or the synchronization process fails.
Note the name of the group created. You must enter the exact name in the appsettings.Production configuration file of each Integrator during the configuration process.

Do not change the group name once it has been configured for an Integrator.

Create API key in Workforce Engagement for each WFE Tenant

In an on-premise or single-tenant WFE environment, sign in as Administrator. In a multi-tenant environment, sign in as Tenant Administrator.
Follow the Generate an API Key topic in the WFE Enterprise Configuration and Administration Guide to create an API key for each Integrator.
Set Key type to External.
When each API key is generated, note their Key ID and Key Value. You must enter the exact values in the appsettings.Production configuration file of each Integrator that synchronize data to this tenant during the configuration process.

Create a VFC API user account

Sign in to VFC as an Administrator user.
Follow the User Configuration topic to create a new user that is only used for submitting API requests to VFC.
1. Set API Access Only to enabled.
Note the user name and password of the created user. You must enter the exact values in the appsettings.Production configuration file of each Integrator during the configuration process.

Configure file upload from Recorder Servers

The Integrator does not process recordings that are stored on the Recorder Servers, so the upload of media and metadata files to a central storage location must be configured.

Sign in to VFC as an Administrator user.
Follow Configuring media file upload to configure policy-based or non-policy based file upload.

Enable External Recorder data sources in Workforce Engagement

To enable External Recorder data sources that represent the VFC switch platforms, turn on the Data Marking API for External Recorder license item in WFE.

In a multi-tenant WFE environment, the service provider must carry out these steps. The tenant administrator cannot enable licenses or configure data sources.

In a browser, go to http://<wfo_app_server_address>/wfo/control/license_edit.
On the License Data page, under Features, enable 2021R1 - Data Marking API for External Recorder.
Click Save.

(optional) Enable AQS in Workforce Engagement

If you have Voice Quality scoring enabled in VFC and would like the voice quality data synchronized, the WFE Audio Quality Statistics license item must be enabled.

In a multi-tenant WFE environment, the service provider must carry out these steps. The tenant administrator cannot enable licenses or configure data sources.

In a browser, go to http://<wfo_app_server_address>/wfo/control/license_edit.
On the License Data page, under Features, enable 2021R1 - Audio Quality Statistics.
Click Save.

Install the Integrator

Follow the Installation Guide to install the VFC to WFE Metadata Integrator.

Configure the Integrator

Follow the Configuration Guide to configure the VFC to WFE Metadata Integrator.

(optional) Encrypt API connection credentials

You can encrypt the API credentials used for connecting to WFE and VFC and ensure that these values are stored securely in the appsettings.<environmentName>.json file.

Verify successful connection by reviewing the logs for successful dependency check messages. If the WFE API key and the VFC API user information are accurate and the connection is successfully established, you can start the encryption of the API credentials.
Open the Command Line as an administrator and run the following command with the ENCRYPT parameter specified. If you specified a new installation directory during the installation process, specify the INSTALLDIR parameter.

msiexec /i VfcToWfeMetadataIntegrator.msi ENCRYPT=”true” /qn

After the command completes, verify the connection between the Integrator, VFC, and WFE by checking the logs for new successful dependency check messages.

Troubleshooting

Follow the Troubleshooting Guide to troubleshoot issues with the VFC to WFE Metadata Integrator.

Post-deployment tasks

Once the integration is configured and active, the following items must be completed and checked:

Verify that the parent organization with the name specified during configuration exists in WFE.
Verify that the parent group with the name specified during configuration exists in WFE.
Verify that the VFC Synced group exists as a child of the parent group in WFE.
Verify that the VFC user groups exist in WFE.
Verify that VFC users are available in WFE, are associated with the same groups as in VFC, and have the right extensions associated to them.
Verify that the data sources configured in the Integrator appsettings.Production file exist in WFE, and have the right name, time zone, recorded platform, contact policy type, and extensions associated with them.
Verify that recordings are visible in the Automated Verification component of WFE.
Verify that recordings are associated with the right users, extensions, and data sources.
Verify that recordings are associated to the Serial Number of the external server that is specified in the Integrator.
Verify that an external recorder server exists in WFE with the Server Name specified in the Integrator appsettings.Production file.

Resilience

The VFC Integrator achieves a resiliency model using an active-passive design. Multiple Integrators can be running and be configured to read from the same VFC database per VFC environment, but only one Integrator is reading at once.

When an Integrator completes its initial dependency checks, it makes an internal note of all dependency statuses. If all dependencies are ready, the Integrator attempts to connect to the database to read data by sending the database a lock request. If no database locks are in place, the database grants the lock to the Integrator that requested it. The active Integrator keeps sending a heartbeat signal to the database to maintain ownership of the lock. While the ownership is allocated, the database declines any further lock requests from other Integrators.

Any Integrators that completed their dependency checks but were not granted the database lock remain in a passive state. In the passive state, Integrators periodically retries gaining ownership of the database lock. The period for reattempting to acquire the lock is 30% of the lock timeout value and is not modifiable. Before resubmitting the lock request, the passive Integrator checks its internal record of dependency statuses, and if all statuses are logged as ready, the Integrator sends the lock request. If any dependencies are not ready, the Integrator carries out another dependency check, and updates its record of statuses.

If the active Integrator fails and no heartbeat signal reaches the database, the lock timeout period starts. After the timeout period elapses, the lock is released, and the next Integrator to submit a lock request is granted database access. The lock timeout period is configurable in the appsettings.Production file of each Integrator.

Limitations

The only WFE module with full functionality access through this integration is Automated Verification.
If the time interval between the start time of the first segment of a call and the start time of the last segment is longer than 12 hours, the created sessions in WFE are not associated with the same contact.
Passive Integrators that do not have ownership of the database lock use their internal record of the dependency statuses noted during the last dependency check to determine if all services are ready, and only run new dependency checks if any dependencies were previously not ready. This means that if a dependency was ready at the last dependency check but fails before the new lock request is sent to the database, the Integrator starts up and fails when it encounters the unavailable dependency, releasing the database lock and restarting the database lock timeout period. This can cause long wait times for Integrators competing for the database lock, as multiple Integrators failing can make the database connection unavailable for multiple consequent lock timeout periods.