24.7 Release

Salesforce B2C Commerce now uses eCDN with WAFv2. WAFv2 brings advanced security features to safeguard all your zones, both existing and new. You can migrate your existing customer zones from WAFv1 to WAFv2 as a self-service option. You can configure eCDN WAFv2 settings directly through the Business Manager UI or CDN Zones API for new zones. In addition, eCDN with WAFv2 integrates ruleset enhancements that improve firewall security and reduce false positives, improving threat detection accuracy and minimizing disruptions to normal operations.

When: All zones must be migrated from WAFv1 to WAFv2 by February 1, 2025.

Why: WAFv2 includes these ruleset enhancements.

• OWASP ruleset: The Salesforce eCDN OWASP Core Ruleset is our implementation of the OWASP ModSecurity Core Rule Set (CRS). It’s updated regularly based on the latest version from the official OWASP code repository.
• eCDN managed rules: The Salesforce security team continually updates the ruleset to address new vulnerabilities and reduce false positives.
• eCDN exposed credentials check: Helps to identify stolen credentials by performing a lookup against a public database of compromised credentials.

How: To migrate your existing zones to WAFv2, on the Business Manager WAF tab, go to the Business Manager UI and WAFv1 zones section. Click Start WAFv2 Migration, and follow the prompts.

B2C Commerce has improved the performance of the common category lookup in storefront search and search refinement. Based on internal testing, the search engine calculates search refinements two times faster. With improved search, your users experience faster storefront response times, providing a smoother browsing experience.

In Business Manager, easily import and export dynamic categorization rules, including the excluded product list. The Catalogs Import & Export feature now updates the catalog.xsd schema with detailed information on categorization rules and excluded products within the catalog tag structure. Previously, you couldn’t import and export the dynamic categorization rules.

How: The catalog.xsd now includes this information structure.

<catalog>
    <category category-id="category-1">
        <categorization-rules-and-excluded-products>
            <categorization-rules xml:lang="locale" site-id="site-id" primary-category-assignment="true" classification-category-assignment="false">
                <categorization-rule id="rule-id" enabled-flag="true" exclusion="false">
                    <categorization-condition id="condition-id" attribute-id="attribute-id" operator="equals">
                        <attribute-value>attribute value name</attribute-value>
                    </categorization-condition>
                    <categorization-condition id="condition-id" attribute-id="attribute-id" operator="equals">
                        <attribute-value>attribute value name</attribute-value>
                    </categorization-condition>
                </categorization-rule>
                <categorization-rule id="rule-id" enabled-flag="true" exclusion="false">
                    <categorization-condition id="condition-id" attribute-id="attribute-id" operator="equals">
                        <attribute-value>attribute value name</attribute-value>
                    </categorization-condition>
                </categorization-rule>
            </categorization-rules>
            <categorization-excluded-products>
                <categorization-excluded-product product-id="product-id1"/>
                <categorization-excluded-product product-id="product-id2"/>
            </categorization-excluded-products>
        </categorization-rules-and-excluded-products>
    </category>
</catalog>

If there is no tag <categorization-rules-and-excluded-products> and it's elements in the import file, no changes will be applied to the existing rules and excluded products.

To delete all existing rules and product exclusions in the respective category during import, use the empty tag within the category tag <categorization-rules-and-excluded-products/>.

If content is set within the <categorization-rules-and-excluded-products> tag, it replaces all the existing rules and excluded products for the respective category with the ones mentioned in the current tag.

You can now update the status of a coupon redeemed outside of B2C Commerce using the new Coupon Redemption API (/organizations/{organizationId}/coupons/actions/redeem). To identify the source of redemption for an external coupon, use a custom reference ID or any custom string. You can also add an optional email address to the redemption for further tracking and communication. To update multiple coupon redemptions at one time, use the new ImportCouponCodeRedemptionsStep job step. This bulk import, which works only in merge mode, streamlines the process of managing multiple redemptions at scale.

The B2C Commerce service framework now supports TLS v1.3 for outgoing HTTP calls made from the platform. TLS v1.3 provides enhanced security features that don’t require complex configuration. It offers modern encryption standards that protect against known vulnerabilities and supports secure integration with third-party partners. If you encounter connectivity issues while using TLS v1.3, contact Support for assistance.

Commerce Cloud is implementing a new security measure that blocks traffic to staging instances that doesn’t originate from Commerce Cloud eCDN from accessing the hyphenated demandware.net hostname. This change rejects all calls using ‌hyphenated hostnames, such as staging-, to access the Open Commerce API (OCAPI) or Storefront.

When: This change becomes effective on October 7, 2024.

Why: Currently, traffic through demandware.net doesn’t have eCDN controls in place, posing a potential risk to your data security. Origin Shielding for staging is crucial to make sure that all external traffic goes through the eCDN security layers before reaching your environment.

The introduction of Origin Shielding for staging impacts Commerce Cloud customers who currently have implementations that involve direct calls to POD IPs.

How: To prepare for this upcoming change, Salesforce requests customers take these actions:

1. Evaluate your current implementations for calls made to OCAPI or Storefront using direct POD IPs, dot-form hostnames, or hyphenated hostnames for demandware.net. For example, staging.xxx.demandware.net or staging-xxx.demandware.net.
2. Update services or applications to use the vanity hostname and route traffic through eCDN.

You can create a proxy zone on Staging instances through the Business Manager and configure a custom hostname with an automatically renewing eCDN Managed certificate for added protection.

For further assistance, contact your Customer Service Manager (CSM).