Abstract:

Customers using IBM Enterprise Order Management System (OMS) need to upgrade to newer versions of product to take advantage over their competitors due to a number of reasons like –

  • Enhance business capability of existing solution through additional out-of-the-box (OOTB) functionalities which offer best industry practices
  • Avoid being outdated on technology road map which may limit operational and business scalability
  • Deploy custom solution from on-premises to cloud to reduce cost and abstracted from nitty-gritties of infrastructure, hardware, environment provisioning, implementation, roll out and deployment

Nuances during upgrade of any enterprise custom OMS solution can be small to huge with business impact if not planned properly, or if implementation methodologies are not adhered in existing production solution and standards.

The objective of this article is to bring out upgrade methodology and related design considerations for OMS practitioners and business to understand various components involved during upgrade.

Problem Statement:

While planning and performing upgrade, we think why enterprise applications cannot be upgraded like any other developer or consumer utility applications by just Select Upgrade–>Hit Next–>Hit Next–>Upgraded.

A theoretical simple answer is Yes, However, this works only when business is using an enterprise application as-is without any customization which doesn’t happen in real world. Each business is unique in terms of business rules, technological stack, operational and technical maturity, transaction policies and controls, etc.

Therefore, to upgrade a running production environment with transactions which are in-flight and completed to ensure business continuity is at the very heart of upgrade. To achieve this, entire upgrade activity must be planned, streamlined and executed way different from just selecting upgrade option and hitting complete.

Below diagram depicts the various phases and respective components involved during an upgrade project



Now that we understand the methodology and components during upgrade, below are important steps and design considerations to be borne in mind while performing upgrade.

Design Considerations Details
Upgrade pre-requisites and Installation
  • Verify IBM OMS with current Fix Pack in production with all the existing customizations
  • Ensure that the backup of the whole IBM OMS foundation folder and the database are taken before starting the migration process, to rollback in case of any issues
  • Upgrade stack with compatible versions of Database, JDK, Application Server, if applicable
  • Install new version of OMS (vY) in upgrade mode with database details same as the in-production version (vX)
  • Ensure that, after installation, OMS version details are same as old version in the database by querying si_version table.
Impact Analysis
  • XML changes between vX and vY impacting API, templates, user exist, events, agents
  • For deprecated xml attributes/elements, design for change in custom components including user screens (across Application Console, Business Center, Call Center, Store, Field Sales applications) wherever old binding is used in xpath
  • For attributes changed impacting interface messages, re-design the interface. Potentially, if downstream or upstream systems are using these attributes, that is communicated to them for impacts
  • Evaluate any open PMR on vX and validate if they are resolved in vY
  • Verify changes to property files for additions, backward compatibility or behavioral changes
  • Identify performance testing components which are to be performed post upgrade
Source Files Reconciliation
  • Create a new branch for upgrade from the existing Production tag
  • Upgrade could potentially impact existing source code files (java, java script, xsl, jsp, xml, ant) and these source files are to be managed on a separate branch from main trunk until production upgrade is complete. Check-in the source files that were modified as per the impact analysis done into this branch
  • Include any new jars required and ensure build scripts are updated to accommodate these new jars
  • Use this branch for creating a tag and deploying to mock upgrade or other environments for testing
Configuration Deployment Tool(CDT)
  • Authoring system to production (master configuration) should not be upgraded until all tests for upgrade roll out are complete
  • Once testing for upgrade is completed in lower environments-
    1. Master configuration (config) should be upgraded to higher version of application
    2. Manually make upgrade related config changes to master config (based on impact analysis)
    3. Upgrade installation on production environment during downtime
    4. CDT is applied on production from master config
Database
  • Verify schema objects by running dbVerify script
  • Execute database counts on critical transaction tables (before and after upgrade)
  • For config tables, verify configuration by performing CDT diff and apply CDT export/import (if required)
IBM OMS Call Center and Store
  • If existing solution in production is 9.3 or below, plan for moving from RCP (Rich Client Platform) based call center or store application to Web Call Center and Web Store application. The call center and store migration is a critical path of upgrade and may involve significant effort to re-write custom functionality on new user interface (UI) framework
  • Consider number of concurrent users during normal/peak business days and then strategize rolling out features for sub-set of users
IBM Field Sales
  • If existing solution in production is 9.4 or below, plan for moving from Ext JS based UI framework to new Angular framework.
User Enablement
  • Identify business and admin users and plan for end user training with a user manual as help document to enable them to do hassle free regular operations.


The below table articulates the various testing elements which are needed to validate the accuracy of system upgrade:

Regarding point 3 in the above table, downtime is a total composition of elapsed time derived out of multiple sub-elements. Performing mock upgrades is critical to arrive at a better business window for production shutdown towards upgrade.

  • From IBM OMS 93 version, zero down time deployment strategy can be employed to upgrade or migrate to higher versions which strategizes to have two different version of OMS running in parallel at production. Refer below for more details on staged rollout methodology
    https://www.ibm.com/support/knowledgecenter/en/SS6PEW_9.4.0/com.ibm.help.upgrade.stagedrollout.oms.doc/c_Staged_Rollout_Upgrade.html
  • The roll outs to new version will be used by certain small segment of business users to validate the features before larger scale fully blown version is rolled out across enterprise. This will be very useful for persona-based applications like IBM Web Store and IBM OMS Call Center.
  • Design JMS clustering, which provides high availability for systems that require near-zero downtime.
  • For WAS clustering across nodes requiring high availability, use WAS roll out feature to synchronize the update node by node in each cluster
  • Adhere to guidelines from a UI, DB, development and customization perspective as mentioned in product documentation
  • Refer sample process flow for roll back strategy

This article was co-authored by Raghuveer P Nagar.

1 comment on"IBM OMS Upgrade Methodology"

  1. Very well detailed and presented.

Join The Discussion

Your email address will not be published. Required fields are marked *