Moving to Release 10.0 - preparation tasks

There are several tasks to complete before you move to Release 10.0.

About this task

Before migrating your data, it is recommended that you make a backup of the custom files in the your current installation, such as:

  • Extended API templates
  • Customized screens
  • Localized bundle files
  • Custom themes

Next, ensure that you complete the following sequence of tasks:

Procedure

  1. Before upgrading from Release 9.5 to Release 10.0, compare the entity extension files in <INSTALL_DIR_OLD>/repository/entity/extensions with the entity extension files in <INSTALL_DIR_OLD>/extensions/global/entities. If extension files with matching file names exist, consolidate these files into one file in <INSTALL_DIR_OLD>/repository/entity/extensions.
  2. For purposes of upgrade, Apache Ant is being shipped as part of the migration kit directory. Set the ANT_HOME environment variable to <INSTALL_DIR>/Migration/apache-ant-1.7.1.
  3. Go to the <INSTALL_DIR>/Migration directory and run the following command:
    chmod -R 755 apache-ant-1.7.1
  4. Ensure that the <JAVA_HOME> environment variable points to the folder in which the JDK is installed.
  5. Shut down your production system. The application is unavailable when database backup takes place.
  6. Back up the database server.
    Note: This backup pertains to premigrated data. If you want this data to be available for use with Release 10.0, you must migrate the data before putting your system into production.
  7. For multihop upgrade, two separate log4jconfig.xml files are used. One file is located in the <INSTALL_DIR>/resources folder and the other is copied from the <runtime.old>/resources folder and placed in the <INSTALL_DIR>/Migration/resources folder. During the upgrade process logging will be done in the log files mentioned in both these log4jconfig.xml files.
  8. If you have functional indexes, they must be dropped before migration, and re-created after migration is completed. If you are upgrading in sharded mode, functional indexes for all colonies must be dropped before migration, and recreated after migration.
  9. In nonsharded upgrade mode, you have the option of reducing the size of some database tables by converting CHAR/NOT NULL columns to VARCHAR/NULL columns. If you plan to convert these columns, extend the following files and edit the corresponding XML files:
    • SMCF_85_attribute_default_extn.xml.sample
    • SMCF_920_attribute_default_extn.xml.sample
    • YCD_920_tables_modifications.xml.sample
    You cannot convert these columns in a sharded environment. Thus, if you want these columns converted and plan to move to a sharded environment in the future, you should perform this conversion as part of the nonsharded migration to Release 10.0.

    To convert columns on Db2, perform the Db2: Reducing Table and Index Size migration strategy. However, if you are migrating from Release 8.0 (or later) to Release 10.0 on Oracle, perform the following migration:

    Note: If you upgraded to version 8.5 (or later) and are now migrating to Release 10.0, the SMCF_85_attribute_default_extn.xml.sample file has already been extended and the corresponding XML file modified. To maintain these changes, use the earlier release’s extended file. However, if you want to make additional changes, such as converting CHAR columns that were not converted earlier, re-extend the SMCF_85_attribute_default_extn.xml.sample file, as described in this step.
    1. In the <INSTALL_DIR>/repository/entity/extensions directory, perform the following file updates:
      • copy the SMCF_85_attribute_default_extn.xml.sample file and save the file as SMCF_85_attribute_default_extn.xml.
      • copy the SMCF_920_attribute_default_extn.xml.sample file and save the file as SMCF_920_attribute_default_extn.xml.
      • copy the YCD_920_tables_modifications.xml.sample file and save the file as YCD_920_tables_modifications.xml.
    2. To convert NOT NULL columns to NULL, remove the Nullable attribute and the DefaultValue attribute from the SMCF_85_attribute_default_extn.xml file, the SMCF_920_attribute_default_extn.xml file, and the YCD_920_tables_modifications.xml file. Do not remove the VirtualDefaultValue attribute from the XML files.
      Note: All NOT NULL columns specified in the sample files must be converted to NULL. You cannot convert only some of the NOT NULL columns in these files to NULL.
    3. Optional. To convert CHAR columns to VARCHAR, remove the DataType attributes from the SMCF_85_attribute_default_extn.xml file. If you want to maintain CHAR columns, do not remove the DataType attributes from the SMCF_85_attribute_default_extn.xml file.
      Note: If converting to VARCHAR, follow these guidelines:
      • Convert NOT NULL columns to NULL before converting CHAR columns to VARCHAR.
      • Convert all columns in the SMCF_85_attribute_default_extn.xml.sample file to VARCHAR. You cannot convert only some of the CHAR columns in this file to VARCHAR.
  10. When upgrading to Release 10.0, if the DB_SCHEMA_OWNER property is not set in the <INSTALL_DIR>/properties/sandbox.cfg file, perform the following steps:
    1. Set the DB_SCHEMA_OWNER property to your database shard owner.
    2. Run the <INSTALL_DIR>\bin\setupfiles.cmd script if you are using the Windows environment, and <INSTALL_DIR>/bin/setupfiles.sh if you are using either the Linux® or the UNIX environment.
  11. When upgrading to Release 10.0 and Change Project Management is enabled, if the OVERRIDE_LOAD_DEFAULTS_PK_GEN property is not set in the <INSTALL_DIR>/properties/sandbox.cfg file, perform the following steps:
    1. Set the OVERRIDE_LOAD_DEFAULTS_PK_GEN property to True.
    2. Run the <INSTALL_DIR>\bin\setupfiles.cmd script if you are using the Windows environment, and <INSTALL_DIR>/bin/setupfiles.sh if you are using either the Linux or the UNIX environment.
  12. When upgrading to Release 10.0, do not use property encryption. Before upgrading, ensure to override the encrypted properties in your old runtime.
  13. If custom entities are defined, TableTypes for custom entities must be specified in the entity definitions.
  14. If you are using Db2 and want to drop nullability constraints for the columns that are made nullable, use the <INSTALL_DIR>/Migration/9.5/buildmigration.properties file to set the following properties to Y:
    • db2.allow.required.reorg.stmts

      This property allows the generation of the DROP NOT NULL alters, which drops the null constraints. You must then perform a manual reorg of the tables.

    • db2.allow.reorg.stmts

      If the null constraints are being dropped, set this property to Y to generate REORG TABLE statements for tables that require a reorg. You must manually execute these statements, and then remove the statements from the alter scripts that get generated.

      If you are dropping nullability constraints, it is recommended that you set both these properties to Y.

  15. Exclude configuration tables from synchronization.

    Before upgrade, a complete export and import cycle is run between the staging and production servers. Running an export/import cycle ensures that the changes in the YFS_ENTITY_CHANGE table do not disrupt a change project that is in progress.

    A new section, ExcludeFromSync is included in the changeDataManagementRules.xml file that allows explicit exclusion of configuration tables from the export process. Any section of the config-db.xml file to be excluded from synchronization is specified in the ExcludeFromSync section.

    Note: Warehouse Management System segments are included by default and are not removed from the config-db.xml file.

    <Rule Name="ExcludeFromSync" Value="">

    <ExcludeList>

    <Exclude Name="YFS_SYNC_SUBSCRIPTION"/>

    <Exclude Name="YFS_CHANGE_PROJECT"/>

    </ExcludeList>

    </Rule>

  16. Prevent change tracking for records in certain tables.

    A new section, DisableChangeTracking, is included in the changeDataManagementRules.xml file that prevents change tracking for records in certain tables. Set this rule to "Y" to prevent change tracking for the tables specified under this rule.

    The tables included in DisableChangeTracking are tables that should not be exported by the Data Sync Delta or Change Project Management export processes. When included, entity tracking is disabled for these tables, and associated records are not tracked in the YFS_ENTITY_CHANGE table.

    <Rule Name="DisableChangeTracking" Value="Y">

    <TableList>

    <Table Name="YFS_CUSTOMER"/>

    <Table Name="YFS_CUSTOMER_GRADE"/>

    <Table Name="YFS_CUSTOMER_ASSIGNMENT"/>

    <Table Name="YFS_CONSUMER"/>

    <Table Name="YFS_CUSTOMER_ADDNL_ADDRESS"/>

    <Table Name="YFS_CUSTOMER_ANALYTICS"/>

    <Table Name="YFS_CUSTOMER_CONTACT"/>

    <Table Name="YFS_CUSTOMER_CURRENCY"/>

    <Table Name="YFS_CUSTOMER_PAYMENT_METHOD"/>

    <Table Name="YFS_CUSTOMER_SCH_PREFERENCE"/>

    <Table Name="YFS_CUSTOMER_SLOT_PREFERENCE"/>

    <Table Name="YFS_PARTICIPANT_NOTE"/>

    </TableList>

    </Rule>

  17. To manually run DDLs for the following targets, use the <INSTALL_DIR>/Migration/9.5/buildmigration.properties file to set the yfs.apply.sql.manually property to Y:
    • alter-history-tables
    • install-history-indexes
    • run-history-drop
    • alter-transaction-tables
    • install-transaction-indexes
    • run-transaction-drop
    If you want to manually run the DDLs, ensure that you apply the DDLs before running the corresponding targets. When you run the target, the upgrade process does not apply the SQLs but creates the required .done files.
  18. If upgrading from Release 9.0 (or earlier), enclose the entry, GraphUI element containing GraphUIKey="20050711140704272558", within comments in <INSTALL_DIR>/COM/Migration/9.0/COM_Add-in/database/FactorySetup/ycd/changed/YFS_Graph_UIList.xml.