Jump to: navigation, search

Migration of the 9.0.x release to newer versions

Important
In release 9, you must upgrade all iWD components to the same release version (9.0.xxx must be the same for all components) to guarantee correct functioning.

How to use this guide

  1. Check your iWD version.
  2. Install the latest version.
  3. Perform all the steps one by one between your version and version you installed in step 2.
    For example, if you have 9.0.009.07 and migrate to the 9.0.011.xx, then you need to perform the following steps sequentially:
    1. Migration to 9.0.009.23+
    2. Migration to 9.0.010.xx

Migration to 9.0.015.xx

Starting with this release, Genesys strongly recommends using native plugins provided with iWD. Kettle aggregation plugins do NOT support the new dimensions added in this release. Use of custom Kettle plugins is fully supported.

To switch to using the native version of the aggregation plugins, adjust the plugins.properties file.

Important
If you have already installed 9.0.015.03, please follow the migration procedure here.

Migration procedure

  1. Stop iWD Data Mart runtime node.
  2. If you use aggregation plugins, it is recommended to switch aggregation to the native version of plugins. Using an ASCII editor, change plugins.properties file, for each plug-in that you have enabled, as shown below:
    ${KETTLE_REPOS_DIR}\plugins\classif,task_classif_fact,native
    ${KETTLE_REPOS_DIR}\plugins\age,task_age_fact,native
    ${KETTLE_REPOS_DIR}\plugins\agent,task_agent_fact,native
    ${KETTLE_REPOS_DIR}\plugins\capt,task_capt_fact,native
    ${KETTLE_REPOS_DIR}\plugins\queue,task_queue_fact,native
  3. Install the new iWD Runtime Node application.
  4. Start the iWD Runtime Node application.

Migration to 9.0.014.xx

Changes to aggregate tables

This version contains the following changes related to aggregate tables.

  • Intraday aggregates tables I_TASK_[Subj]_FACT_15MIN have been removed in this release. The Aggregate Intraday job now directly populates H_TASK_[Subj]_FACT_15MIN tables.
  • For backward compatibility, the I_TASK_[Subj]_FACT_15MIN view has been introduced to reflect intraday aggregates tables behavior.
  • Population of H_TASK_[Subj]_FACT_DAY tables is triggered by the fact that corresponding H_TASK_[Subj]_FACT_15MIN table contains a full set of 15-minute intervals for that particular day.

Migration procedure

  1. Stop the iWD Runtime Node application.
  2. Back up the Data Mart database.
  3. Install the new iWD Runtime Node application.
  4. If you use the H_TASK_[Subj]_FACT_15MIN table directly in your reports or plugins, you need to take into account that it may now contain intervals for the current day. If you expect the prior behavior, you need to add a condition such as the one below to filter the incomplete aggregated day.
    For example:
     
    SELECT * FROM H_TASK_<subj>_FACT_15MIN WHERE interval_date_key <= (SELECT COALESCE(MAX(interval_date_key), 0) FROM H_TASK_<subj>_FACT_DAY)
     
    The <subj> can take values from the list of aggregate names: AGE, AGENT, CAPT, CLASSIF, QUEUE.
  5. Start the iWD Runtime Node application.

Migration to 9.0.013.xx

The following default attributes types were changed from string to list:

  • iwd_ext_resultCode
  • iwd_ext_requestedAgentGroup

To update the default attributes please follow this procedure.

Migration to 9.0.010.xx

Custom Attributes can now have types configured. To update the default attributes please follow this procedure.

Migration to 9.0.009.23+

Important
Interaction Server 8.5.3+ is required for this release of iWD and higher. DB Server connection is not supported: an ODBC connection must be used.

All standard iWD columns created in the Interaction Server database have been converted to type nvarchar. The length of all standard columns is also aligned with the Data Mart database.

Standard indexes are recreated during the migration procedure. If you have custom indexes using standard iWD columns, you will need to drop them before the migration run and recreate them manually after the migration.

The following procedure must be repeated for all iWD Solutions with different Interaction Servers.

