Choosing a customization model

You can customize HCL Commerce using the traditional development model, or the externalized Customizations (xC) framework. Which approach you use depends on how complex your requirements are, and how beneficial it is to you to isolate your customization code.

Prior to Version 9, core HCL Commerce functionality required you to extend server functions directly. The xC programming model gives you more flexibility by isolating your customization code within an xC server. There are numerous advantages to this approach:
  • Because xC customizations run on their own server, upgrades and fixes to the core components of the HCL Commerce system will not overwrite them. In other words, xC is the enabler for a zero-outage customization environment with regression-free updates. If an xC extension point exists for customizations you have already made using the old model, migrating them to xC gives you the benefit of isolating them from maintenance and upgrade issues.
  • Customizing an extension point is often simpler than modifying traditional subsystems directly.
  • xC is ideal for integration scenarios. You can often use an existing extension point to perform the integration.
  • The xC model is not a replacement for the traditional HCL Commerce programming model, but works alongside it. You can use a mix of both approaches.
  • The xC customization server runs on Liberty and uses the REST API, so it provides a path to modernizing your customizations.

In summary, xC delivers a highly robust, zero-outage customization option for a useful subset of HCL Commerce functions. For more complex enhancements or those that require changes to the Docker servers or their behavior, you can use the traditional programming model.

For more information about the externalized Customizations framework, see Extending HCL Commerce with xC extension points.

Positioning of the traditional and xC programming models

The Version 9 runtime is different from previous versions in several important respects. JPA has replaced EJB entities in the Transaction server; for more information, see Migrating IBM Websphere Commerce Version 8 EJB entity beans to Java Persistence API. In addition, Version 9 runs its servers inside Docker containers. To customize a server you must build a new version of it and run it as a customized Docker container. In this containerized environment, the customization server does not have direct access to the Transaction server database. Therefore, neither will your customization code if it runs in xC. The traditional programming model still allows you to use custom database tables in the Transaction server.

  • Running extensions in a separate Docker container introduces a performance cost. For this reason, xC is only appropriate for light modifications at this time.
  • Only integration scenarios have been validated with xC by IBM. Only use xC for integration projects, for example, payment or tax integration .
The Docker-based architecture imposes other limitations on what customizations can be run from the xC server. You will need to use the traditional programming model if you want to do the following:
  • Deploy custom cron jobs or shell scripts
  • Deploy manually or deploy via a custom package structure
  • Alter the server topology
  • Deploy 3rd party components outside of the deploy package
  • Deploy data load mediators
  • Have command line access to any of the servers
  • Deploy agents used by monitoring services
  • Deploy customizations of the Apache Solr search binaries
  • Alter Operating System-level utilities
  • Create custom log files
  • Customize Management Center, HCL Commerce Accelerator, or the HCL Commerce Administration Console
  • Alter or create new Commerce REST services
Restriction: Promotions and marketing has no xC extension points, so it is limited for use with orders and returns, promotions and marketing.