ATG Upgrade

Upendra Chivukula01/22/2021

ATG Upgrade

Blog Category :ATGPublished on: 22 January 2021
Blog Image
Author : Upendra Chivukula Email : chivukula@aienterprise.com

Oracle ATG Web Commerce

Introduction

Most retailers who are not on the latest version of Oracle ATG Commerce have to consider upgrading to the latest version. However, the upgrade process is not trivial and requires a strong understanding of the infrastructure, configurations, and ability to solve edge case scenarios. We pride ourselves on having one of the best teams worldwide who have the experience of helping enterprise customers move to the latest platform version.

This article is for folks familiar with the Oracle ATG platform so that they can appreciate the high-level upgrade process.

Support for ATG Versions

Oracle has announced its support options for your specific version of ATG.

 

Oracle ATG v10.x

Oracle ATG v11.1 - v11.2

Oracle ATG V11.3.2

Premier Support

  • Ended in Dec 2015

 

  • Ended in Feb 2019

 

  • Available till Feb 2022

 

Extended Support

  • Ended in Dec 2018

 

  • Support available only for the terminal patch set releases of Oracle Commerce Platform/CSC 11.2.0.3 and Oracle Commerce Guided Search 11.2

 

  • Available till April 2025

 

Sustaining Support

  • Access available to service requests, knowledge articles, documentation, & approved fixes
  • Oracle will not provide new fixes
  • Support is provided with no guarantee of problem resolution

 

  • No end date

 

All customers are entitled to lifetime Sustaining Support per Oracle's Lifetime Support Policies. Under Sustaining Support, customers are entitled to open service requests and access any knowledge articles, documentation, and approved fixes. But Oracle will no longer provide new fixes or update third party certifications. All Sustaining Support is done on a "reasonable efforts" basis with no guarantee of problem resolution. Customers maintain the right to upgrade if they are current on their support and maintenance contract.

Retailers who want to continue their investment can consider upgrading to the latest version.

Effort involved in the Migration

The high-level areas which typically impact the migration effort are listed below.

  1. The extent to which BCC has been customized.
  2. The extent to which CSC has been customized.
  3. The migration effort increases if any Application Server related features are used. For example JMS Messaging, JCA, SMTP, etc.
  4. Migration of Core Commerce components.
    • JDK and ATG version upgrades.
    • Upgrading deprecated APIs.
    • Migration of 3rd party jars.
    • Migration of SOAP WSDL jars.
  5. Endeca Experience Migration.
    • As long as the ATG Out of the Box (OOTB) indexing mechanism is used, the effort involved here is low.

Migration Approach

The first step usually is to identify the target environment. Illustrated below is an environment which we typically encounter in the migration process.

Application Server

Web logic 12c

ATG

11.3.2

Database

Oracle 12c

OS

Win 10 for Development, Red Hat Linux 6.7

JDBC Driver

Ojdbc8.jar

JDK

JDK 1.8.0_251 (64 bit)

MDEX

Oracle Commerce MDEX Engine Release 11.3.2

Tools and framework

Oracle Commerce Tools and Frameworks Release 11.3.2

Guided search

Oracle Commerce Guided Search Platform Services Release 11.3.2

Content Acquisition System

Oracle Commerce Content Acquisition System Release 11.3.2 (CAS)

 

Database

Special attention must be given to Database DDLs, DMLs, and indexes during the migration.

  • Modify DDLs which can potentially create read/write lock on tables.
  • DMLs that can modify a large number of records in a table can potentially create locks. Modify such scripts to apply changes in small chunks using stored procedures.
  • Creating Indexes on existing columns that have large data can cause potential issues. Even though Oracle 11 has “ONLINE” and “PARALLEL index build processes, we need to avoid such activities especially on the “Order” or “Profile” tables, and low traffic periods or alternate options should be identified.
  • “Drop” column requirements should be eliminated and should be executed only after complete migrations.

Pre-Migration Tasks

