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.
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.
OpenTelemetry
OpenTelemetry is an open source framework for gathering performance traces, metrics and logs from your HCL Commerce+ Transaction Server system.
Enable OpenTelemetry
When OpenTelemetry (OTEL) is enabled in the Helm chart, it is enabled for all containers, including Ruby. This page explains how to use the OpenTelemetry toolkit with Ruby storefronts.

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.
- 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.
  - Methodology
    Like site security, a proper approach to site performance requires planning, execution, testing, monitoring, and maintenance. The following collections of topics describe each phase of this process, and contain the recommended considerations, and best practices for getting the most out of your Commerce+ Transaction Server deployment.
  - OpenTelemetry
    OpenTelemetry is an open source framework for gathering performance traces, metrics and logs from your HCL Commerce+ Transaction Server system.
    - Java agent extension
      The HCL OpenTelemetry extension extends the standard OpenTelemetry Java agent with a set of features for serviceablity.
    - Enable OpenTelemetry
      When OpenTelemetry (OTEL) is enabled in the Helm chart, it is enabled for all containers, including Ruby. This page explains how to use the OpenTelemetry toolkit with Ruby storefronts.
  - HCL Cache
    The HCL Cache integrates with DynaCache and improves performance and scalability with features such as remote caching, real-time monitoring, and auto-tuning capabilities.
  - Experiments considerations
    When experiments that you have created in WebSphere Commerce Accelerator are running in the store, the Scheduler launches a job that determines whether any of the current experiments have expired. The job compares the expiration date specified in the experiment to the current system date. When an experiment is identified as expired, its status is updated in the database, and the experiment is prevented from displaying to customers.
  - Website performance tuning
    There are four steps for evaluating performance of an Commerce+ Transaction Server website that is based on Transaction server.
  - Tuning the price rule object cache
    You can improve performance by changing the size of the cache used to store price rule business objects during storefront runtime.
  - Data Load utility performance tuning
    Scheduled Data Load utility jobs can affect Commerce+ Transaction Server performance. You can reduce the impact of this process by tuning the data load performance appropriately for your implementation.
  - Workspaces performance tuning
    Workspaces use database views instead of tables to retrieve data. Retrieval of underlying data might be more time-consuming because of the complexity of SQL statements that are used in workspace view definitions.
  - Thread Monitor - Yaml configuration file
    The Thead Monitor tool gathers thread dumps and Javacores at a configured interval, and during events such as high WebContainer/Default_Executor pool thread usage. Yaml configuration file must exist with name /SETUP/support/thread_monitor.yaml, or under the location specified with the THREAD_MONITOR_CFG environment variable.
  - Elasticsearch performance tuning
    You have numerous options when tuning the performance of NiFi and Elasticsearch. The following guide introduces tools for monitoring performance and validating key tuning parameters, and provides a performance tuning strategy that you can use with the component.
  - Tuning ingest performance in Elastic part II
  - Recommended Parameters for NIFI and Elastic
    You can run your Elastic and NiFi environments using the default settings, which provides a minimal resource set. For best performance, tune your configuration or use the recommended parameters for CPU, memory and system resources.
  - Measurement
    As each deployment of Commerce+ Transaction Server is different, a measured approach to modifying your defaults must be taken to successfully tune your site. The following collection of topics provides details on how to measure and troubleshoot site performance.
  - REST caching on TXN server
    Emerald Store is powered by the REST framework, and the cache is implemented using a REST servlet.
- 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.

Enabling OpenTelemetry for containers

When OpenTelemetry (OTEL) is enabled in the Helm chart, it is enabled for all containers, including Ruby. This page explains how to use the OpenTelemetry toolkit with Ruby storefronts.

Pages Router

The Ruby storefront implementation of OpenTelemetry uses pages router request-id tracking. This capability is set using environment variables.

To enable OpenTelemetry for Ruby storefront:

Set OTEL_JAVAAGENT_ENABLED to true, or,
Set NEXTJS_OTEL_ENABLED to any value other than false.

OpenTelemetry defines its own environment variables, which are documented on the OpenTelemetry website. The OTEL_EXPORTER_OTLP_ENDPOINT variable must be set in the environment for traces and spans to be sent to the OpenTelemetry server. This is the only mandatory variable from the OpenTelemetry toolkit.

Additional features

You may use other OpenTelemetry variables as appropriate for your environment. You may need to set some of these environment variables to push traces and spans to any custom endpoints you have configured to receive them.