- v1.0.0-latest-prod
Cart Operations guides the workflows for cart and checkout but does not provide facilities for pricing, inventory checks and reservations, or persistence out-of-the-box. Instead, it relies on various integration hook-points called "providers" to handle those functions.
For tax calculation specifically, see TaxService, which delegates to a TaxProvider.
By default, Cart Operations does not persist catalog, pricing, inventory, or tax data. It delegates these lookups to downstream services using one of two communication modes:
The default provider implementations (e.g., ExternalCatalogProvider, which extends AbstractExternalProvider) communicate via REST.
Transport: Configured using Spring WebClient.
Context Propagation: Automatically forwards contextual headers, such as locale, preview token/date, and tenant/application metadata (ContextInfo), to the downstream endpoint.
Authentication: Each provider authenticates to its downstream service using its own registered OAuth2 client credentials (client_credentials grant, one registration per downstream service) — the original caller’s token is not forwarded.
Custom Endpoints: These providers can point to non-Broadleaf endpoints by adjusting standard Spring HTTP client properties.
When services are bundled together in a single deployment package (a FlexPackage), network hops can be bypassed.
Interlink Interactions: If Cart Operations is co-located with target services (such as Catalog or Pricing), the providers use Broadleaf Interlink beans to make direct JVM method calls, avoiding HTTP serialization overhead.
Integration strategies are configured independently for each business domain. There is no single mandatory topology. Each domain can adopt one of four integration patterns based on business and performance needs:
Broadleaf itself is the service being called, and it is the master system of record for that business domain’s data — no projection or cache sits in front of it, so every operation is a live call directly against it.
Example use case: Cart data.
CartService owns and persists the Cart/CartItem records; Cart Operations doesn’t replicate or cache this state itself, and instead calls into CartService live for every cart read or mutation via the CartProvider.
The external system is the system of record. Broadleaf holds a near real-time synced projection of the data for fast read performance.
Example use case: Inventory availability. Both availability checks during add-to-cart and reservations during checkout are made directly against Broadleaf’s synced inventory projection; the reservation is synced back to the external warehouse system afterward, rather than calling out to it synchronously at reservation time.
A synchronous, real-time call is made directly to an external API. Data is not replicated in Broadleaf.
Example use case: Pricing. Cart Operations recalculates pricing via a live call on every relevant cart modification.
The provider is deactivated.
Example use case: Payment. When charges aren’t collected through Broadleaf at all — for example, where order totals are instead passed to a downstream invoicing system for billing.