About this Release

This Release Notes for Infosys Equinox Commerce 8.17.7 is an independent branch of the Infosys Equinox Commerce platform. This release is feature-frozen, meaning it will not receive updates with new features, API changes, or functional improvements.

Key Areas of Focus

This release focuses on the following areas:

  • Technical Enhancements: Introduces several key technical enhancements aimed at improving the platform’s functionality, performance, and stability. These enhancements include:
    1. Product Cache Optimization for Redis/RabbitMQ: This section covers the optimization of product cache clearing process in Redis to address performance issues caused by API-based caching. For more information, see Product Cache Optimization for Redis.
    2. OMS Split for Camunda: It focuses on splitting the OMS service into instances: Order Capture and Order Processing respectively. For more information, see OMS Split for Camunda.
    3. Inventory Block & Assign Features: To avoid the order acceptance more than the availability, we introduced BLOCK and ASSIGN mechanism. It focuses on blocking the inventory during placing an order and assigning it later in the Order service. For more information, see Inventory Block & Assign Features.
    4. Search Enhancements: Admins can search or create custom attributes in the Accounts or Customers Admin console. See Search Enhancements.
  • Critical Bug Fixes: Addresses significant bugs impacting platform stability. It also includes resolved issues that have re-emerged from previous versions. See Bug Fixes for more information.
  • Security Vulnerabilities: Patches known security flaws to ensure platform safety. See Open-Source Library Vulnerability Fixes for more information.

Technical Enhancements

Product Cache Optimization for Redis

We have implemented optimizations for the product cache clearing process in Redis. Previously, using API-based caching resulted in higher utilization of Redis server due to which the other services like Order services got impacting. Our latest update addresses this issue in the following sections, enhancing performance and efficiency.

Iteration 1 Changes

  • In the Ecommerce Framework, the default SCAN count value has been changed from 10 to 50.
  • In the Search service, updated to the latest LTS framework version.

Iteration 2 Changes

We have enabled throttling queue-based cache clearing with the following configuration changes in the respective services:

Feed Job Service Changes

To support the previous configuration (api), to turn off (off), and to support event processing (event), configure the following property:

Configure the new store property “cacheClearConfig”, to configure the mode of cache clearing: API, EVENT, or NONE. This property is supported in both ZooKeeper and Store configurations. It sets the default cache clear configuration. The default value is {“product”:”event”,”merch”:”event”}. For example, in the ZooKeeper property, you can configure as follows:

skava:
  cache:
    defaultCacheClearConfig:
      defaultValue: {"product":"event","merch":"event"}
      description: "This property sets the default cache clear configuration."
      allowedValues:
        - valid string value

Search Service Changes

  • As we are running multiple search PODs, we need to have a single consumer per POD. To achieve this, we have added a consumer for the cache queue with a concurrent consumer value of 1.
    • Added a new ZooKeeper property “customConcurrentConsumers” in the Search service. This property is used to set the custom concurrent consumers for RabbitMQ. The default value is set to 1.
  • In Redis, we have two options to clear the cache, such as KEYS and SCAN commands. In production, the SCAN command is recommended. Hence, we have enabled this option by default. Configure as follows:
    • Added a new ZooKeeper property “redisScanCount” in the Search service. This property is used to set the custom count of the Redis scan. The default value is 0. When the value is 0, the ZooKeeper property “redisDBSplitBy” will be considered.
    • Added a new ZooKeeper property “redisDBSplitBy” in the Search service. This property is used to set the Redis scan count (pagination) by dividing the Redis database size by the given value. The default value is 4.

Iteration 3 Changes

  • Each POD (Search services) has its own consumers to process messages, which increased Redis usage, we introduced a configurable delay between message processing:
    • Added a new ZooKeeper property “forceDelayInMillisecs”. This property is used to delay the cache clear message processing as per the defined value. The default value is 1000 (in milliseconds).
  • A client team was using scheduled based pricing due to which the cache clear is not required by the client team. We have created different configurations to give independent cache times for Catalog and Merchandising services. Configure as follows:
    • Added new ZooKeeper properties in the Search service:
      • Search_Index_Cache_default_sfo_catalog_solr_collection
      • Search_Index_Cache_default_sfo_merch_solr_collection

These properties are used to set the expiration time for the created Redis collections for Catalog and Merchandising services.  The default value is 60.

