HCL Commerce Version 9.1.18.0

Upgrading Solr version 7.3.0 to 9.7.0

HCL Commerce version 9.1.18 introduces a new Solr-based Search runtime built on Solr 9.7. Transitioning to this version impacts index compatibility and requires planning to ensure a smooth cut-over, particularly in live production environments. The following considerations should be reviewed before initiating the upgrade.

Once you have reviewed this information, use the steps described in HCL Commerce production update overview to perform the upgrade.

Note: The 9.1.18 Commerce Solr-based Search upgrade is a significant update. By default, the 9.1.18 Commerce Solr-based Search solution is configured to work with the existing Solr 7.3 runtime provided in version 9.1.17. Upgrading to the 9.1.18 Solr-based Search Query container runtime is optional but recommended to take full advantage of the latest improvements. The 9.1.18 release will work with a 9.1.17 Solr-based Search Query container runtime. If you require this hybrid configuration and are using an Oracle database, open a case with HCL Customer Support to request patch HC-60507 to enable this configuration setup.

Benefits

The upgrade from Apache Solr 7.3 to 9.7 improves the stability, performance, and security of HCL Commerce Search.
Improved Search Performance and Stability
Solr 9.7 includes significant performance enhancements and stability improvements over version 7.3. You can expect faster, more reliable search results with reduced chances of memory or storage-related errors, especially those previously caused by legacy Solr behavior.
Enhanced Security
Upgrading to Solr 9.7 ensures you are protected against known vulnerabilities present in older versions. This improves the application's security posture and reduces potential risk exposure, providing peace of mind for security-conscious organizations.
Reduced Operational Overhead
The upgrade positions the system on a more modern and maintainable stack, enabling proactive support and smoother upgrade paths. This foundation allows for timely security fixes and better issue management through formal support channels, ultimately reducing operational overhead and minimizing disruptions for administrators and end users.

What is unchanged

  • HCL Commerce Developer Search environment: No change to HCL Commerce Developer Search environment - the embedded Search test server environment remains at Solr 7.3 / Java 8.
  • Solr Search Architecture: The overall Solr Search architecture remains unchanged.
  • Existing Solr Upgrade Procedures: No changes have been made to existing Solr upgrade procedures.
  • Search Customization Programming Model:The customization programming model remains the same, as detailed in the documentation.
  • Configuration File Format: The configuration file format remains the same and is compatible with existing supported Search customizations.
  • Deployment Steps: The deployment steps for customizations remain unchanged.
  • Workspace:Workspace behavior remains the same.
  • Search-related Default Configurations: Fully compatible between old and new Solr:
    • Search profile and runtime configurations.
      • wc-rest-resourceconfig.xml
      • wc-component.xml
      • wc-search.xml
      • wc-query.tpl
    • Search indexing configurations.
      • pre-processor
      • data-import-handler (DIH)
      • index-load

What has changed

Runtime and Libraries
  • The Solr runtime has been upgraded from version 7.3.1 to 9.7.0.
  • The Lucene library is upgraded from version 7.3.1 to 9.11.1.
  • Solr-based Search now runs on Java 17 using the Open Liberty application server, replacing Java 8 with IBM Liberty. Java 17 is installed in /opt/java/openjdk folder.
  • The Run engine command is switched to open liberty from IBM liberty.
Encryption Algorithm Update
The encryption algorithm for user activity cookies has been modified from SHA2DRBG (a proprietary IBM algorithm) to SHA1PRNG (a JCE provider) due to OpenJDK 17's lack of support for SHA2DRBG. The Solr Query service (and remote stores) utilizes AES128Cryptx for decryption and validation of the Commerce user activity cookie. The underlying Jewel code (AES128Cryptx) employs an IBM proprietary SecureRandom provider, SHA2DRBG, which is unavailable in OpenJDK 17.
  • The system property com.hcl.commerce.software.stack, used in multiple locations in the Transaction server (ts-app) to determine the algorithm, can be set to "ibm" for SHA2DRBG and "open" for SHA1PRNG.
  • A new system property, com.hcl.commerce.software.stack.encryption, with values "open" or "IBM" has been introduced in ts-app to specify the algorithm for the AES128Cryptx class.
  • All three service applications, ts-app, CRS, and Solr, must use the same encryption and decryption algorithm.
  • Given that Solr and Elasticsearch are now running on OpenJDK 17, ts-app can enable this setting by default in version 9.1.18.
Schema
In the new version, the FieldTypes and Fields definitions must now be declared in a single XML file, as Inheritance via dynamic include (<x-include>) is no longer supported. To incorporate these alterations while preserving operational continuity, a preprocessor consolidates this into ‘solr-schema.xml’ at server startup. The generated file, solr-schema.xml, will be used exclusively by the Solr runtime for all index schema related definitions.

solr-schema.xml is situated in the same directory as the schema.xml file for each core. Manual modification of solr-schema.xml is discouraged, because any changes made to it will be overwritten upon server restart.

Existing custom schema definitions remain unaffected and can continue to utilize x-schema.xml.

The version must remain at 1.5 to preserve schema compatibility, although Solr 9.7 can support up to version 1.7.

solrconfig.xml
The solrconfig.xml requires special handling at build time to preserve customer-facing compatibility. This will be handled at build time, and you should not make any changes in this file.
Open Liberty Installation Location
The installation location and default profile name for OpenLiberty are different from WebSphere Liberty. Symbolic links have been created to preserve compatibility.
Impact on Business Users
  • Business users should see minimal changes in the search functionality and experience.
  • There may be a brief period after the upgrade when existing browser cookies are invalidated, potentially causing session loss for some shoppers.

What is no longer supported

  • The following HCL Commerce Solr extensions have been removed in this release:
    • SolrSearchMultipleQueryComponent
    • SolrSearchMultipleFacetComponent
    • NewSearcherNotifyOnChangeListener
    • SearchExternalFileFieldReloader
    If your implementation relies on these components, please contact HCL Support for guidance on alternative approaches.
  • <x-include> inheritance in schema files is no longer supported.
  • Lucene index data segments are not backward compatible. Indexes must be pre-built before cutting over to live production.
  • Trie data types are deprecated and will no longer be supported in future Solr versions.

Customization Considerations

Existing customizations should largely continue to work without modification. However, it is crucial to test all customizations thoroughly in the new environment. solrconfig.xml and schema.xml customizations require special handling. See "Schema" section above for more details. After upgrading to the 9.1.18 Solr-based Search Query container runtime, search customization can continue to be developed and tested with the 9.1.18 Commerce Toolkit. The new 9.1.18 Solr-based runtime is capable of using Java 8-built custom extensions created from the Commerce Toolkit. The customization programming model itself has not changed, so developers can continue to use existing practices.