Step 5: Migrate transaction data
You can migrate transaction data by running certain commands.
About this task
- When migrating from 9.3, 9.4, or 9.5 to 10.0, run the following command:
-
${ANT_HOME}/bin/ant -Druntime=<INSTALL_DIR> -Druntime.old=<INSTALL_DIR_OLD> -f buildmigration.xml -logfile <logfile> -Dtarget=upgrade-transaction-tables migrate
-
- When migrating from 9.3, 9.4, or 9.5 to 10.0, from the
<INSTALL_DIR>/COM/Migration/
9.5/COM_Add-in
directory, run the following command:${ANT_HOME}/bin/ant -f ycdmigration.xml -Druntime=<INSTALL_DIR> -Druntime.old=<INSTALL_DIR_OLD> -DYANTRA_RUNTIME_NEW=<INSTALL_DIR> -Dtarget=upgrade-transaction-tables migrate -logfile <logfile>
Important:- As part of the transaction data migration, only the factory defaults are upgraded.
- If you are migrating from 9.3, 9.4, or 9.5 to 10.0, along with
COM_Add-in
, but do not want to upgrade Sterling Call Center or Sterling Store Engagement (Legacy) run the following command:${ANT_HOME}/bin/ant -f ycdmigration.xml -Druntime=<INSTALL_DIR> -Druntime.old=<INSTALL_DIR_OLD> -DYANTRA_HOME_NEW=<INSTALL_DIR> -DYANTRA_RUNTIME_NEW=<INSTALL_DIR> -Dtarget=upgrade-transaction-tables -Dcom.recertification=true migrate -logfile <logfile>
- This command performs the following inner tasks:
pre-transaction-migration
migrate-transaction-data
post-transaction-migration
apply-fc-setup
- Typically you update the unique transaction indexes by running the
install-transaction-indexes target
before you update tables with theupgrade-transaction-tables
target. However, if more than one record exists in the YFS_USER table for DISPLAY_USER_ID or ENTERPRISE_CODE, you must run theupgrade-transaction-tables
target before you run theinstall-transaction-indexes
target. Otherwise, theinstall-transaction-indexes
target fails because a unique index cannot be created for the YFS_USER table. - If you have deleted any factory setup records and the
upgrade-transaction-tables
target fails, you must add the deleted records to the database before continuing the upgrade. - If an SQLCODE=-204, SQLSTATE=42704 error is displayed when you run the
upgrade-transaction-tables
target on Db2®, you can ignore the error message. - If you are upgrading from 9.0 or earlier version, and if the ORA-12899: value too large for
column COMMON_CODE_KEY in YFS_COMMON_CODE error message is displayed, ensure that either the
COMMON_CODE_KEY is not more than 19 bits or change the migrator
<INSTALL_DIR>\Migration\9.0\transaction\xmls\migrator_customer_common_codes.xml
where you append 5 bits 90MIG to COMMON_CODE_KEY by ensuring that the total length is not more than 24 bits. -
The YSCPreInstallMetadataCreator class is called to create the factory setup for the metadata shard. The class creates records in the following tables:
PLT_DB_COLONY PLT_DB_COLONY_POOL PLT_DB_POOL
These tables store connection properties for a Sharded deployment.
-
The
*.done
files created in the9.3 status
folder for the task upgrade-transaction-tables are:transaction_ant_pca_migration.xml.done
transaction_ant_migration.xml.done
transaction_ant_postmigration.xml.done
transaction_ant_premigration.xml.done
transaction_ant_applyfcsetup.xml.done
transaction_Add-in_applycomfcsetup.xml.done
-
The
*.done
files created in the9.4 status
folder for the task upgrade-transaction-tables are:transaction_ant_pca_migration.xml.done
transaction_ant_migration.xml.done
transaction_ant_postmigration.xml.done
transaction_ant_premigration.xml.done
transaction_ant_applyfcsetup.xml.done
transaction_ant_applicationversion.xml.done
transaction_ant_metadatamigrator.xml.done
transaction_ant_apiresourcemigrator.xml.done
transaction_Add-in_applycomfcsetup.xml.done
-
The
*.done
files created in the9.5 status
folder for the task upgrade-transaction-tables are:transaction_ant_pca_migration.xml.done
transaction_ant_migration.xml.done
transaction_ant_postmigration.xml.done
transaction_ant_premigration.xml.done
transaction_ant_applyfcsetup.xml.done
transaction_ant_applicationversion.xml.done
transaction_ant_metadatamigrator.xml.done
transaction_ant_apiresourcemigrator.xml.done
transaction_Add-in_applycomfcsetup.xml.done
-
- When migrating from 9.3, 9.4, or 9.5 to 10.0, run the following queries if necessary:
- If you have custom status modification groups, run the respective update query to fix status modification records inserted during the upgrade.
- If custom status modification group is created for
ORDER_FULFILLMENT
:update YFS_STATUS_MODIFICATION set STATUS_MOD_GROUP_KEY='ORDER_FULFILLMENT' WHERE ORGANIZATION_CODE = 'DEFAULT' AND STATUS_MOD_GROUP_KEY IS NULL AND STATUS_MODIFICATION_TYPE_KEY IN ( SELECT STATUS_MODIFICATION_TYPE_KEY FROM YFS_STATUS_MODIFICATION_TYPE WHERE PROCESS_TYPE_KEY='ORDER_FULFILLMENT' )
- If custom status modification group is created for
PO_FULFILLMENT
:update YFS_STATUS_MODIFICATION set STATUS_MOD_GROUP_KEY='PO_FULFILLMENT' WHERE ORGANIZATION_CODE = 'DEFAULT' AND STATUS_MOD_GROUP_KEY IS NULL AND STATUS_MODIFICATION_TYPE_KEY IN ( SELECT STATUS_MODIFICATION_TYPE_KEY FROM YFS_STATUS_MODIFICATION_TYPE WHERE PROCESS_TYPE_KEY='PO_FULFILLMENT' )
- If the custom status modification group is created for
QUOTE_FULFILLMENT
:update YFS_STATUS_MODIFICATION set STATUS_MOD_GROUP_KEY='QUOTE_FULFILLMENT' WHERE ORGANIZATION_CODE = 'DEFAULT' AND STATUS_MOD_GROUP_KEY IS NULL AND STATUS_MODIFICATION_TYPE_KEY IN ( SELECT STATUS_MODIFICATION_TYPE_KEY FROM YFS_STATUS_MODIFICATION_TYPE WHERE PROCESS_TYPE_KEY='QUOTE_FULFILLMENT' )
The
YFS_SHIPMENT_LINE
table in Sterling Order Management System Software has a column named
BACKROOM_PICKED_QTY
and Sterling Store Inventory Management has a column named
BACKROOM_PICKED_QUANTITY
which was referred with the XML name
BackroomPickedQuantity
. However, this XML name now points to
BACKROOM_PICKED_QTY
column. The shipment APIs return the value of this column in
the BackroomPickedQuantity
attribute.
Therefore, for existing shipments,
users must update the value of BACKROOM_PICKED_QTY
same as
BACKROOM_PICKED_QUANTITY
by running an SQL query like update
yfs_shipment_line set backroom_picked_qty=backroom_picked_quantity
.