An ecommerce site has dynamic shipping cost calculation. it allows the customers to see their potential shipping costs on the Product Detail Page…

The core issue is the violation of the spi.basket.addResolveInSameRequest quota, which limits the number of basket modifications within a single server request. The original logic performs an "add" and a "remove" operation for each shipping method, quickly exceeding this limit.

The correct architectural pattern for this "what-if" calculation is to wrap the basket modification and cost calculation within a transaction and then explicitly roll it back. The dw.system.Transaction.wrap() method or a begin/rollback block allows the system to calculate costs based on a temporary basket state in memory. The rollback then discards these changes without persisting them, effectively restoring the basket's original state. This avoids the expensive remove operation and respects the platform's governance limits while fulfilling the business requirement.

1. Salesforce B2C Commerce Developer Center

dw.system.Transaction Class Documentation: The official documentation describes the use of transactions for grouping database operations. The pattern of beginning a transaction

performing temporary modifications for calculation

and then rolling back is the standard approach for "what-if" scenarios to avoid persisting changes. The wrap(callable) method is often highlighted as a best practice for this.

2. Salesforce B2C Commerce Developer Center

"Custom Code Limits (Quotas)": This documentation outlines the platform's governance limits. The spi.basket.addResolveInSameRequest quota is defined here

specifying the maximum number of product line items that can be created and resolved in a basket within a single request. The described problem (looping add/remove) is a classic example of how this quota is violated.

3. Salesforce B2C Commerce Architect B2C Commerce Functional

Courseware (e.g.

ARCH300): Official course materials for the B2C Commerce Architect certification explicitly cover performance best practices and adherence to platform quotas. They recommend using the transaction rollback pattern for temporary calculations on the basket to prevent performance degradation and avoid hitting governance limits like the one described.