Upgrading custom components
Be sure to read all of the information about migration for custom components, as those components will be impacted during migration.
Read information about customizing the user interface thoroughly and understand the impact of various features on your customizations. The impact analysis sections provide you with an understanding of the reasons behind some of the changes that were made.
For a complete list of changes, please go through the XML and HTML files shipped as part of the upgrade kit. These list every change performed to every API input and output XMLs, data published by events, user exit input and output XML changes, and data published by monitors.
User interface customizations are also impacted during upgrade. The procedure for ensuring that your user interface customizations continue to function correctly are also listed here.
Backward compatibility support
When performing your migration assessment, you should also consider backward compatibility. This section describes how Sterling Order Management System Software supports APIs, user exits, and events in backward compatibility mode.
A list of APIs, user exits, and events supported in backward compatibility mode is
provided in the 10_upgrade_home.html file, located in the
Foundation_Upgrade_Reports.zip file.
By default, this migration sets all user exits, events, and subflow versions to 'blank' (current version). The backward compatibility mode for these components must be set manually from the Applications Manager in the respective details windows found under Application Platform.
By choosing to run in backward compatibility mode, you may not be able to utilize the new functionalities. It is recommended that the current version is used as much as possible to take advantage of the additional features provided in Release 9.5.
Backward compatibility for APIs
Every API invocation maps to a particular class and
a method. To achieve backward compatibility, the version number must
be specified as part of the API invocation. Specify the version number
for the API you are invoking in the yifclient.properties file,
through the property provided, as follows:
yfs.api.<apiname>.version=<versionnumber>
Here, the valid values for <versionnumber> are ver73,
ver75, or ver75sp1.
If the version number is not provided, the current version is assumed as the default (in this case, Release 9.5).
<INSTALL_DIR> directory. This enables you
to re-create the runtime environment without losing your configurations
and extensions.Upgrading backend customizations
The upgrade home page is located in the 10_upgrade_home.html file,
located in the Foundation_Upgrade_Reports.zip file.
From this page, you can view the following:
- API Default Template Changes: Default XML template differences between Release 8.0 and Release 9.5 provided in XML format.
- API Input and Output XML Changes: Analyzed XML differences between Release 8.0 and Release 9.5 provided in XML format.
- Event Differences: Default XML event differences between Release 8.0 and Release 9.5 provided in XML format.
- Monitor Differences: Default XML monitor differences between Release 7.3 and Release 9.5 provided in XML format.
Custom indexes
Review the index creation scripts in
<INSTALL_DIR>/Migration/9.5/database/scripts/<db
version>/transaction/indexadds.sql and
<INSTALL_DIR>/Migration/9.5/database/scripts/<dbtype>/history/indexadds.sql
to ensure that there are no existing custom indexes of the same name. However, this is an issue only
if custom indexes have been created with a YFS_ prefix.
Upgrading console customizations
The list of tasks that need to be carried out for upgrading console customizations is provided as part of the upgrade procedures. Because the user interface framework-level changes affect your custom code, some reconciliations are necessary as part of the upgrade.