Bug Fixes and Resulting Recommendations

An unexpected infinite loop issue may occur if you use two containers that contain identical products or categories to configure your promotion rule for Buy X Get X Discount/Free scenarios. For more information, see Containers Best Practice for Buy X Get X Discount/Free.

To avoid such infinite loop issues, a new constraint PromotionSourceRuleConditionConstraint was introduced to display a warning message in the Backoffice when two containers with identical products or categories are detected. For more information, see Configuring Containers with Identical Products or Categories Detection.

In SAP Commerce Cloud 2211.27 or lower versions, methods annotated with @ResponseBody in a Spring MVC controller class returned JSON objects by default. Starting with version 2211.28, these methods return XML objects instead. This breaking change is due to the introduction of the library com.fasterxml.jackson.dataformat:jackson-dataformat-xml in the azurecloud extension and may cause the handing of the API response to fail. For more information, see 3527679

The issue regarding the deprecated PBKDF2 with HMAC-SHA1 salted hashing algorithm has been resolved. Any attempt to use this password encoder when the legacy.password.encoding.enabled flag is set to false throws an exception in the log as expected.

In addition, the value of the otp.customer.login.token.code.encoder property in the project.properties file has been set to the current default (Argon2). The property determines the hashing algorithm used to generate a One-Time Password token after user login, so the property should specify the safest algorithm to ensure the integrity and confidentiality of user sessions.

Some customers were experiencing performance degradation due to excessive Database Transaction Unit (DTU) usage in the database.

The problem was traced to a resource-intensive database query that was launched during the guest user checkout process, specifically when adding products to the cart. To eliminate the problem, we have optimized the following query, which was part of the registerGuestForAnonymousCheckout process in the ServiceLayer Direct mode for persistence:

12
SELECT TargetPK,max(RSequenceNumber) FROM pgrels WHERE TargetPK IN (?) GROUP BY TargetPK

The fix consists in the change of loading of sequenceNumbers from eager to lazy, so they are now loaded only when required by specific relations, successfully mitigating the previous slowdowns.

Some customers might have experienced issues while trying to add a new transition as part of the DynamicProcessDefinition. Specifically, the system failed to recognize modifications to the OrderManualChecked action in the order management process during a system update. This prevented the manual fraud check step from being added to the order processing workflow handled by the customer support agent.

The root cause was traced to the system's attempt to validate both the old and new versions of the DynamicProcessDefinition simultaneously. Since the old definition didn't contain the newly added transition, it couldn’t be properly mapped, leading to a system exception.

Now only active process definitions are validated. This approach prevents unnecessary validation of inactive process definitions. The system can now properly recognize and apply modifications to active workflows, such as adding the manual fraud check step to the order processing workflow.

Some customers might have experienced problems with server startup resilience in the face of temporary database connection issues.

If the database connection was dropped while the system was attempting to load essential database metadata (such as persistence information for non-abstract types), the server startup proceeded, and the Spring Context was loaded. However, the system did not attempt to reload the missing persistence metadata, nor did it fail the server startup after multiple attempts to recover. Consequently, while the server showed an alive status and was up and running, critical functionalities were impaired, as the essential persistence metadata was not loaded, leading to operational issues. Ultimately, even brief network issues prevented the system from recovering after failing to load persistence information, causing deployments to become indefinitely stalled and leading to potential extended downtime.

The system now includes intelligent retry logic and graceful error handling to make server startup resilient against temporary database connectivity issues. More specifically, we have introduced the following key improvements:

• Automatic retry mechanism: When database connection issues occur specifically during the loading of persistence information within the startup process, the system automatically retries connecting and loading the required persistence information. By default, the retry duration is 120 seconds, but it's possible to configure the maximum waiting time through the persistence.loading.max.wait.duration property.
• Graceful exception handling: If the database remains unavailable after the maximum wait time, the system returns a PersistenceInfoNotLoadedException and can either shut down cleanly or resort to legacy behavior, controlled by the persistence.loading.skip.exception.legacy.flag (with a default setting of false).
• Controlled shutdown process: When persistence loading fails, the system prevents Spring Context creation and shuts down gracefully, avoiding stuck states.

This fix eliminates the problem of costly production outages caused by deployment failures and reduces deployment time and complexity by automatically handling temporary issues. At the same time, it offers configurable resilience settings for different operational requirements.

We have addressed a security vulnerability in CodeMirror 5.65.18 that affected the mode/markdown/markdown.js component. The vulnerability involves a regular expression denial-of-service (ReDoS) attack that could cause application freezing or significant performance degradation.

To mitigate this security risk, we have removed multiple language modes from the CodeMirror library in the hac extension, retaining only the following four essential modes:

• clike
• groovy
• javascript
• sql

All other language modes (including the vulnerable markdown mode) have been removed from the package.

For a complete list of over 100 removed language modes, consult the following page: What's new in Update Release 2211.45

If you want to use the hac extension with CodeMirror library modes other than the four retained modes listed above, add them back manually to the extension:

123456
<dependency>
    <groupId>org.webjars.npm</groupId>
    <artifactId>codemirror</artifactId>
    <version>5.65.20</version>
</dependency>

12345
<!-- Before -->
<script type="text/javascript" src="/webjars/codemirror/mode/yaml/yaml.js"></script>

<!-- After -->
<script type="text/javascript" src="/static/codemirror/mode/yaml/yaml.js"></script>