- Site Search features that impact shoppers’ engagement
Oracle ATG Web Commerce
Support for ATG Versions
Oracle has announced its support options for your specific version of ATG
- Ended in Feb 2019
- Ended in Feb 2019
- Available till Feb 2022
- 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
- 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 3rd 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
Listed below are the high-level areas which typically impact the migration effort
- The extent to which BCC has been customized
- The extent to which CSC has been customized
- The migration effort increases if any Application Server related features have been used. e.g., JMS Messaging, JCA, SMTP etc.
- Migration of Core Commerce components
- JDK and ATG version upgrades
- Upgrading deprecated APIs
- Migration of 3rd party jars
- Migration of SOAP WSDL jars
- Endeca Experience Migration
- As long as the ATG Out of the Box (OOTB) indexing mechanism has been used, the effort involved here is low
Migration Approach
The first step is to usually identify the target environment. Illustrated below is an environment which we usually typically encounter in the migration process:
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 which can modify 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 which have large data can cause potential issues. This is a difficult issue. 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” columns requirements should be eliminated and should be executed only after complete migrations
Pre-Migration Tasks
This section involves the following high-level steps:
- Back up the Oracle Commerce 11.1 database
- Complete all Content Administration projects
- Backup the version file store in the ATG data folder
- CA Server / ATG-Data/Publishing folder
- Storefront / ATG-Data/Publishing Agent
CIM based migration
<- The CIM based migration is performed only once on 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 meta data
- 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
- 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 hot fixes applied in the Oracle Commerce 11.1 application; and 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 cleanup tables which 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)
- 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
The high-level steps in Endeca Migration will be as follows:
- Take a backup of 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 new Endeca application by using the new deployment template
- Incorporate the backup with 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
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 below listed factors are intended to provide a sampling 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 a migration to JDK 1.8.0.251
Deployment in Local Environment
The below listed factors are intended to provide a sampling of the kind of changes inherent in an Oracle ATG migration. They do not constitute an exhaustive list of issues to be considered
- 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 new Endeca APP
- WebLogic 12.2.1.3 configurations, JMS queue
- Setup XM cartridges and template
- Rebuild the ears with latest code base
- Deploy the latest ears with 11.3.2 code base
- Run Baseline Index
Deployment Steps across Environments
- SIT
- UAT
- PROD
Additional Steps
Listed below are specific steps that need to be considered in a migration project
- Take a DB dump from production
- Take a copy of the version file store from 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
- Shut down the servers
- Copy the CORE (Transactional schema) from production
- Execute the migration script on the CORE schema
- Start the servers