Iteration 4 Changes

  • A client team wants to enable CDN. The following configuration is used to disable a specific cache in the Search services:
    • Added ZooKeeper property “excludeCacheNames” in the Search service. This property is used to disable the Redis cache for the given cache names.

OMS Split for Camunda

It focuses on splitting the OMS service into instances: Order Capture and Order Processing respectively. For more information, refer to the following document:

Infosys Equinox Order Split Document

Inventory Block & Assign Features

This change focuses on blocking the inventory during placing an order and assigning it later in the Order service. Currently, the orders are placed without any block which leads to accepting order more than the inventory capacity. This feature changes include:

  • Inventory Service Changes: Introduction of new transaction types and properties to better manage inventory, including block expiry times and enhanced validation for inventory checks. For more information, see Inventory Service Changes.
  • Order Changes for Inventory: Updates to transaction types and payloads to streamline inventory assignment and improve order processing workflows. For more information, see Order Changes for Inventory.
  • Storefront Orchestration Changes: Internal updates to transaction handling within the Create Order API to ensure accurate inventory blocking and unblocking. For more information, see Storefront Orchestration Changes for Inventory.

For sequence diagram, FAQs, and other technical-related information on Block & Assign, refer to the following document:

Infosys Equinox Assign & Block Document

To achieve this, refer to the following sections:

Inventory Service Changes

Configure as follows:

  • The collection property “BlockExpiryTime” has been newly introduced, providing the default time for block expiry. The default value is 5 minutes.
  • When a “BLOCK” type transaction is created, its associated BinItem is updated with blocked quantities in the required fields as per the TRANSACTION entity, only if the requested quantities are less than or equal to the available quantity in the BinItem. The expiry time for the block is calculated using the collection property “BlockExpiryTime”.
  • When an “ASSIGN” type transaction is created, its associated “BLOCK” transaction (ref_transaction_id) is marked as “INACTIVE” after successfully reducing the blocked quantities and increasing the real quantity from BinItem as per the “BLOCK” transaction entity details, only if the associated “BLOCK” transaction is valid and “ACTIVE”.
  • The collection property “EnableUnblockExpiredTransactions” has been newly introduced. When the value is set to
    • true – While creating any transaction, if any “ACTIVE” expired “BLOCK” type transaction is available in the database, it is marked as “INACTIVE”. After successfully reducing the blocked quantities from the BinItem as per the “BLOCK” transaction entity details.
    • false – No cleanup happens for BLOCK type expired ACTIVE transactions. The default value is false.
  • While validating the Check Inventory API, the “ATP Block Quantity” is now considered along with the “ATP Quantity” when passing the request body.

For example, if the expected inventory is “5”, both ATP and ATP Block Quantity are checked:

  • If ATP Quantity is “50” and ATP Block Quantity is “2”, the remaining quantity is 48. This will be true.
  • If ATP Quantity is “50” and ATP Block Quantity is “48”, the remaining quantity is 2. This will be false.
  • When an “UNBLOCK” type transaction is created, its associated “BLOCK” transaction (ref_transaction_id) is marked as “INACTIVE” after successfully reducing the blocked quantities from the BinItem as per the “BLOCK” transaction entity details, only if the associated “BLOCK” transaction is valid and “ACTIVE”.

While creating any transaction, if any “ACTIVE” expired “BLOCK” type transaction is available in the database, it is marked as “INACTIVE”.

  • Under the Transactionentity, the following fields have been introduced to capture the data:
    • Block Expiry Time
    • Reference Transaction ID

These fields capture the data based on the new transaction types: Block, Unblock, and Assign.

  • The following new fields have been introduced to capture the details of the blocked quantity:
    • ATP Blocked Quantity (atpBlockedQty)
    • Pre-Order Blocked Quantity (preOrderedBlockedQty)
    • Back Order Blocked Quantity (backOrderedBlockedQty)

Order Changes for Inventory

  • The “Assign” transaction type is now used to assign the inventory quantity, replacing the “Remove” transaction type.
  • The “Assign” transaction type payload has been created to:
    • Enable the Order service to retrieve the block transaction ID from the Order Item Info Properties.
    • Allow the Order service to send the details to the Inventory service based on the block transaction ID to assign the inventory.
  • The BPM flow has been updated to:
    • Include the blocked quantity.
    • Assign the inventory quantity within the block expiry time.
  • The BPM has been configured so that the order can enter a wait state for the CSR to act upon instead of the order being deleted. The default value is 24 hours.

