Broadleaf Microservices
  • v1.0.0-latest-prod

Upgrade to 1.8.6

December 20, 2023

Overview

This release contains the same enhancements and bug fixes as the 2.0.0-GA Release, except this release does not contain any of the Spring or Java upgrades that are part of the 2.0.0 release.

Notable Changes

Dynamic Customer Segments

Introduced support for evaluating rule-based Customer Segments in real time rather than online in offline, asynchronous processes. This includes new evaluation-type field used to distinguish the old rule-based segments where the rules are evaluated offline and against the customer table and the new type where the segments are evaluated in real-time against the current customer and request context. Additionally, ContextInfo now has a customerSegmentIds field to store the list of active customer segments.

Important
 This new field is only hydrated on requests to Cart Operations and Catalog Browse services by default. These services hydrate the data on incoming requests and use it to build out the Customer Context, Content Context, and Price Context headers. This is done in only these two services because they are intermediaries to commerce frontend requests and are able to centralize all the required information for evaluating rule-based Customer Segments and cache the results.

See release notes of other services for details on changes:

  • Customer Services 1.8.11

  • Customer Client 1.0.0 (New)

    • This will be automatically included when upgrading the Release Train version.

  • Cart Operation Services 1.8.13

    • broadleaf.cartoperation.customer-segment-provider.url should be modified for each environment and flexpackage configuration to point to the Customer Service:

    • Any custom or extended endpoints should be annotated @DataRouteByKey(RouteConstants.CARTOPS_ROUTE_KEY) in order for the customer segment IDs to be hydrated onto the context info.

  • Catalog Browse Services 1.8.7

    • broadleaf.catalogbrowse.customer-segment-provider.url should be modified for each environment and flexpackage configuration to point to the Customer Service:

    • Any custom or extended endpoints should be annotated @DataRouteByKey(RouteConstants.BROWSE_ROUTE_KEY) in order for the customer segment IDs to be hydrated onto the context info.

  • Data Tracking 1.7.25

    • This will be automatically included when upgrading the Release Train version.

  • Authentication Services 1.8.14

    • New permissions and scopes have been added and should be inserted into the auth database with the following SQL:

      -- New scopes and permissions for Cart Ops and Catalog Browse clients

INSERT INTO blc_client_permissions (id, permission) VALUES ('cartopsclient', 'READ_CUSTOMER_SEGMENT');
INSERT INTO blc_client_permissions (id, permission) VALUES ('catalogbrowseclient', 'READ_CUSTOMER_SEGMENT');

INSERT INTO blc_client_scopes (id, scope) VALUES ('cartopsclient', 'CUSTOMER_SEGMENT');
INSERT INTO blc_client_scopes (id, scope) VALUES ('catalogbrowseclient', 'CUSTOMER_SEGMENT');

Disabling

This feature can be disabled by setting broadleaf.cartoperation.dynamic-customer-segments.active=false and broadleaf.catalogbrowse.dynamic-customer-segments.active=false in the appropriate flexpackage, or if Browse and Cart Ops are in the same flexpackage just set broadleaf.dynamic-customer-segments.active=false to disable both. You can also hide the option in the admin UI to create dynamic segments with broadleaf.customer.metadata.enable-dynamic-customer-segments.

broadleaf:
  catalogbrowse:
    dynamic-customer-segments:
      enabled: false
  cartoperation:
    dynamic-customer-segments:
      enabled: false
  customer:
    metadata:
      enable-dynamic-customer-segments: false

Fixed bug where users in multiple Customer Segments would not see Content Zone Items applying.

This was caused by incorrect metadata configuration causing the display rule to use a contains instead of a containsAny (intersection) comparison between the list of targeting Customer Segments and the list of the current user’s actual segments.

Tip

A migration script is included with the upgrade to correct any existing rules and will be automatically run by liquibase. Also provided here for convenience.

-- liquibase formatted sql
-- changeset broadleaf:content-zone-item-display-rules-migration

UPDATE BLC_CONTENT_ZONE
SET ALTERNATE_ITEM_SETS =
    REGEXP_REPLACE(ALTERNATE_ITEM_SETS,
        'contains(.customer\?\.customerSegmentIds)',
        'containsAny(customer?.customerSegmentIds');

UPDATE BLC_CONTENT_ZONE
SET DEFAULT_ITEMS =
    REGEXP_REPLACE(DEFAULT_ITEMS,
        'contains(.customer\?\.customerSegmentIds)',
        'containsAny(customer?.customerSegmentIds');

Endpoint Versioning

As part of this release, there was a bug in one of the API endpoints in OrderService, which required an update to the request body and therefore would require a change of method signature. To fix the bug while maintaining the backwards compatibility of Broadleaf’s API contract, using a version header Accept-Version=2 was determined the best approach for this release.

See Order Services 1.8.10-GA Release Notes for more details

Properties to Control Tax Response Payload

Introduced properties to control whether the tax response payload should be persisted, to fix the bug where the tax payload can be too large when using Avalara, causing message failures.

See Cart Operation Services 1.8.13-GA Release Notes and Delegating Tax Service Properties for more details

Frontend Compatibility and Release Notes

Microservices release 1.8.6 is congruent with:

Service-level Release Notes

Services

Common Libraries