Known Issues and Recommendations
Reporting and Analytics Aggregates
The Known Issues and Recommendations section is a cumulative list for all 8.5.x releases of Reporting and Analytics Aggregates. This section provides the latest information on known issues and recommendations associated with this product. It includes information on when individual items were found and, if applicable, corrected. The Resolved Issues section for each release describes the corrections and may list additional issues that were corrected without first being documented as Known Issues.
See also Internationalization Issues.
The build year is stated incorrectly (2010) in log files and in the output of the -version command. The correct build year is 2020.
ID: GII-2832 | Found In: 8.5.011.03 | Fixed In: 8.5.011.04 |
On RAA release 8.5.007 and 8.5.008 deployments that use Microsoft SQL, and where MicroStrategy Web uses Turkish or Azeri Latin, the database connection can fail with an ODBC error. To resolve this issue, upgrade to RAA release 8.5.009.04, or contact Genesys Customer Care.
ID: GII-6547 | Found In: 8.5.007 and 8.5.008 | Fixed In: 8.5.009.04 |
On PostgreSQL deployments, reaggregation of data for a specified period can fail in scenarios where RAA has been upgraded from a release earlier than 8.5.001.23 to a release earlier than 8.5.006.00, and the structure of any AGT_* tables have been changed (for example, if a metric was added). This results in incorrect partition rules being created for old partitions, and the following error message can appear in the log following aggregation or reaggregation:
org.postgresql.util.PSQLException: ERROR: new row for relation ... violates check constraint
Beginning with RAA 8.5.006.00 and later, partition rules are for the affected tables are automatically corrected. If you prefer not to upgrade to RAA 8.5.006.00 or later, contact Customer Care for help working around this issue.
ID: GII-6457 | Found In: 8.5.001.23 | Fixed In: 8.5.006.00 |
On PostgreSQL deployments where there are several time zones configured in RAA, readPending operations take longer than expected.
ID: GII-6429 | Found In: 8.5.001.48 | Fixed In: 8.5.005.03 |
In release 8.5.005.03 and later, the -updateAliases runtime parameter supports GIM schemas that have a name different from the GIM user name (see GII-6404). 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:
- 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>;
- PostgreSQL — Use the following SQL statement to view the search path:
- Specify the GIM schema (gim-user-schema "<test_schema>") in the Tenant Alias File. For more information, see the RAA User's Guide.
In releases earlier than 8.5.005.03, on PostgreSQL deployments, the -updateAliases runtime parameter fails in scenarios where Genesys Info Mart uses a database schema other than public, unless the schema name is the same as the Info Mart account name (database user). To work around this issue, complete the following steps:
- Execute the following SQL statement under <gim-user> for each <tenant login> before the -updateAliases command:
grant usage on schema <gim schema> to <tenant1 login>;
- Execute the following SQL statement under <gim-user> for each <tenant login> after the -updateAliases command:
revoke usage on schema <gim schema> from <tenant1 login>;
ID: GII-6394 / GII-6404 | Found In: 8.5.004.05 | Fixed In: 8.5.005.03 |
Hierarchies are not populated with data at the HOUR level or higher in scenarios where:
- Hierarchies are disabled in the [agg-populate-disable] section.
- The materialize-subhour-in-db option is activated.
- The hierarchies are re-enabled in the [agg-populate-disable] section.
To work around this issue, complete the following steps:
- Back up the Info Mart database.
- Disable the affected hierarchies by adding them back to the [agg-populate-disable] section. (Wait a few minutes for the update to be processed.)
- Remove [materialize-subhour-in-db].
- Restart Genesys Info Mart / RAA and wait until an aggregation cycle completed (typically 15-30 min).
- Enable the affected hierarchies by clearing the [agg-populate-disable] section. (Wait a few minutes for the update to be processed.)
- Add the materialize-subhour-in-db option.
- Restart Genesys Info Mart / RAA and wait until an aggregation cycle completed (typically 15-30 min).
- The hierarchies are now enabled, and will be populated with new data in HOUR+ levels.
ID: GII-6349 | Found In: 8.1.405.09 | Fixed In: |
If you are deploying RAA with MS SQL Server Standard Edition, in certain scenarios you may encounter an error such as the following:
Agg Error - Cannot enable compression for object 'AG2_CALLBACK_HOUR'.
Only SQL Server Enterprise Edition supports compression
To work around this issue, set the option ms-sql-std-edition in the [agg-feature] section of the Genesys Info Mart application.
ID: GII-6152 | Found In: 8.1.405.07 | Fixed In: |
RAA has a small memory leak, which becomes apparent when aggregation is performed many times over very long intervals. For example, in a two year period, expect the leak to total about 15 MB. This leak does not have a significant impact on performance.
ID: GII-5989 | Found In: 8.5 | Fixed In: 8.5.001.23 |
The Physical Data Model documentation for Reporting and Analytics Aggregates Reporting and Analytics Aggregates fails to list the RAA Indexes. The correct list is as follows:
- RESOURCE_.IDX_AGR_RESOURCE_NAME
- RESOURCE_.IDX_AGR_RESOURCE_AG_NAME
- RESOURCE_.IDX_RES_KEY_TYPE_CODE
- IXN_RESOURCE_STATE_FACT.IDX_IRSF_IRF
- IRF_USER_DATA_GEN_1.IDX_IRFUG_GSWCAG
- SM_RES_STATE_FACT.IDX_RSF_AGR_DB
- SM_RES_SESSION_FACT.IDX_RSSF_AGR_DB
- IXN_RESOURCE_STATE_FACT.IDX_IRSF_AGR_DB
- SM_RES_STATE_REASON_FACT.IDX_RSRF_AGR_DB
- INTERACTION_RESOURCE_FACT.IDX_IRF_AGR_DB
- SM_MEDIA_NEUTRAL_STATE_FACT. IDX_MNSF_AGR_DB (release 8.5.008 and later)
ID: GII-5924 | Found In: 8.x | Fixed In: |
On deployments with PostgreSQL or Oracle databases where multiple time zones are configured in Genesys Info Mart / RAA (causing HOUR and SUBHOUR levels in AGT_* tables to sometimes share data between time zones), a purge using the QUERY syntax may fail to purge some data from shared levels HOUR and SUBHOUR).
ID: GII-5234 | Found In: 8.1.405.09 | Fixed In: |
During aggregation, RAA can generate an error similar to the following:
Zone delimiting time key NNN is absent in at least some date-time dimensions.
To work around this problem, avoid using zoneOffset Aggregation parameters with values greater than the range of keys populated in the DATE_TIME dimension. Typically, the zoneOffset value should be less than a week (that is, less than 604800).
ID: GIM-4538 | Found In: 8.1.102.02 | Fixed In: |
In the RAA release 8.5.011.03, the build year is stated incorrectly (2010). This value appears in logs, and is displayed in the output of the -version command. The correct build year is 2020.
ID: GCXI-2832 | Found In: 8.5.011.03 | Fixed In: |
In rare scenarios where it takes a long time for the healthCheck tool to run, the healthCheck tool reports a problem where none exists, and exits prematurely with the following message:
RAA 8.5.010.01 dispatching is stopped!
ID: GCXI-2182 | Found In: 8.5.010.01 | Fixed In: 8.5.011.00 |
The ACCEPTED_FCR metric in the ID_FCR aggregate table is sometimes populated with incorrect values that are greater than actual. To resolve this problem, contact Customer Care.
ID: GCXI-2089 | Found In: 8.5.009.04 | Fixed In: 8.5.010.01 |
RAA sometimes stores incorrect values for GPR metrics in the QUEUE and QUEUE_GRP aggregates, due to an incorrect value in the ADDED_TS column of the GPM_FACT table.
ID: GCXI-2088 | Found In: 8.5.009.04 | Fixed In: 8.5.010.01 |
In some scenarios, the ID_FCR aggregate works slowly on partitioned databases. To resolve this problem, contact Customer Care.
ID: GCXI-2026 | Found In: 8.5.008.00 | Fixed In: 8.5.010.01 |
In some scenarios, the ID aggregate works slowly on partitioned databases. To resolve this problem, contact Customer Care.
ID: GCXI-1980 | Found In: 8.5.008.00 | Fixed In: 8.5.010.01 |
When upgrading RAA, be sure to use the set of files from the Installation Package (IP) to which you are upgrading. If you continue to use some of the files (partition-kit.ss or patch-agg-subhour.ss, for example) from a prior release, then you might encounter errors such as the following:
Argument 'false' to 'apply-to-args' has wrong type (java.lang.Boolean) (expected: procedure)
ID: ER# 319335618 | Found In: 8.1.100.31 | Fixed In: |
In some callflow scenarios involving the customer leaving the call during a transfer or conference initiation, due to a Genesys Info Mart limitation (noted in ER#s 287617711, 286023177, and 286022901), the following measures might not reflect the full duration of the consultations:
- All consult measures (CONSULT_* columns in the aggregates)
- All warm consult measures (*_WARM_* columns)
- All conference-initiated measures (CONFERENCE_INITIATED_* columns).
ID: ER# 299444482 | Found In: 8.1.001.04 | Fixed In: |
On Microsoft Windows platforms, you cannot install RAA 8.1 in plug-in mode over an existing version as it is documented. Rather, you must uninstall the previous RAA version in order to reinstall it or to install a new version.
ID: ER# 290013039 | Found In: 8.1.000.12 | Fixed In: |
By design, RAA uses the INTEGER data type on SQL Server platforms to store values for measures at the lower aggregation levels. This data type has a narrower range of values that can be written to INTEGER fields than other numeric data types. If, during the aggregation of data, values exceed this data type's capacity (as might be the case for lengthy agent-state durations or long-running interactions both of which are stored in seconds), then RAA will log the following:
Arithmetic overflow error converting expression to data type int
.
If these long-running interactions or agent states are legitimate—and not due to Genesys Info Mart error—and you choose not to set the days-to-keep-active-facts Genesys Info Mart option (in order to reduce the duration of active interaction or state), then to avoid this error, consider disabling the problematic aggregates following the instructions provided in the Reporting and Analytics Aggregates Deployment Guide.
ID: ER# 295306930 | Found In: 8.0.100.05 | Fixed In: |
Internationalization Issues
Information in this section is included for international customers.
On RAA release 8.5.007 and 8.5.008 deployments that use Microsoft SQL, and where MicroStrategy Web uses Turkish or Azeri Latin, the database connection can fail with an ODBC error. To resolve this issue, upgrade to RAA release 8.5.009.04, or contact Genesys Customer Care.
ID: GII-6547 | Found In: 8.5.007 and 8.5.008 | Fixed In: 8.5.009.04 |