The pre-migration tasks help us to prepare for migration and carry out operation with ease, eliminating risk of failures and plan for remediation.

  • Back up the Oracle Commerce 11.1 database.
  • Complete all Content Administration projects.
  • Back up the version file store in the ATG data folder.
    • CA Server / ATG-Data/Publishing folder.
    • Storefront / ATG-Data/Publishing Agent.

CIM based migration

The Configuration and Installation Manager (CIM) Migration Tool automates schema and data migration based on your current installation. The steps involved are as follows:

  • The CIM based migration is performed only once on a local dev environment, to collect and consolidate SQL Scripts.
  • Once this is done, new schemas can be created for Oracle Commerce 11.3.2 and existing tables and data can be imported.
  • Data should be imported for PUB and CORE only.
  • For Switching Schemas (CATA and CATB), import metadata.
  • Table data will be pushed into CATA and CATB when a full deployment is done from BCC.
  • At the end of the CIM based migration, consolidate the SQL scripts per schema and create the shell scripts to execute the SQL scripts.

Commerce and Merchandising

To migrate Oracle ATG Web Commerce and Merchandising to Oracle Commerce Platform 11.3.2, one performs the following steps:

  • Create new schemas for Oracle Commerce 11.3.2 and import the existing tables and data\
  • Execute the migration scripts
    • db_migration_core.sh
    • db_migration_switching.sh
    • db_migration_pub.sh
    • db_migration_agent.sh
  • After the execution of the DB migration scripts and full deployment, create the replicas of CORE, CATA, CATB for staging.
  • Update the JDK to 1.8.0_251 reference in the environments (eclipse, build, environment variables).
  • Install Web logic 12c (12.2.1.3) and configure the data sources and JNDI.
  • Update the reference to Oracle Commerce 11.3.2 in the environments.
  • Identify the hotfixes applied in the Oracle Commerce 11.1 application. Remove if it has been fixed in the newer version (Oracle Commerce 11.3.2).
  • Replace Commerce Reference store 11.3.2 with Commerce Reference store 10.1.2.
  • Fix the deprecated API (ATG/JDK) errors.
  • Update the WebLogic.
  • Update / Add ojdbc8.jar to the lib folder and configure the same in the classpath.
  • Execute the following script to clean up tables that are no longer used in the newer version. This contains tables related to ATG search which are no longer applicable. However, data in these tables should be reviewed in each of the environments before running this.
    • script.db_cleanup_core.sql
    • db_cleanup_pub.sql
    • db_cleanup_switching.sql
    • db_cleanup_agent.sql
  • Build and create the CA, Store and AUX ears.
  • Update the deployment topology and agents in BCC to point to the new environment.
  • Test the upgraded application and verify all functionalities including integration (Web and Mobile).

CSC (Commerce Service Centre)

To migrate the CSC module to Oracle Commerce Platform 11.3.2, one performs the following steps:

  • Create new schemas for Oracle Commerce 11.3.2 and import the existing tables and data from the AGENT schema.
  • Execute DB migration scripts.

Endeca App Migration

To migrate the Endeca module to Oracle Commerce Platform 11.3.2, one performs the following steps:

The high-level steps in Endeca Migration will be as follows:

  • Take a backup of the Endeca application and services (version 11.1).
    • Back up/Exporting Workbench users from Tools and Frameworks.
    • Back up the Workbench configuration files.
    • Back up application content from Workbench.
    • Back up CAS configuration and CAS index configuration.
    • Back up Endeca Script Files.
  • Create a new Endeca application by using the new deployment template.
  • Incorporate the backup with the newly created Endeca application and services (11.3.2 version).
    • Restore CAS configuration.
    • Initialize the Endeca application.
    • Import Workbench users to Tools and Frameworks.
    • Restore CAS Index configuration.
    • Restore script files.
    • Migrate application content to Workbench.
  • Address all Endeca application and scripts issues.
  • Validate and fix API response issues.

