A Journey into the HCL Commerce Search Service, Focusing on Elasticsearch

Introduction:

In this blog post, we focus on the HCL Commerce Search Service and specifically highlight Elasticsearch, an integral component of this service. Additionally, many recognize Elasticsearch, a powerful and flexible search engine, for its scalability and performance. Furthermore, when it comes to e-commerce platforms like HCL Commerce, providing a seamless search experience is crucial for driving user engagement and conversion rates. This is where Elasticsearch comes into play, offering advanced search capabilities that enable customers to find products quickly and easily. Notably, in Version 9.1, the default search solution for React-based storefronts is Elasticsearch, while the Solr architecture is not intended for their implementation. For a comprehensive understanding, you can explore further details on this topic.

Advantages:

One of the key advantages of using Elasticsearch within the HCL Commerce Search Service is its efficient handling of large volumes of data. Moreover, Elasticsearch utilizes a distributed architecture, enabling the horizontal scaling of search capabilities across multiple nodes. As a result, it can efficiently process and index massive amounts of product data, ensuring real-time delivery of search results.

Another notable feature of Elasticsearch is its relevance and ranking algorithms. In fact, Elasticsearch employs sophisticated techniques to determine the most relevant search results based on factors like customer preferences, popularity, and relevance to the search query. This enhances the overall search experience, enabling users to find what they are looking for with greater accuracy. Moreover, Elasticsearch supports various search functionalities, such as full-text search, faceted search, and geographical search. These capabilities empower merchants to implement complex search scenarios that cater to the diverse needs of their customers. Whether it’s filtering products by attributes, refining search results based on location, or implementing autosuggestions, Elasticsearch provides the tools to accomplish these tasks effectively.

In addition to its search capabilities, Elasticsearch seamlessly integrates with other components of the HCL Commerce platform. Moreover, it can leverage product information, catalog data, and customer insights to further enhance the search experience. By combining search results with personalized recommendations and intelligent merchandising, merchants can create a truly personalized and engaging shopping journey for their customers.

Features:

The Solr functions as a traditional monolithic application within a dedicated Search container, ensuring stability and scalability. In contrast, HCL Commerce Search, which integrates with Elasticsearch, comprises a set of Data microservices, each operating within its container. Furthermore, these microservices have specific responsibilities, maintaining compatibility with your Commerce Transaction server, storefront, and Xc customizations. Importantly, they provide the following features:

1. The HCL Commerce Search service utilizes Stanford CoreNLP to power Natural Language Processing (NLP) capabilities. Its language models, including English, Spanish, French, German, Arabic, and Chinese, enhance search relevance.
2. The CoreNLP language models offer comprehensive functionalities, encompassing tokenization, lemmatization, part-of-speech tagging, name-entity recognition, sentence splitting, sentiment analysis, grammatical analysis with constituency and dependency parsing, as well as coreference.
3. An additional NLP processor enhances Matchmaking capabilities by facilitating the discovery of similar colors or measurements and enabling automatic measurement conversion.
4. Elasticsearch serves as the default core search technology, seamlessly integrating within the system.
5. The system provides over 30 built-in language-specific analyzers, enhancing multilingual support for text analysis, including tokenization, stemming, and stop words.
6. Dynamic index shards allow for the dynamic addition of nodes and automatic data rebalancing across the cluster, ensuring uninterrupted operations.
7. Hot swapping of newly built indexes is achievable using index aliases, minimizing the impact on the live index cluster.
8. Fast incremental snapshots enable frequent backups.
9. Data ingestion is facilitated through indexing pipelines in Apache NiFi.
10. The HCL Commerce Search service robustly supports multitier marketing and ensures near-real-time updates.
11. The deployment interface is Kubernetes-ready, streamlining the deployment process.
12. Service upgrades and version control are seamless, enabling continuous delivery of new features and bug fixes through recurring service packs.
13. The Docker container stack that hosts the microservices is based on CentOS and utilizes the Spring Boot framework.

Architecture:

The provided diagram illustrates the architecture of HCL Commerce Search. Additionally, in Version 9.0, the main box consolidated the microservices within the monolithic Search container. However, in the current version, the services have been modularized and operate independently, communicating through the Data Environment.

Choosing a Global Software Development Partner to Accelerate Your Digital Strategy

To be successful and outpace the competition, you need a software development partner that excels in exactly the type of digital projects you are now faced with accelerating, and in the most cost effective and optimized way possible.

Get the Guide

The components of HCL Commerce Search comprise:

• The Ingest service: This microservice oversees write operations and handles crucial Extraction, Transformation, and Loading (ETL) tasks on business data, making them accessible to the search index. Previously, the Transaction server housed the business logic of the indexing lifecycle, but now it is managed within the Ingest service.
• The Ingest service utilizes an indexing pipeline that operates on Apache NiFi. It employs customizable connectors, allowing complete control over data indexing without the need to write any code. Each connector functions as a processor, manipulating the data as it moves through the pipeline. By combining various connectors, you can achieve different types of indexing pipeline logic.
• Each environment (e.g., Authoring and Live) shares one NiFi cluster, consisting of multiple NiFi nodes.
• To enhance the standard, ingest data flow, you have two options: either develop a new connector or make modifications to an existing connector.

The Query service:

It is responsible for constructing search expressions and passing them to Elasticsearch. Additionally, it takes the query results and converts them into a format usable by the storefront. Notably, the storefront does not need to be aware whether the response came from Elasticsearch or Solr, thanks to the translation done by the Query service.

Apache NiFi:

It serves as the indexing pipeline utilized by the Ingest service. Moreover, it employs connectors to ingest raw data and convert it into a format compatible with Elasticsearch. NiFi provides default connectors for known data types; however, you can define custom connectors to handle specialized data types. Additionally, NiFi operates in its own container and offers full extensibility.

Elasticsearch:

In conjunction with the Query service and search profile, Elasticsearch efficiently handles search queries. It utilizes its high-performance engine to execute searches and filters the response through the search profile before returning it to the storefront. This approach ensures that the storefront can seamlessly interact with Elasticsearch or Solr without requiring any specific knowledge of which search engine is being used. Furthermore, the Elasticsearch index allows building as a separate persistent volume, and its distributed index paradigm enables continuous updates even if other Docker containers are taken down. Additionally, internally, the Data Platform does not directly expose certain services to the outside world, and access to them is facilitated through the NGINX gateway.

Redis:

Redis serves as the message bus for distributing change events and cache invalidation events.

ZooKeeper:

It is utilized to store default and custom configurations, connector descriptors, custom properties, and extensions. Each microservice, upon starting, follows a preset, stable configuration, and at runtime, it polls ZooKeeper for any custom configurations, allowing it to adapt behaviors and incorporate custom applications. To learn more about customization options, refer to the documentation on Configuring Query services in ZooKeeper.

For deployment, preconfigured helm charts are available with Version 9.1, providing a complete search stack. By editing these helm charts, you can deploy a tailored system using Kubernetes that aligns with your specific business requirements.

Conclusion:

In HCL Commerce Version 9.1, Elasticsearch is a vital component of the HCL Commerce Search Service, enabling fast, relevant, and scalable search capabilities. Moreover, its robust features and seamless integration with other platform components make it an invaluable tool for merchants striving to provide an exceptional search experience for their customers. With Elasticsearch, HCL Commerce empowers businesses to enhance user engagement, drive conversions, and stay ahead in the competitive e-commerce landscape.

Reference:

https://help.hcltechsw.com/commerce/9.1.0/search/concepts/csdsearchingest.html