What Do I Need to Know About Managing Multi-Tenant Environments?

In environments configured with more than one tenant, the Genesys Info Mart Server enables the use of tenant aliases to control user access to data stored in a single Info Mart database. These aliases include a set of intermediate views (all prefixed AGR_ALIAS_) to the original source tables and views that restrict the data set that is returned to that data which pertains to the tenant only. Because Reporting and Analytics Aggregates (RAA) is an optional Genesys Info Mart component, the mechanism for updating tenant aliases for the aggregate tables is achieved apart from the Genesys Info Mart mechanism for updating tenant views.

This page describes how to run the RAA tenant alias update module.

How Often Should I Update Tenant Aliases?

Update tenant aliases whenever a tenant is added or deleted from Genesys Info Mart configuration or whenever there are changes to RAA queries (such as with the rollout of a hot fix, the inclusion of a query patch as described in How Do I Customize Queries and Hierarchies?, or in a development environment in which you are designing your own reports). If information about a tenant changes—such as the tenant moving to a different account— updating the aliases will also be necessary. Otherwise, existing aliases might become unusable, and the subset of reports (queries) based on the existing tenant views might not retrieve expected data.

After the aggregation process runs for the first time, run an update of tenant aliases. Genesys recommends that you also schedule an update of tenant aliases to occur regularly and automatically (for example, using a batch file that is called by an O/S scheduler). Running the RAA tenant alias update affects views of only those database objects that are controlled by the aggregation layer—namely:

• The AGT_* tables.
• The AGR_* tables (these are internal RAA entities).
• All GCXI–specific tables and views.

Whenever table structures change, you must also update tenant views for the dimension and fact tables (which are referenced by the Genesys CX Insights Detail reports); however, this update is apart from RAA. Refer to the section about creating read-only tenant views in the Genesys Info Mart Deployment Guide for further information.

Prerequisites and Logging

The following are the minimum required permissions for the alias (or tenant) account:

Oracle	Microsoft SQL
grant connect to <account> grant create view to <account> grant create table to <account> grant resource to <account>	grant create view to <account> grant create table to <account> The account (database user) must belong to the same database as the Genesys Info Mart account. A schema in the database must exist with the same name as database user. The database user must own the schema.

When the update is run, RAA connects to the specified database and begins creating intermediate views. RAA logs each operation—for example:

Creating view <AG2_QUEUE_ACC_AGENT_MONTH> in tenant schema

When all views are created, the update drops stale views and then exits. Any errors that the update encounters are also logged.

Reference: Format of the Tenant Alias File

The -updateAliases runtime parameter (described in the Reporting and Analytics Aggregates Deployment Guide) requires that you specify a file named AliasFile, which must contain one line for each tenant alias account, formatted as described below. For any tenant alias not listed in the file, -updateAliases clears all views.

Specifying the Genesys Info Mart schema

The -updateAliases runtime parameter supports GIM schemas that have a name different from the GIM user name. However, if the GIM schema name differs from GIM user name, and the GIM schema is not either public (on PostgreSQL) or dbo (on MS SQL), you must complete the following steps:

1. Specify the GIM schema in the AliasFile:

   (gim-user-schema <schema_name>)

   where ‹schema_name› is the name of the GIM schema. This is required when the GIM schema name is not the same as the GIM user name.

2. Before running the -updateAliases tool, ensure that the default schema matches the GIM user in database:
   • PostgreSQL — Use the following SQL statement to view the search path:

      show search_path

     The GIM schema is expected to be first in the search_path variable. If it is not, then execute the following SQL statement:

      alter role <GIM user> set search_path = <GIM schema>, public;

   • MSSQL — Use the following SQL statement to view the default schema:

      SELECT SCHEMA_NAME()

     The GIM schema is expected to be the default schema for the GIM user. If its not, then execute the following SQL statement:

      ALTER USER <GIM user> WITH DEFAULT_SCHEMA = <GIM schema>;

3. Specify the GIM schema (gim-user-schema "<schema_name>") in the Tenant Alias File.

Formatting subsequent lines

Format each line, other than the first line, as follows:

(aliases-for-account name: <UName> login: "<lname>" password: "<pwd>" (tenant[s]: <ID#>) (time-zone: <TZcode>))

where:

• ‹UName› is the name of the tenant user account.
• ‹lname› is the tenant user account (should now be the same as the tenant schema name).
• ‹pwd› is the password of the tenant user account.
• ‹ID#› is the ID of the tenant as specified in the TENANT_KEY field of the TENANT Info Mart database table. This value, incidentally, matches the tenant’s DBID in Configuration Server. You can specify more than one tenant for this parameter—for example: (tenants: 4 5) or the value all for all tenants.
• ‹TZcode› is the code for an additional time-zone—one other than the Genesys Info Mart default time zone. This code must be declared in the time-zones.ss file and placed in the Genesys Info Mart root directory. Note that specifying an additional time-zone parameter and setting up the time-zones.ss file are optional. See Aggregation in Multiple Time Zones for more information.

Depending on the RDBMS type and the number of tenant accounts that are specified in the alias file, the update completes in a matter of seconds after it has been run.