Storefront Orchestration Changes for Inventory

  • The “Block” transaction type is called internally with the Create Order API to block the inventory quantity.
  • If there is any error while placing an order, the “Unblock” transaction type is called internally to unblock the inventory quantity.
  • The store property “enableInventoryQtyBlockValidation” has been newly added to the Storefront Orchestration. When this property is set to:
    • true: blocks the inventory during the order placement by a storefront user.
    • false: does not block the inventory during the order placement. This is default.

Search Enhancements

The following new features have been implemented, and relevant changes have been incorporated in the Customer Admin console, Accounts Admin console, and Admin Orchestration services:

  • Ability for admins to search the custom attributes in the Accounts or Customers Admin console.
  • Ability for admins to create custom attributes in the Customer Admin console.

Bug Fixes

Here is a list of all the functional and technical/API fixes that have been resolved for this release:

Functional Fixes

Promotion Admin Console

  • Previously, dates were enabled in the Promotion Group and the Promotions’ date picker popup during creation and updates. Now, dates are displayed as expected in the date picker popup.
  • When applying a promotion with GWP to both normal and bundle products, the “AND” operator condition has been removed, retaining only the “OR” and “NOT” operators in the Promotion Admin console.
  • Previously, the “Stop Further Processing” condition did not function correctly, affecting promotions. Now, when a stop condition is added at the promotion group level and this condition is met, the system fetches the applicable offers and halts promotions from other groups. If the condition is not met, the system continues to check other promotion groups.

Pricing Admin Console

  • The configured Property condition in a promotion is not shown upon saving. Now, the property condition is displayed appropriately under the Conditions tab.

Catalog Admin Console

  • Fixed an issue where the dateofavailability attribute was added in the wrong format when editing the status of a SKU or product. The correct format should be ‘1994-01-03T01:00:01.000-07:00‘ or ‘1994-01-03T01:00:01.000‘ instead of ‘1994-01-03T01:00:01‘.

Technical/API Fixes

Storefront Orchestration Services

  • The order placement issue related to shipping discount proration, caused by a null mathordershipping value for the last item resulting in value mismatches, has been fixed in the Storefront Orchestration services.
  • The list of component details that are available in backend were exposed in the error response in the Orders controller of the Storefront Orchestration services. This issue has been fixed.
  • Previously, domain values were accepted in the locale fields. This is now restricted in the Storefront Orchestration services.
  • We have addressed an increase in 500 errors caused by large headers being passed to the promotion microservice from the search API.

Admin Orchestration Services

  • Only specific file upload extension has been allowed in the Admin Orchestration services to avoid security issues.
  • Previously, clicking ‘Resend Invite’ in the Foundation Admin console resulted in a 201 response, but the user did not receive the notification email. Now, the email is triggered correctly, and the user receives an activation email.
  • Validation is not provided in the input fields while updating details via an API call in the Admin Orchestration services. This has been rectified to provide proper validation messages.

E-Commerce Framework & Admin Console

  • Vulnerable JavaScript dependency security issue has been resolved.

E-commerce Framework

  • In the platform framework, secret keys or credentials are stored within the service instance to avoid repeated calls to AWS Secret Manager. However, updates to AWS secrets are not automatically reflected, requiring a manual restart or deployment. To streamline this process, a new Refresh API has been introduced in the Secret Manager component to clear cached data from the service instance, triggered via the pipeline.

Payment Service

  • The authtoken which was optional earlier has been made mandatory now in the Payment service’s POST payment/tokens API.

Customers (User) Services

  • Each microservice attempts to retrieve the master secret key from the cache on incoming requests. If the cache retrieval fails, it should fall back to the secret manager. Previously, errors were not handled properly, causing the process to end. Now, it correctly fetches data from the origin when Redis fails.
  • The “getTesttoken” API has been removed/hidden in the Customer (User) services.
  • Fixed an issue were attempting to activate an account from the ‘Activate Your Account’ email notification resulted in the 500-error message.

Open-Source Library Vulnerability Fixes

The unique security vulnerabilities that have been patched in the Infosys Equinox Commerce platform are 28 vulnerabilities. The total vulnerability fixes are 2,514.

  • Critical – 128
  • High – 952
  • Medium – 427
  • Low – 1,007

 

 

Revision History
2024-11-25| JP – Added content for Release 8.17.7.