Migration procedure

  1. Stop the Interaction Server application.
  2. Back up the Interaction Server database.
  3. If you have any non-standard indexes that use standard iWD columns, drop them manually to speed up the migration procedure.
  4. Log into iWD Plug-in for GAX.
  5. Open Business Structure.
  6. Navigate to your iWD tenant.
  7. Navigate to your Solution from the navigation tree and select the Migration tab. The Interaction custom properties and migration issues table on the right side notifies you of the updates that must be made.
  8. Press the Configure button.
  9. Recreate the non-standard indexes dropped in step 3.
  10. Start the Interaction Server application.

Migration to 9.0.008.xx

If you have not changed the default value of iWD Manager's [iWD]/filterElementValuePattern option, then either:

  • Update this option to the new default value from Manager Configuration Options; or;
  • Remove this option from the iWD Manager configuration object. This will force the application to use the default option value.

If there is a customized value stored in filterElementValuePattern then make sure that your regex allows percent (%), underscore (_) and backslash (\ ) for use with SQL wildcards within iWD Manager's filters.

Migrate iWD Manager Logging options

Previously iWD Manager logging was configured via the log4j.properties file. This file has been removed and configuration properties have moved to Configuration Server. Move existing options according to the following mapping:

log4j Property <section.property> Comment
log4j.rootLogger=DEBUG... log.level add rootLogger level to log.level option
log4j.appender.Console=org.apache.log4j.ConsoleAppender log.log-to-console If Console logging is enabled, set log.log-to-console to true
log4j.appender.Console.Threshold=TRACE log.console-log-level  
log4j.appender.centralized_manager=com.genesyslab.iwd.log.CentralizedAppender log.centralized-logging If Centralized logging is enabled set log.log-to-file to true
log4j.appender.centralized_manager.Threshold=DEBUG log.centralized-log-level DEBUG, TRACE, WARN, INFO => STANDARD, ERROR => ALARM
log4j.appender.manager=org.apache.log4j.RollingFileAppender log.log-to-file

log.archive

  • If File logging is enabled set log.log-to-file to true
  • If Logger class is org.apache.log4j.FileAppender set archive to false,
  • If Logger class is org.apache.log4j.RollingFileAppender set archive to true
log4j.appender.manager.Threshold=DEBUG log.file-log-level  
log4j.appender.manager.File=/GCTI/iWD/iwd_manager.log log.log-filename  
log4j.appender.manager.MaxBackupIndex=9 log.max-history  
log4j.appender.manager.MaxFileSize=1024MB log.max-file-size  

Migrate Data Mart and History Node logging options

Data Mart and History Node logging options have been updated. Migration to the new version of logging configuration may be performed via iWD Plugin for GAX. Note that iWD Plugin for GAX should be updated to version 9.0.008.0x

  1. Login to GAX.
  2. Navigate to GAX -> Configuration -> Environment > Tenants.
  3. Go to the iWD Attributes tab
  4. Check that the fields "'Current Configuration Version"' and "'Actual Configuration Version"' have the same value—9.0.0.2.
  5. If the "'Current Configuration Version'" is lower than the actual one, click the "'Update Configuration"' button.
  6. If the '"Current Configuration Version"' is still not updated, refer to the GAX logs.
  7. If the "'Current Configuration Version"' and "'Actual Configuration Version'" are equal to 9.0.0.2, you can check and modify options as described on this Logging page.

Migration to 9.0.007.07

If you have already installed a 9.0.x iWD Runtime Node prior to the 9.0.007.07 release, you must manually upgrade the database schema before starting the new iWD Runtime Node versions. The upgrade procedure alters the H_TASK_FACT table, adding the NOT NULL constraint to the last_task_event_id column and changing the primary key.

Migration Procedure

  1. Stop the iWD Runtime Node application.
  2. Back up the Data Mart database.
  3. Install a new iWD Runtime Node application.
  4. In the <iWD Runtime Node>/etl/migration/manual directory, find a migration script for the appropriate database type and run it on the Data Mart database.
  5. Start the iWD Runtime Node application.
This page was last edited on January 14, 2021, at 16:43.
Comments or questions about this documentation? Contact us for support!