While the cache is being populated in cached API response objects, the system caches metadata information about those cache entries. That information is then used by the regenerate batch job to get the affected cache entries and generate or regenerate the cache data. As a prerequisite to caching metadata, the corresponding trigger setting should be enabled.
With versioning, different versions of the same product use the same offer code where a change in the sObjects can affect:
One version of the cache if it’s a fixed reference.
All versions of the cache if it’s a floating reference.
Some versions of the cache if it’s a hybrid reference.
Caching the metadata in the cached API response offers objects involves a mechanism to:
Link the cache entry with its version: If there are any changes in EPC for the released products that affect only one particular version of the cache entries, then linking the cache entry with its version performs a delta regeneration of the cache entries for that particular offer version. This includes an OfferId column to account for the unique ID of a particular product version.
Link the cache entry with the time slice(s) to which it belongs: If there is any change in the qualifying context rule or rule associations affecting the eligibility of the product, then the catalog level entries (Context eligibility result items, Offers List, etc.) need to be regenerated to include or exclude that product. Having information about the time slices to which offers belong means performing a delta regeneration of only those time slices catalog level entries. This information can be derived from using the VersionInfo list and TimeSliceInfo types of data cached by the version info generator batch