In this V9 Chats series, we go to the source and interview Commerce experts from the Development, Services and Support teams, who share their insight into the new features and capabilities of WebSphere Commerce V9.
Q: There are many architectural changes in V9. How similar or different is the migration process compared to previous versions of Commerce?
James: Moving from V7 to V8 was similar to adopting a V7 Feature Pack. Moving to V9 and continuing to use the V7 architecture in a backward compatibility mode still requires some technical changes and the adoption of the new software stack and orchestration processes. Moving to V9 and adopting the new remote store architecture requires even more change in order to take full advantage of customization separation with xC.
Q: How much of these changes do I have to adopt when I initially move to V9?
James: This depends on which version of Commerce and which features you are currently using. If you plan to leverage the V9 local store backward compatibility mode, some changes you might need to take are: replacing EJBs with JPA, updating your Session Beans to EJB 3.x, replacing OpenLaszlo with DHTML, adopting the separated WC Search Server, moving from Dojo to jQuery, and so on. There is also the new WebSphere Liberty, Kafka, and Docker solutions and technologies to learn. If you are moving to V9 with full adoption of the remote store architecture and xC customization model, then there's the new xC architecture to learn as well.
Yan Xia: Also, note that BOD search is discontinued (not an option) in V9, so you would need to switch over to REST based Search if you are still using BOD.
Q: How about my Operating System? I currently use one that is not supported in V9. Can I still Migrate over?
Piraveen: The custom assets created on your existing environment are usually independent of the operating system. As a part of migrating over, you will be able to transfer your existing customization to your V9 development environment. You can then perform testing and make any required changes to ensure they meet your requirement, and proceed to deploy on a supported V9 runtime environment.
Q: And my database? What if I am using an older version of DB2 or using Oracle?
Piraveen: For your existing development environment, you need to upgrade your database to the latest supported version (22.214.171.124 or higher FP), or upgrade to version that is within 2 releases of the latest supported version (e.g. 10.1 or 10.5). Then you can proceed to back up and restore the database on to your v9 developer database, which needs to be at 126.96.36.199 or higher FP. For the Production environment, your existing database will become your primary database for your v9 store. As such, you need to make sure it is at least on 188.8.131.52 or higher FP. As for Oracle, testing is ongoing, and upon successful completion, it will become a supported migration path, and details will be provided.
Q: I heard my migrated store is considered a Local store? How is that different from a Remote Store?
Piraveen: When migrating your store, it is stored and run locally on the transaction server (TX), hence the name Local Store. Whereas, stores created directly on the v9 environment run on the remote Stores server (CRS); these stores are referred to as Remote Stores.
Yan Xia: Adding to that, even if you migrated your existing v7 or v8 Store to v9 as deployed in local store model, you can still create new eSite Stores on top of the migrated store, but it can only be working as local store model. The remote store architecture is only applicable to a store designed and created to be ran in remote store model. Also note that Hybrid model (both a Local and Remote store) is not supported.
Q: Why can't I use the Local Store as a Remote store?
Yan Xia: You would need to convert your custom assets to work in a remote store; in other worse, you would need to re-develop your custom applicable assets to Restify them.
Piraveen: Right. The local store runs with the assumption everything will be available in the same JVM, but once the store is moved to a remote Liberty server, you'll typically find that you need to make several adjustments. For example, all the calls to services in the remote store are remote REST call as Yan Xia mentions. But in local store, there are a lot of local calls, including url commands, databeans, taglibs, and BOD services that need to be reworked.
Q: I need to redo 3rd party integrations for this migrated store, like LDAP, third party systems, etc. Do all the integration steps need to be performed again? How about the artifacts that exist from the previous enablement at the v7/8 level?
Piraveen: The steps you will have to take will vary depending on the specific integration. As a part of migrating your custom assets and configuration files over, you will need to keep track of the files that were changed as a part of the integration and determine if they are still needed. When performing integration tasks, most if not all the files will be recreated as most integrations are unaware that it was enabled previously. This process will be largely the same as with migrations on previous versions of Commerce where you would need to perform all the same steps over again, while making sure existing files are still needed, or will be generated/replaced during the integration steps taken.
Yan Xia: Also when taking into consideration changes already made, make sure to note that database records updated during the integration on your existing environment are migrated to v9 with database migration utility.
Q: How do I differentiate between a successful migration followed by needed code changes and a migration that failed, causing unexpected errors?
Piraveen: For each of the migration steps you take, there should be resulting logs generated. Best practice would be to review each log, and any associated console outputs to confirm that the specific task completed successfully. Assuming all tasks completed successfully, then you would need to review the resulting error to see it is an issue with a customization, or an issue with what was provided OOTB.
Q: What is the best way to understand and plan a WC upgrade to V9?
James: Engage IBM Lab Services to inventory your current feature usage and customizations and to talk about your options: V8 or V9; on-premise, WCMH, or IDC; Local Store or Remote Store; set up the new Orchestration solution and process yourself, leverage IBM Cloud Private, or use WCMH DevOps. And if your customizations aren't fully documented for your latest changes, Lab Services can exercise a time-boxed quick migration to help ascertain what challenges may arise during the full migration process.
The authors shared the following links to continue learning about the topic: