Home
Documentation
This Help Center provides documentation on all aspects of the HCL Commerce+ Transaction Server product, from installation and deployment to operating and customization.
Administering
The site administrator performs the tasks needed to support day to day operations of the Commerce+ Transaction Server site.
Administering Search
HCL Commerce+ Transaction Server Search provides the core search capability for Commerce+ Transaction Server, 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.
Commerce+ Transaction Server Solr and Elasticsearch
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.
Solr -based solution
The Solr search index lifecycle includes tasks that you perform after Commerce+ Transaction Server 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.
Applying patches
The following topics describe how to apply patches received from Commerce+ Transaction Server to NiFi.

Documentation
This Help Center provides documentation on all aspects of the HCL Commerce+ Transaction Server product, from installation and deployment to operating and customization.
- Overview
  Welcome to the HCL Commerce+ Transaction Server overview. Explore these feature overviews to learn how Commerce+ Transaction Server operates. Refer to the related links listed at the end of each topic to access expanded product documentation.
- Deploying
  This section provides details on deploying HCL Commerce+ Transaction Server. 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.
- Migrating
  The following topics show how to migrate an existing HCL Commerce Version 9.1 environment to Commerce+ Transaction Server.
- Operating
  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.
- Administering
  The site administrator performs the tasks needed to support day to day operations of the Commerce+ Transaction Server site.
  - Member groups
    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.
  - Inventory management
    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.
  - Approvals
    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.
  - System Administration
    Commerce Lab allows you to manage transport, messages, scheduler, Connectors, registries, and security policies.
  - Staging environment
    An Commerce+ Transaction Server 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
    Workspaces provide a powerful and flexible way to manage and preview changes to your e-commerce website without affecting the live production environment.
  - Commerce+ Transaction Server database
    As a site administrator, maintain the Commerce+ Transaction Server database and ensure that any Commerce+ Transaction Server utilities and processes that load and retrieve data from the database is configured to connect to the database properly.
  - Dynamic caching
    In general, caching improves response time and reduces system load. Caching techniques are used to improve the performance of World Wide Web Internet applications. Most techniques cache static content (content that rarely changes) such as graphic and text files. However, many websites serve dynamic content, containing personalized information or data that changes more frequently. Caching dynamic content requires more sophisticated caching techniques, such as those provided by the Open Liberty Server dynamic cache, a built-in service for caching and serving dynamic content.
  - Extracting and loading data
    Commerce+ Transaction Server provides utilities for preparing and loading data into a Commerce+ Transaction Server database. The loading utilities are flexible and you can continue to use these utilities when you customize the Commerce+ Transaction Server schema.
  - Administering Search
    HCL Commerce+ Transaction Server Search provides the core search capability for Commerce+ Transaction Server, 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.
    - Search
      Discover how Search enables catalog browsing, indexing, and product discovery across Commerce+ Transaction Server storefronts while preserving your existing Solr and Elasticsearch configurations during migration.
    - The search service
      Commerce Search includes a data ingest component and the powerful indexing and query services of the Elastic engine. Commerce+ Transaction Server services are SaaS services. In day-to-day operations, they function like internal components of Commerce+ Transaction Server, but when a service is upgraded, its improvements become instantly available to Commerce+ Transaction Server.
    - Commerce+ Transaction Server Solr and Elasticsearch
      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.
      - Comparing Solr and Elasticsearch architectures
        The Solr and Elasticsearch systems behave similarly at the storefront level. Behind that layer are key differences in architecture.
      - Comparing Solr and Elasticsearch index lifecycles
        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.
      - Comparing Solr and Elasticsearch common business tasks and their impact on the search index
        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.
      - Migrating from Solr to Elasticsearch
        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.
      - Developer Solr-based Search environment
      - HCL Commerce Developer Solr-based Search environment
      - Orchestration service
        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.
      - Elasticsearch-based solution
        The Commerce+ Transaction Server 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.
      - Solr -based solution
        The Solr search index lifecycle includes tasks that you perform after Commerce+ Transaction Server 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.
        Populating and building the search index data
        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.
        Applying patches
        The following topics describe how to apply patches received from Commerce+ Transaction Server to NiFi.
        Applying a class patch to Commerce+ Transaction Server Search server
        Complete the following steps to apply a class patch to NiFi.
        Backing up, restoring, recovering, and verifying search indexes
        Several tasks help you backup and restore the Commerce Search index, depending on your business needs.
        Workspaces in Commerce Search
        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.
        Using Search with product variants
        Commerce+ Transaction Server 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
        User sessions are synchronized between the Commerce+ Transaction Server and Commerce+ Transaction Server search servers.
        Search index locking
        The Commerce Search index is locked at certain points during the indexing lifecycle. For example, when running the search utilities or scheduler jobs.
        Debugging Commerce Search
        You can debug Commerce Search by directly accessing Solr functions by using a web browser, without using Commerce+ Transaction Server run time or utilities.
        Tracing and logging
        You can enable tracing and logging to help troubleshoot Commerce Search after deployment.
- Extending
  Using Commerce+ Transaction Server'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.
- Securing
  These topics describe the security features of Commerce+ Transaction Server and how to configure these features.
- Performance
  Topics in the Performance section describe the means by which to plan, implement, test, and re-visit the optimization of Commerce+ Transaction Server site performance.
- Troubleshooting
  Topics in the Troubleshooting section highlight common issues that are encountered with Commerce+ Transaction Server, and how they can be addressed or mitigated.
- Reference
  Topics in the Reference section contain all of the Commerce+ Transaction Server reference documentation.

Applying patches

The following topics describe how to apply patches received from Commerce+ Transaction Server to NiFi.