This Help Center provides documentation on all aspects of the HCL Commerce+ product, from installation and deployment to operating and customization.
The site administrator performs the tasks needed to support day to day operations of the Commerce+ site.
HCL Commerce+ Search provides the core search capability for Commerce+, enabling product indexing and retrieval for customer queries across the storefront. It supports guided navigation, landing pages, and dynamic merchandising, helping shoppers quickly find relevant products while giving merchandisers tools to influence search results.
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.
The Solr search index lifecycle includes tasks that you perform after Commerce+ search is deployed. For example, building, replicating and propagating the search index, backing up and restoring the search index, and monitoring indexing activities across different search servers.
The following topics describe how to apply patches received from Commerce+ to NiFi.
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.
A member group is a grouping of members - users, organizations, or other member groups - used for various business purposes. Two kinds of member groups exist: implicit and explicit. An implicit member group contains users that share common attributes and are therefore considered members of a specific member group. An implicit member group specifies criteria or attributes that users must satisfy in order to be considered members of that member group. You can also explicitly exclude certain users although they satisfy the criteria. An explicit member group contains explicitly assigned users, who may or may not share common attributes. A member group can be both implicit and explicit at the same time.
Use the HCL Commerce+ Inventory to manage your inventory and access your Inventory Locations (ILs), where your inventory is physically stored and is delivered or shipped from.
Accurate, secure transactions require that a second individual approve some electronic marketplace actions before they proceed. This individual, called an approver, can accept or reject requests to perform a specific action. During the organization registration process, the organization administrator selects the business processes for which they want to enable approval. This is done by signing up for the appropriate approval member group during membership registration. The organization administrator also populates the approver member groups. Only users within these groups have the authority to accept or reject requests to perform those actions for which approval has been enabled.
Commerce Lab allows you to manage transport, messages, scheduler, Connectors, registries, and security policies.
An Commerce+ staging environment is a runtime environment where business and technical users can update and manage store data and preview changes. The changes can then be propagated to the production environment.
Workspaces provide a powerful and flexible way to manage and preview changes to your e-commerce website without affecting the live production environment.
As a site administrator, maintain the Commerce+ database and ensure that any Commerce+ utilities and processes that load and retrieve data from the database is configured to connect to the database properly.
Commerce+ provides utilities for preparing and loading data into a Commerce+ database. The loading utilities are flexible and you can continue to use these utilities when you customize the Commerce+ schema.
Discover how Search enables catalog browsing indexing, and product discovery across Commerce+ storefronts while preserving core legacy configurations during migration.
Commerce Search includes a data ingest component and the powerful indexing and query services of the Elastic engine.Commerce+ PBCs are SaaS services. In day to day operations they function like internal components of Commerce, but when a PBC is upgraded, its improvements become instantly available to Commerce+.
The Solr and Elasticsearch systems behave similarly at the storefront level. Behind that layer are key differences in architecture.
Apache Solr and Elasticsearch have different approaches to updating your search index. Solr does delta updates on a regular schedule, usually every five minutes. Elasticsearch performs an incremental update in near real-time.
There are impacts to the search index when certain business tasks are performed. This topic describes the Solr and Elasticsearch comparison for the common business tasks and their impact on the search index. The following table lists the common business tasks and reindexing types for Solr and Elasticsearch. The table groups business tasks and reindexing types by business components.
The following table describes the Solr-based and Elasticsearch-based search solutions and their concepts. A guideline is also presented for migrating from the Solr-based search solution to the newer Elasticsearch-based solution.
The Orchestration service enables the Ruby starter store to use Solr-based search. The Ruby store uses the V2 search REST API that is only compatible with Elasticsearch. With the Orchestration service, the ability to convert a JSON message from one format into another is introduced.
The Commerce+ introduces a new service for inputting and organizing your data. This new version of Commerce Search is a generic data management system that can be used by other Commerce subsystems, including but not limited to the Elasticsearch engine. Along with the Ingest service that brings in the data, the new Query service provides natural language processing, color recognition and more. For customers who need backwards-compatibility, the previous Apache Solr-based search solution is still available.
Populating and building the search index data includes the following tasks: building the search index, indexing site content, propagating the search index with the repeater, and setting up cache invalidation in the storefront.
Complete the following steps to apply a class patch to NiFi.
Several tasks help you backup and restore the Commerce Search index, depending on your business needs.
Business users work on catalog-related changes in an isolated environment when you work with workspaces in Commerce Search. They can then preview their changes in the storefront before you submit them for approval. Content approvers or workspace managers then use the Workspace Management tool in the Management Center to preview a workspace, undo submitted tasks, reject, cancel, or approve task groups. A task group is scheduled for publishing after it is approved.
Commerce+ provides a rich set of Search tools to use with product variants. Once you have enabled Search for variants, a number of usage scenarios become possible. Those scenarios are described in the following topics.
User sessions are synchronized between the Commerce+ and Commerce+ search servers.
The Commerce Search index is locked at certain points during the indexing lifecycle. For example, when running the search utilities or scheduler jobs.
You can debug Commerce Search by directly accessing Solr functions by using a web browser, without using Commerce+ run time or utilities.
You can enable tracing and logging to help troubleshoot Commerce Search after deployment.
Commerce+ maintains a detailed set of logs related to a variety of processes and functions. These logs are available upon request.
Each time that a command triggers a business event, a record is added to the BUSEVENT database table to persist data from the event. Event listeners and external systems (such as the Marketing component, a back end order management system, or an external analytics system) can use this data to perform further processing.
Applying limits on business operations reduces the risk of system attacks where unbound conditions might result in system failures.
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.
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.