Custom changes to be handled as part of Development Phase

  • Commerce Custom Code Changes.
  • CA/Merchandising Custom Code Changes.
  • CSC Custom Code Changes.

Planning the Migration

Listed below are the high-level aspects that must be factored into a migration project plan.

Planning migration

In addition to these, there are many more steps that need to be considered to ensure that one has a holistic project plan in place.

Specific Activities

The following factors provide a sample of the kind of changes inherent in an Oracle ATG migration. They do not constitute an exhaustive list of issues to be considered.

  • Changes/updates to JSP Tab Libraries.
  • Changes/updates to external / third party jars used in the application.
  • Changes to deprecated methods.
  • Changes to database related changes.
  • Updates to configuration/build scripts to support web logic 12c.
  • Potential changes due to migration to JDK 1.8.0.251.

Deployment in Local Environment

  • Installation of 11.3.2 software stack on local server.
  • Take a DB dump from SIT.
  • Take a copy of the version file store from SIT.
  • Import database dump (mask the customer data) and copy the version file store.
  • Execute migration steps as described in the document per section 2.1.7.
  • Update build.xml For WebLogic.
  • Build the EAR with ATG 11.3.2 and JDK 1.8.0_251 and make necessary changes in the code to make it compatible with ATG 11.3.2.
  • Deploy the latest ears and resolve issues if any.
  • Create a new Endeca APP.
  • WebLogic 12.2.1.3 configurations, JMS queue.
  • Setup XM cartridges and template.
  • Rebuild the ears with the latest codebase.
  • Deploy the latest ears with 11.3.2 codebase.
  • Run Baseline Index.

 

Deployment Steps across Environments

The above steps need to be repeated across the below environments:

  • SIT
  • UAT
  • PROD

 

Additional Steps

Listed below are specific steps that need to be considered in a migration project.

#

Task description

1

Procure additional hardware required for production.

2

Install a newer version of the software stack.

3

Prepare the environment (Network setup, router configuration, Apache setup, ATGDB tool setup, create domains/server instances for Web logic).

4

Take a DB dump from production.

5

Take a copy of the version file store from the production.

6

Import database dump and copy the version file store.

7

Execute migration scripts.

8

Deploy the latest ears.

9

Setup the XM cartridges and template, and do a baseline update.

10

Verification, Smoke Testing.

11

Performance testing / Penetration / Security testing..

12

Refresh with new data from production and re-configure.

  • Take a DB dump from production.
  • Take a copy of the version file store from the production.
  • Import database and copy the version file store.
  • Execute migration steps.
  • Deploy the latest ears.
  • Do a BCC full deployment if required.
  • Do a Baseline update for Endeca indexing.

13

Do a final build. Verification, Smoke Testing.

14

Cutover and Go-Live.

  • Shut down the servers
  • Copy the CORE (Transactional schema) from the production.
  • Execute the migration script on the CORE schema.
  • Start the servers.

15

Have a rollback strategy ready.

 

Conclusion

In case you have decided to upgrade then we will be happy to assist you. We have the experience across all the required aspects and would be able to guide you through the process.

 

About the Author

Upendra Chivukula

As Vice President, Global Delivery, and a key member of the leadership team, I am responsible for developing and managing the overall service delivery strategy for AIEnterprise's (AIE) business. I have served in various leadership roles focusing on building global practices and teams responsible towards delivering successful eCommerce implementations. I have a successful history of moving back and forth between roles managing teams up to 1500+ people and as an individual contributor. I find myself energized by enabling others, clearing obstacles, finding innovative solutions, and being a part of a team with a common goal.

Areas of Excellence include Customer Success, Portfolio and Delivery Management, Project Management, Partner Relationship Management, P&L, Revenue Forecast and Generation, Building and Leading Global Technology Teams, Talent Acquisition, Development, and Retention.

Special Focus Area include Delivery Led Sales, Sales Enablement, Practice Leadership, eCommerce Platforms, Frameworks and Solutions, related areas like Cloud, Data Science, Front End Technologies, Automation, Testing amongst others