General Technical Updates

Objective

After completing this lesson, you will be able to identifying various updates of interest to developers

Setting Gradle Root Project Name in Property Files

A new property has been introduced to enable persistent Gradle project naming in SAP Commerce Cloud, streamlining workflow for developers managing multiple versions.

A new property has been introduced that allows you to define a name of the root Gradle projects that are generated with ant gradle:

JSON

12
gradle.project.name=<project-name>

The default value of this property is platform.

The value of this property is used as a name for a Gradle root project only when there's no explicit name provided in the ant gradle call. This means that if you generate a Gradle project with the following command, the myCustomProjectName value is used regardless of the value provided with the gradle.project.name property:

Code Snippet

12
ant gradle -DprojectName=myCustomProjectName

Why?

The new gradle.project.name property in offers a more efficient way to set Gradle project names, replacing the need to repeatedly use the -DprojectName option with the ant gradle command. This persistent, project-specific approach allows you to easily manage multiple SAP Commerce Cloud versions without constantly specifying the project name. The new property maintains backward compatibility by defaulting to platform if not set, and still allows the use of the -DprojectName option, which takes priority if both are specified. This enhancement particularly benefits those who frequently switch between different SAP Commerce Cloud projects in their IDE, streamlining their workflow and reducing potential errors from manual input.

Improved Logic for Setting Purchasable Field Value in Product Populators

The value of the purchasable field for a product is determined collaboratively by multiple populators.

Multiple populators can collaborate to determine the value of the purchasable field for a product. However, the final value of the purchasable field is not determined based on the sequence of populators. For instance, the productPricePopulator sets the purchasable field to false if no price data is found for the product. This value will not be switched to true even if the productBasicPopulator runs after the productPricePopulator.

Why?

You can now create your own product populator to set the purchasable value for a product, without concerns of it being reset by the productBasicPopulator due to the sequence of populators.

Improved IP Address Handling to Use Customers' Real IP Addresses Instead of Proxy Addresses

Experience improved IP address handling in the /applyVoucher OCC API. Now, customers' real IP addresses are used for brute force protection instead of proxy addresses.

Brute force protection limits the number of coupon applications within a specified time period per IP address. Previously, the /applyVoucher OCC API uses the request.getRemoteAddr() method. When customers use a proxy, the system uses the proxy address in brute force protection instead of their real IP address. If multiple customers share a single proxy, they also share the coupon usage limitation.

To use customers' real IP addresses in brute force protection, a new toggle named toggle.useXForwardedForForIp.enabled is added to de.hybris.platform.commercewebservices.core.v2.controller.BaseCommerceController under the commercewebservices extension.

The toggle prioritizes the X-FORWARDED-FOR header over the request.getRemoteAddr() method. It ensures that the brute force handler receives the customers’ real IP address, whether they're using a proxy or not.

When customers are using a proxy, the X-FORWARDED-FOR header contains their real IP address, while the request.getRemoteAddr() method holds the proxy IP information. The system prioritizes the X-FORWARDED-FOR header and sends the real IP address to the brute force handler instead of the proxy IP.
When customers aren't using a proxy, the X-FORWARDED-FOR header remains empty, and the request.getRemoteAddr() method contains their real IP address. This real IP information is sent to the brute force handler.

Why?

This feature enhances customers' experiences by preventing shared limitations among users of the same proxy, providing a more personalized and fair shopping experience.

Feature Activation

Depending on the release you are using, this feature may be deactivated by default. To activate it, see Activating Improving IP Handling to Use Customers' Real IP Addresses Instead of Proxy Addresses.

Solr 9.8 Support

SAP Commerce Cloud now supports Solr 9.8.

The Solr application that comes with this release's SAP Commerce Cloud ZIP uses Solr 9.8 as its default version. For information on configuring the Solr version, see Selecting Solr Server Version.

Upgrading to Solr 9.8 ensures compatibility and access to the latest features and improvements in Solr. For more information, see Advancing to Solr 9.8.

For more details, see the following resources:

Caution

As of Solr 9.7, the default schema.xml version is upgraded to 1.7. During an upgrade, we recommend explicitly setting the schema version to 1.6 to guarantee there are no indexing issues.

For details on the schema related changes you can refer to, see the Apache Reference Guide.

New Property Added

To support Solr versions 9 and later, a new property, solrserver.instances.<instance_name>.placement.plugin, has been introduced in the project.properties file for configuring the replica placement. For more information, see Solr Instance Properties.

Why?

Using the newer Solr versions allows you to benefit from newer functionality and security provided by Solr.

Support for Localizable Exceptions

You can now use new classes from the ServiceLayer i18N package to localize exceptions thrown in SAP Commerce Cloud.

The ServiceLayer i18N package now contains classes that you can use to implement localization for SAP Commerce Cloud exceptions. For more information, see Support for Localizable Exceptions.

Why?

Localizable exceptions enable error messages to be easily translated and adapted for different languages and cultures, improving user experience and application maintainability.

Protection of Media Against Direct Folder Changes

There's a new safeguard in place to protect media with associated data against direct changes to the media folder. The protection is enabled by default, ensuring the integrity of file locations and preventing abandoned files in the media storage. For operations that require direct folder changes, a session-based override option is available.

Why?

This enhancement improves overall system reliability and helps maintain a clean, well-organized media storage structure.

Next lesson