Derive Aggregate Entities
The Derive Aggregate Entities batch derives the aggregate entities that are affected by changes made on the listed sObjects.
A change can be any of the CRUD operations, where a new entity is created, modified, or deleted from the system. CRUD operations mark the catalogs or the offers affected by this change and derive the type of the affected change. This information is the data set on which the regenerate batches operate. This batch derives the impacted offers and types of cache data affected by the change. Changes are classified into the following categories:
-
Offer: Any change affecting the profile of an offer is considered an offer type change. These types of changes include changes in description, name, etc.
-
Hierarchy: Any change in the product structure or product child item is considered a hierarchy change.
-
Price: Change in the price list entries is a price type change.
-
Promotion Wapper: The promotional wrapper is by any changes in the promotion or promotional product for a simple promotion type.
There are two levels of changes according to the type of cache data populated:
-
Catalog level change: Affects the cached list of offers under a catalog. For example, if a new product was added to the catalog, then the cached data of the paginated offers list, catalog data profile, and context eligibility lists need regenerating.
-
Offer level change: Affects the details of an offer. For example, if a price list entry was changed, then the affected cache entry becomes the price of that offer.
This batch job has the derivation logic driven by the way cache data is populated in the cached API response objects. Offer level cache data includes itemDetails, priceResults, hierarchy, and catalog level cache data.
Catalog level cache data includes contextEligiblityResultItem, item list, etc. A change in an offer impacts the cache data and its ancestors, as well as the promotions or any of its ancestors that are promotional items. This occurs because the offer details are cached against an offer with its full hierarchy, including the details of its children. If any part of the child product model has been modified, the offer details of all the offers that include the child product need to be regenerated.
There are changes that could impact the offers listing, such as a product that has been made inactive. In that case, the inactive product needs to be removed from all the listings under the catalog, including the cache for the catalog profile, the eligibility lists for different context combinations, and the Contains Offers sets.
With versioning enabled, the product can have different versions with the same offer code in different time frames. Therefore, other than the derivations performed on the basis of the type of sobject that was changed, the Derive Aggregate Entity batch job considers the reference type of the object:
-
Fixed reference: sObjects that are linked to only one version of the product.
-
Floating: sObjects that are linked to all the versions of the product.
-
Hybrid: sObjects that are linked to multiple versions of the product, depending on the use case.
The data model change in the cached API response offer includes an offerId column in the cached API change object. When deriving the impact of the change in an object of type fixed reference, the system includes the offerId of only that offer, along with that offer code, in the cached API change table. A snapshot of the cached API change table looks as follows:
| Code__c | OfferId__c | CodeType__c | ChangeType__c | isProcessed__c | Description |
|---|---|---|---|---|---|
| productA | prod1Id | offer | offer | FALSE | Derived entities as the impact of that change |
| prod1Id | null | data | offer | TRUE | Entry for change registered while modifying the product A description |
If there are changes to the sObjects that are floating references to products, then all the versions of that product are impacted because of that change. In that case, the offerId is null. For example, if the catalog product relationship has been deleted, then all the versions of the product need to be removed from the offers listing, contains offers list, offerdetails. Hierarchy cache data needs to be deactivated. The snapshot of the cached API change table then looks as follows:
| Code__c | OfferId__c | CodeType__c | ChangeType__c | isProcessed__c | Description |
|---|---|---|---|---|---|
| catalogA | null | catalog | offer | FALSE | Catalog level change, all time slices are affected |
| productA | null | offer | price | FALSE | All prices for that offer across all versions are impacted |
| productA | null | offer | hierarchy | FALSE | All hierarchies for that offer across all versions are impacted |
| productA | null | offer | offer | FALSE | All offer details for that offer across all versions are impacted |
| catalogProductrelationshipId1 | null | data | offer | TRUE | Entry for change registered while modifying the productA description |
With versioning and time slicing at the catalog level and batch cache population at the offer level, changes in EPC can cause a conflict with time slices, leading to the need to recompile the time slices. Recompile/regeneration of the time slices at the catalog level and the offer level can occur when:
-
There is a change to the version effectivity date of the child product or the root product.
-
A new product is added to the catalog with no overlapping time slices.
-
A new child product is added to the hierarchy of a catalog product.
To accommodate the Recompile/regeneration of the time slices in any of the above scenarios, the Derive Aggregate Entity batch job processes the entities impacted by the time slices. The change type TimeSlice is added to the picklist value of the changeType and change objects are populated accordingly.
The following table is a database snapshot for the scenario where the version effectivity of the root product is changed:
| Code__c | VersionId__c | CodeType__c | ChangeType__c | isProcessed__c | Description |
|---|---|---|---|---|---|
| catalogA | timesliceKey1 | catalog | offer | FALSE | Catalog level change impacting time slice 1 |
| catalogA | timesliceKey2 | catalog | offer | FALSE | Catalog level change impacting time slice 2 |
| productA | prod1Id | offer | offer | FALSE | Effectivity of version 1 of productA is impacted |
| prod1Id | null | data | offer | TRUE | Entry for change registered while modifying the productA description |
In the above scenario, when the start and end date of the root product are changed and published, the type of change populated is still a product2 object. When deriving the impacted entities, the batch job gets the cached version information of that product and matches the current version information. If there is a mismatch, then based on the time slice information generated for that catalog, the batch job determines which time slices are impacted and need regenerating, and marks those time slice changes for the catalog as an impacted entity. That change will be later picked by the catalog level batch and those time slices will be regenerated.
When the version effectivity of the child product is changed, the change is still a product2 change. In the cached API change object, the product2Id of the object is registered as the change object. During the derivation step for this child product, the system determines which are the ancestors which are the catalog products, gets the time-slice information for each of them by querying the hierarchyResult type, and gets the effectivity dates. Using those time slice dates and current version dates of the child product, the system determines if any time slice for the product is impacted. If so, the corresponding cache objects are populated.