Broadleaf Microservices
  • v1.0.0-latest-prod

Cart Operation Release Notes for 2.1.3-GA

Tip
 The 2.x versions are Spring Boot 3 compatible.
Note
 Includes changes in 2.0.4-GA

Requirements

  • JDK 17 is required for Broadleaf release trains 2.0.0-GA, and beyond.

Important Updates

Spring Boot Upgrade

  • As of Broadleaf Release Train 2.1.3-GA, all microservices have been upgraded to Spring Boot 3.3

New Features & Notable Changes

  • Added a ContextInfo parameter to methods in CartItemConfigurationService to facilitate validation decisions based on multi-tenancy

    • This was done in a backwards-compatible way by calling the now-deprecated versions of the updated methods (without ContextInfo)

    • Note that the method CartItemConfigurationService.validateCartItem(Cart, CartItem, CatalogItemList<? extends CatalogItem>, String) was replaced with the method that has a new ContextInfo parameter. This can cause backward-compatibility issues for clients that have customizations calling this method.

  • Added a flag shouldCalculateTaxes in CartPricingService#calculateTotals to prevent the tax calculation logic from being executed twice during the price cart flow.

    • Also, deprecated the CartPricingService #calculateTotals(Cart, ContextInfo) method in favor of the new method CartPricingService#calculateTotals(Cart, boolean, ContextInfo).

  • Improve logic creating FulfillmentPricingItems in DefaultFulfillmentOptionRequestService.

    • Use typeFactory to create the pricing items

    • Set the sku and inventoryType fields on the objects from cart items

  • Improvements to support the Adyen payment integration

    • Added an ability to send the additional data in the CheckoutProcessRequest, needed to execute payment transactions, esp. properties that should not be persisted to the Payment#paymentMethodProperties. See CheckoutProcessRequest#sensitivePaymentMethodData

  • Enhanced checkout to be more robust by utilizing Spring RetryTemplates to finalize the payments and update the cart. Additionally more logging was added to help debug checkout in case of further issues.

Bug Fixes

  • Populate offerUses field on the Adjustment object when retrieving non-item adjustments from OfferServices using ExternalOfferProvider

  • Fix incorrect quantity validation logic that used counts per sku for bundles, which usually do not have sku fields.

    • Instead, validate quantities for bundles using productIds

  • Fixed the ExternalPaymentInteractionMessagingAutoConfiguration being guarded by the catch-all broadleaf.basic.messaging.enabled property

    • This can cause the listener to not be registered due to the basic messaging being disabled in certain flexpackage compositions (e.g. Cart flexpackage)

    • It can now be enabled via broadleaf.cartoperation.checkout.messaging.active

    • broadleaf.cartoperation.checkout.messaging.active should also be used for CartCheckoutMessagingAutoConfiguration as well for consistent naming, instead of broadleaf.cart.checkout.messaging.active (still usable for backwards compatibility)

  • Resolved a bug where a failed payment transaction causes the PaymentSummary in the CheckoutResponse to be out of date

Important

This release includes a potentially breaking change if you have an override/implementation of one of the following methods:

  • CheckoutService#processCheckout(…​)

  • CheckoutWorkflow#execute(…​)

    • DefaultCheckoutWorkflow#executeActivity(…​) (protected method)

  • RequiresSecurePaymentInformationActivity#execute(…​)

  • PaymentTransactionExecutionService#executeCartPaymentTransactions(…​)

  • DefaultPaymentTransactionExecutionService#executeCartPaymentTransactions(…​) (protected method)

  • DefaultPaymentTransactionExecutionService#executePaymentTransaction(…​) (protected method)

  • DefaultPaymentTransactionExecutionService#buildTransactionExecutionRequest(…​) (protected method)

If this effects your project, you’ll encounter a compilation issue. These compilation issues should be simple to resolve - ie look to gather data from the provided SensitivePaymentMethodData objects, or simply pass them along to the next service component.

In short, these method signature changes within the CartOps were needed to effectively pass the SensitivePaymentMethodData representations through the checkout process, & do so in a way that is very intentional about which components do/do not have access to the data.

This change was also made to future-proof these method signatures by passing objects, rather than simple params.