- v1.0.0-latest-prod
A Provider for interfacing with a persistence provider for operations directly involving the CustomerSegment domain.
Typically utilizes WebClient to make requests to an external REST API such as to an Customer microservice.
The default implementation is ExternalCustomerSegmentProvider which is configured to communicate with an external microservice.
Implementations should define the following methods:
readDynamicCustomerSegments: Used to read all customer segments that can be dynamically applied under the current context for the current user.
In the default implementation, this is intended to read all rule-based CustomerSegments with an evaluation type of REAL_TIME.
resolveCustomerSegmentsForContext: Used to evaluate dynamic CustomerSegments against a ResolveCustomerSegmentsRequest containing relevant context and user information.
In the default implementation, this sends a request to the Customer microservice to evaluate a prefetched list of segments against the request and is intended to be used in cases where the service using the Customer Client does not have all of the necessary context or user info. This can happen when a Customer Segment rule targets a value not included in the Auth token claims or available as a request attribute such as a registered Customer’s home postal code, which is typically only available in the Customer Service.
This method should be used with caution since it is hard to cache the result and may cause excessive calls to be made to an external service.
See Configuration: External Customer Segment Provider for configuration properties.
Customizer responsible for hydrating ContextInfo#getCustomerSegmentIds().
This will reach out to the configured CustomerSegmentProvider to retrieve any dynamic segments, cache them, then evaluate their rules against the current incoming web request and auth context.
The default implementation builds a ResolveCustomerSegmentsRequest to use as a common evaluation context object. The customer segments are expected to have rules using Spring Expression Language (SpEL), and evaluation is performed using the Broadleaf Rules Engine library.
See Configuration: Customer Segment Resolution for configuration properties.
Represents a request to resolve CustomerSegments matching a given context.
It is expected to contain any useful details about a user to evaluate rule-based segments against.
Available fields
userId: string
username: string
email: string
phoneNumber: string
fullName: string
registered: boolean
accountId: string
rootAccountId: string
In the case where an Account is part of a hierarchy, this will be the ID of the root account in the hierarchy.
accountHierarchy: List<String>
This includes the IDs of all the ancestor accounts of the current one used by the Customer with the current id last in the list.
For example, if we have this account setup, rootAcct → subAcct (child of rootAcct) → subSubAcct (child of subAcct), this field would be [rootAcct, subAcct, subSubAcct].
This is useful to have queries include sub-accounts.
attributes: Map<String, Object>
Additional, arbitrary request attributes.
The attributes included in this map are determined by the list defined by the property request-attribute-list—See Configuration: Customer Segment Resolution.
prefetchedSegmentIdsToEvaluate: List<String>
List of ids of any prefetched CustomerSegments to evaluate whether they apply to the request.
This list will be used instead of looking up all rule-based or directly assigned customer segments.
Typically, this will only include the ids of rule-based segments with evaluation type REAL_TIME as other segments should already be known from the user’s auth token claims and do not require evaluation.