This Help Center provides documentation on all aspects of the HCL Commerce+ product, from installation and deployment to operating and customization.
Using Commerce+'s xC programming model, you can use HCL-provided extension points to extend existing Commerce logic. You can implement these extensions with the xC Customization toolkit provided by HCL. Commerce+ also provides Packaged Business Capability integrations that extend the product's reach and functionality.
The topics in the Customizing section describe tasks performed by an application developer to customize Commerce+.
Commerce+ comes with a powerful and fully integrated search function. The search functions in Commerce+ provide an enriched customer experience, with features such as automatic search term suggestions and spelling correction. Since it is built on industry standards, Commerce Search is highly flexible and extensible. Starter stores can use the search engine's most sophisticated features without requiring extra customization. The Commerce Search Elasticsearch microservices manage indexing and other crucial tasks, with no performance impact on the storefront or transaction server.
In keeping with HCL's commitment to current and open standards, Commerce Search uses Apache Lucene as the basis of its Search framework. Lucene powers the Apache Solr search engine and the Elasticsearch search engine. The indexing pipeline is a more open, flexible and scalable and is tightly integrated with the data service. Using the underlying dataflow technology and architecture, you can easily customize the pipelines. This open-standards approach considerably eases the process of integrating Search with existing and third-party applications.
Commerce Search contains extension points that can be used for customization. If you are migrating from a previous version of the product, there are mandatory and optional areas to work with, depending on your existing customizations. In the following topics the available customization points are described, and you are given detailed instructions on customizing each.
The Commerce Search index life cycle provides numerous extension points. There are eight main stages to the life cycle, and each of these comes with its own extension opportunities. Your primary tool for customization is the configuration files that control the indexing process. Beyond configuration, you can build and integrate your own custom code.
The base index schema can be extended to suit your business needs. For example, to separate data into different indexes that are based on their refresh intervals.
You can customize several areas of the search run time.
Welcome to the HCL Commerce+ overview. Explore these feature overviews to learn how Commerce+ operates. Refer to the related links listed at the end of each topic to access expanded product documentation.
This section provides details on deploying HCL Commerce+. It explains how to download the Docker images and Git bundles that comprise the product, how to create a minimal environment, and how to plan for a full deployment. It details supported software versions, patches, and configurations to ensure the platform performs well.
The following topics show how to migrate an existing HCL Commerce Version 9.1 environment to Commerce+. The process consists of an initial migration of your database contents. This is followed by a code migration. Both are fully described.
The topics in this section focus on tasks that are performed by business users, marketers, and customer support representatives to connect with partners and attract and satisfy customers.
The site administrator performs the tasks needed to support day to day operations of the Commerce+ site.
Commerce+ Search uses a number of specialized terms. A concise list of the most commonly used terms is provided to get you started.
The topics in this section describe tasks performed by an application developer to customize the Elasticsearch-based search solution. You can extend the search-migration/tutorials/concepts/csdelasticsearch.html and Query Service to meet your business requirements.
The product Search server runs in its own Linux-based container. The containers use Docker technology. All servers share workspaces in the Windows-based development environment, simplifying the development process. After you develop and test your code in the workspace, you can deploy it in new containers.
When working with Commerce Search APIs, it is important to understand how URI paths and query parameters are encoded. Proper encoding ensures that requests are interpreted correctly by the server and that special characters are handled consistently across systems. Incorrect and inconsistent encoding can lead to unexpected search results, misinterpreted query parameters, or request errors, especially when working with accented characters.
Commerce Search includes several key services and interaction areas, including the search interface, programming model, and its interactions with other Commerce components.
Commerce Search is configured using several files. These files contains properties that control certain search features, and can be extended to meet your business requirements.
Adding new fields into the index schema requires modifying the x-schema.xml file to add the new index field. Typically, an existing index is updated to add new fields (local index). In other instances, it is recommended to extend the product index by creating an index as an extension of an existing index (extension index).
The Search index is set up automatically during Search server startup. Search cores are created according to the configuration settings defined in the SRCHCONF and SRCHCONFEXT database tables. You can customize these tables to control the creation of search index cores.
The indexing process requires mapping data from an external source (database or file) to index fields to create index records or index documents. Depending on the complexity of the source data and index schema design, preprocessing the data might be required. Otherwise, indexing can be directly performed by using either the Data Import Handler (DIH) to index data from the database, or Solr APIs to index data from a file.
An expression provider implements custom business logic for modifying the main search expression before it is sent to the search engine. Each expression provider can be separately registered to any search profile query section so that it can be reused for other search operations. That is, a search profile defines a list of search providers that are used for assembling the main expression for a search request.
You can add native Solr query parameters to each search profile's query parameter section to enhance and customize the final Solr query.
You can disable certain expression providers and result filters in the Commerce+ search configuration file (wc-search.xml). Doing so optimizes the storefront flow and improves the overall response time for certain types of Commerce Search scenarios.
A query preprocessor modifies the native SolrQuery object right before it is sent to the Solr server for processing.
SolrQuery
A query postprocessor creates and modifies a search response immediately after the QueryResponse is returned from the Solr server.
QueryResponse
You can add custom index fields to be returned in REST responses by updating the wc-component.xml file.
Commerce Search uses search profiles to control the storefront search experience at a page-level. Search profiles group search runtime parameters (search index name, search index fields, expression providers and result filters, paging and sorting), and search feature configurations (text highlight, facets, and spelling correction). Search profiles are defined in the Commerce Search configuration file, wc-search.xml.
You must customize Commerce Search when you are adding new indexed catalog entry properties to search rule actions or targets.
You can customize Commerce Search in the storefront to suit your business needs. You can customize Commerce Search according to your role within the WebSphere Commerce site.
You can use navigation rules to sort products in a category via a specific criterion such as price.
You can customize components of the final Solr query by using query parsers. A query parser is a component responsible for parsing the textual query and converting it into corresponding Lucene Query objects.
Search term associations are used to suggest more, different, or replacement products in search results. Search term associations can also link search terms to a selected landing page in the store. Business users create and manage search term associations in the Management Center by using the Catalogs tool.
The following limitations exist in Commerce Search.
The search runtime, REST services, and search components are all customizable.
Search relevancy and merchandising is the process of controlling the search results that are returned to shoppers in the storefront, and the order in which they appear. There are several techniques that can be used to influence search relevancy, which lets you return products in the order that best suits your business needs.
Commerce+ service includes access to an externalized customization server that runs your custom Connectors and any functional extensions you may write. The xC service uses an Open Liberty server on OpenJDK, with webapplications executed via Spring Boot 3.x for development.
Commerce+ offers customizable features for storefronts using the Next.js framework. Commerce+ supports headless commerce to use any front end storefront.
These topics describe the security features of Commerce+ and how to configure these features.
Topics in the Performance section describe the means by which to plan, implement, test, and re-visit the optimization of Commerce+ site performance.
Topics in the Troubleshooting section highlight common issues that are encountered with Commerce+, and how they can be addressed or mitigated.
Topics in the Reference section contain all of the Commerce+ reference documentation.