Identifying the Core/Platform Features

SAP Commerce Cloud updated the groundbreaking Compatibility Guide, providing comprehensive information on the compatibility between various components and releases. This guide serves as a one-stop reference for users, detailing compatibility between add-ons, independent software vendor (ISV) products, extension packs, and composable storefront releases with different versions of SAP Commerce Cloud. Additionally, it outlines system and third-party software requirements, offering users a holistic view of the compatibility landscape and empowering them to make informed decisions regarding system configurations and extensions.

Please click to get into the first page of the compatibility guide and check through the documentation. But don't forget to expand the explorer tree on the left (cf. below) to find out more information about the other important solutions of SAP Commerce Cloud.

The introduction of lazy loading for relation/collection attributes in Models brings a finer level of configurability to service layer based implementation. This enhancement allows users to enable the lazy loading mode:

• either globally through the property: servicelayer.lazy.collections=true (default is false) for all the relation/collection attributes,
• or via the property: servicelayer.lazy.collections.<Type> .<Attribute> .enabled=true for a particular relation/collection attribute of a certain type. For example, if you want to enable the lazy loading mode for the addresses collection that is defined in the Company Model, you use:

1
1| servicelayer.lazy.collections.Company.addresses.enabled=true​

It is now possible to stop (or fail) the initialization/update process during data import errors of an ImpEx file. To enable this behavior, you only need to set

1
1| system.setup.create.data.fail.on.error=true

This deliberate pause serves as a strategic measure to validate configuration integrity and ensure that the project data undergoes accurate processing. By stopping the system, you can meticulously investigate and rectify any issues that may arise during the crucial stages of data import, contributing to a more robust and error-resilient platform.

The free-text input field for SQL statements in the SAP Commerce Cloud Administration Console (HAC) is replaced since 2211.12 by a dropdown list of pre-configured SQL statements based on custom properties cf. HAC Monitoring (1) → Performance (2) → SQL (3).

The definition of the custom properties follows this format(4):

1
1 | hac.performanceTest.statement.<ID>=<SQL statement>

For example:

1
1 | hac.performanceTest.statement.selectFromProducts=SELECT * FROM products

Since 2211.12, in response to the diverse testing and local development environment needs, database logging is now disabled by default in standalone mode (including ant initialize, ant update, and ant integrationtest commands). This ensures that the generation of database audit logs is minimized during testing and in local environments.

You can enable database logging by adding a specific property to the local.properties file:

1
1 | dbaudit.disabled.for.standalone=false

This approach aligns with best practices, allowing users to selectively activate database logging when needed, while prioritizing performance in development and testing scenarios.

The Scheduler Watchdog introduces a robust mechanism to manage tasks in a clustered environment with multiple server nodes.

As the default strategy, the AuxiliaryTablesTasksProvider task fetching strategy is tailored for environments where a scheduler node and worker nodes collaborate to process tasks in the task queues. You can find a descriptive diagram here to explain the working principle of the strategy.

Since 2211.8, to prevent multiple schedulers from executing operations concurrently, the scheduler watchdog monitors the activity time of schedulers. This ensures a coordinated and efficient task execution approach, particularly in clustered environments, enhancing the overall reliability and performance of task processing within SAP Commerce Cloud.

Content Security Policy (CSP) headers, implemented in HTTP responses, serve to reduce the risk of code-injection vulnerabilities like XSS or clickjacking. These headers enable you to define the resources that a browser is permitted to render when users access your application.

Since 2211.4, Content Security Policy (CSP) response headers are integrated into web applications of selected extensions, such as hac, adminapi, oauth2, processing, etc.

In addition, this security measure extends to the 'yempty' extension, enabling users to create custom CSP headers for enhanced security in custom extensions. An example of a custom property for a custom extension <Ext Name> can look like this:

1
1 | <Ext Name>.xss.filter.header.Content-Security-Policy=default-src 'self'; style-src 'self'

The configurable property, invalidate.current.authentication.on.password.change, is introduced to address a critical security aspect, whether the HTTP session and token utilized during a password change should be invalidated immediately after the change.

By leveraging this property, users gain granular control over the authentication mechanisms, enhancing security practices within the platform. This feature aligns with best practices for managing user sessions and access control in response to password-related events.