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: What version of Solr are we using for V9?
Eric: We use Solr v5.3.2 for Commerce V188.8.131.52 until Commerce V184.108.40.206. Starting in Commerce V220.127.116.11, however, we're using Solr v7.3.1.
Q: If I started working with a pre-V18.104.22.168 release already, will I have to make any changes to my configurations/customizations when I move to V22.214.171.124 or later?
Eric: There will be a few changes to make after upgrading to Commerce V126.96.36.199 or later due to Solr code changes and deprecation, which we document in further detail on our Solr 7.3.1 integration Knowledge Center doc:
- Range Query Format
- Default schema field types
- Customized solrconfig.xml parameters
Q: What new and interesting features are we using from this version of Solr?
Zhong Hua: The biggest change we've made was to deprecate SolrSearchMultipleQueryComponent and SolrSearchMultipleFacetComponent, and replace this logic with SolrJoin. To sort and facet on an extension index, we'll use SolrJoin as well as query re-ranking.
Eric: The SearchCatalogEntryExtensionIndexPostprocessor is used to perform a subquery against each extension core, and joins this data back to the main CatalogEntry core's data.
Q: It looks like there is now a scheduler implemented on the Search server, judging by SRCH_SCHSTATUS, SRCH_SCHACTIVE, etc. tables. What kinds of jobs can we schedule on the Search server?
Zhong Hua: Currently, we use the scheduler framework on the Search server for indexprop (from master to repeater).
Eric: We will keep track of each indexprop request within a single "job", which you can track with the jobStatusId returned by the indexprop REST API.
Q: Can I still use BOD-based search in V9?
Eric: Yes, we still have BOD-based search logic in the transaction server. That said, we're not developing any new functionality for BOD-based search so any new search functionality will only be available through REST-based search logic from search server. You should seriously consider following our migration documentation to move from BOD-based Search to REST-based Search to take advantage of many powerful OOB search features (search result grouping, sorting/faceting against extension index, etc).
Q: The old command line preprocess/buildindex is gone in V9, replaced by REST API on the Transaction server. Does that mean that the UpdateSearchIndex scheduled job is gone as well? Also, are there any improvements to logging/auditing available with this new REST API?
Frank: No, UpdateSearchIndex has been replaced by the new REST API as well. The only indexing related process that is still currently performed by a script is parallel processing and distributed indexing (sharding). The REST API also tracks each indexing request as a job (with jobStatusId), which can be checked for it's status through REST API.
Q: If I shutdown my Search docker container, I will lose my container data in memory right? What is the recommended way of storing index data to prevent data loss when shutting down the Search docker container?
Frank: Keeping index files only needs to be configured at master/repeater level, as the subordinate servers will always replicate the index from the repeater on startup. Using the orchestration process discussed in our CI/CD pipeline whitepaper, there are two options you can take:
- Configure the Search server to use local Docker volume for docker-compose.
- Configure the Search server to use a remote storage location (ex. using GlusterFS).
Q: It looks like I shouldn't directly customize wc-data-config.xml and schema.xml in V9. Can you explain how customizations to these Search configuration files now work, and the advantages to the new process?
Frank: We have created x-data-config.xml and x-schema.xml to include extensions that you want to apply to wc-data-config.xml and schema.xml (respectively). This approach allows us to further separate OOB configurations from customizations, allowing you to move between new versions within V9 without having to deal with significant re-merging of your customizations (like you would have to do in V7/V8).
Zhong Hua: If the x-data-config.xml file doesn't provide the level of extendability that you're looking for, you can define a custom data-config file to use instead through SRCHCONF table.
Q: Any new/interesting features that we haven't mentioned yet that people will find useful on V9
Zhong Hua: The SearchCatalogEntryViewPriceRangeQueryPostprocessor can be used to add indexed price ranges of SKUs into search REST response, independent of search result grouping functionality being used. Another feature is the additional functionality added to the search index verification logic (health check). In addition to verifying index contents, there are a few new operations available:
- index backup
- index restore (from a backup)
- index replication
- index synchronization check (master/repeater, or repeater/subordinate)
Eric: The setupSearchIndex utility has been removed as it is now performed as part of Search server container startup, pulling search configurations from SRCHCONF and SRCHCONFEXT tables. This results in your Search server always using the latest version of search index configuration files, rather than having to run setupSearchIndex process manually (and re-merge your customizations into OOB files).
The authors shared the following links to continue learning about the topic: