|Data Feeds functionality is in a pre-release stage and not generally available. The functionality as well as this documentation is subject to change.
While DataFeedServices documentation covers Data Feed concepts in great detail, this section will discuss common data feeds related functionality affecting other microservices.
As discussed here, partial update processes are designed to keep feeds up-to-date in between the more comprehensive full process runs. For example, when a product changes in price or goes out of stock, it’s often important to ensure those changes are reflected in data feeds quickly.
To achieve this, Broadleaf has a concept of 'Incremental Entity Update Events'.
On production-level (non-sandbox-level) changes to certain data, services such as CatalogServices will emit an
IncrementalDataFeedEntityUpdateEvent message for consumption by DataFeedServices.
The contents of this message mainly just include the unique reference value for the entity which was updated and requires reprocessing.
Upon receipt of this message, for any active partial
DataFeedProcess that may be interested in that event (ex: processes in the same tenant, same application), DataFeedServices will create a new
IncrementalDataFeedEntityUpdateRecord (see these docs).
When each partial
DataFeedProcess is next executed, DataFeedServices will gather all
IncrementalDataFeedEntityUpdateRecords that have accumulated since the last execution and reprocess the entities referenced within.
This design essentially follows the 'transactional inbox' microservices pattern.
For services that need to notify DataFeedServices of interesting update events, Broadleaf’s DataTracking common library (since version
1.7.21) enables the necessary functionality.
Whether to enable Data Feed related functionality in DataTracking.
|Typically, this component can be left as-is and does not require customization.
This is a component that listens for
MutationNotifyEvent Spring Application events, which are published on updates to entities.
DataFeedInspection components, and for the first
DataFeedInspection that deems the entity changes of a
MutationNotifyEvent relevant, it will emit the appropriate
|A new implementation of this interface should be registered as a bean for each entity whose changes should be monitored for data feeds.
Responsible for determining whether an entity change is interesting from a data feeds perspective, and building the appropriate
IncrementalDataFeedEntityUpdateEvent payload if so
Implementations should typically extend
AbstractDataFeedInspection as a base starting point
The InventoryServices implementation is different as it only partially uses the DataTracking patterns and does not leverage the standard
A special component that listens for
InventoryAvailabilityEvent Spring Application events, and then delegates to the DataTracking
DataFeedMutationHandler to send the