Migrating BOD-based Search

Review the following information to understand what architecture and functionality has changed in .

• BOD-base search is discontinued in .
• The server has its own container within your production environment. You deploy your server as part of your CI/CD pipeline.
• The programming model for is changed to coincide with the new build and deployment process in . The basis of the new programming model is to separate custom assets and configuration settings from the product code, which reduces the resource cost of maintenance and operation. The following customizations must be updated for the new programming model:
  • Solr and Lucene runtime are upgraded to 7.3.1, so any customizations to Solr must be updated to follow new programming model.
  • utilities are replaced by the container utility service, which includes di-preprocess, di-buildindex, di-calculateprice, and indexprop. The SetupSearchIndex utility is discontinued. The index core directory is now automatically synchronized with the SRCHCONF table and the SRCHCONFEXT table when the server is started. To create a new master core, extension core, or language you must maintain the SRCHCONF and SRCHCONFEXT tables. The workspace core is created automatically if the server detects that the workspace schema is on an authoring environment.
  • In , the table view is used for preprocessing and index building, so any customizations to preprocessing and index building must be reconfigured according to the new programming guide.
  • In , the common foundation-based scheduler is enabled on the server. Authoring environments use the scheduler to replicate indexes from authoring environments to the repeater.
  • moved to JAX-RS 2.0(JSR-339). Also, the documentation API is Swagger 2.0.
  • Earlier versions of used direct JDBC calls, which went through DSL(data service layer) to the database. In , JPA 2.1 (EclipseLink) native query is used. Custom queries from previous versions are ported over to the new query service. No additional configure is required.
  • In , when Price or Inventory are worked as extended cores, SolrJoin preserves the document relationship between the main CatalogEntry core and the Price/Inventory subcore. MultipleQueryComponent and MultipleFacetComponent, which were used to join or filter the subcores in previous versions, are disabled by default. To handle facet and result fields from extension indexes, a new SearchCatalogEntryExtensionIndexPostprocessor makes a subquery against each of the extension indexes, then joins back with the main index. A new join parameter was also introduced in wc-search.xml, so any previous customization to an extension index needs to be implemented to use SolrJoin.