In some cases, your product catalog may contain multiple SKU items that are variations of the same product. For example, the same rubber boots may be available in different colors. To simplify the display of such product data in results lists, you can configure an aggregated record to represent the product in general, and member records of the aggregated record to represent the different SKU items.
Aggregated records can be accessed through keyword search or Guided Navigation in the same way that other types of records can be accessed.
Aggregated records appear in results lists. The number of member records that appear with each aggregated record in the results list is configurable. Typically, a single member record is included; this record is known as the representative record. See the following section for information about how to configure aggregated records.
You can configure some or all properties of this record to be
available to your front end application for display by configuring the
defaultFilterState
bean in a file named
assembler-context.xml
(see below).
Your front end application determines how the aggregated record and the member record returned with it are displayed.
For example, suppose that your data includes several records representing different SKU items that belong to a single product such as "Frederick's Castaway Boat Shoe". The records representing the SKU items contain product information about the different versions of this product, distinguished by size, color, and other qualities. In this case, you can configure an aggregated record to represent the product "Frederick's Castaway Boat Shoe" and a member record to represent each version (SKU item) of this product.
If your query returns "Frederick's Castaway Boat Shoe" and you then refine your search further -- for example, by selecting a color -- some member records may be removed from the aggregated record. For example, if you select "brown", all member records that represent Frederick's Castaway Boat Shoes in colors other than brown are removed. Thus, the actual set of member records varies at runtime, depending on the current navigation state. If more than one member record reflects that state, the system chooses which member record to return.
The following diagram illustrates how an aggregated record
is configured by
assembler-context.xml
and the JSON document that
configures properties:
To configure an aggregated record, follow these steps:
In the
defaultFilterState
bean ofassembler-context.xml
, specify the name of the record property that will serve as the rollup key. All records that have the same value for their rollup key property will be members of this aggregated record.You can specify only one rollup key per application. A version of
assembler-context.xml
is provided with the Discover Electronics reference application in the folderC:\Endeca\ToolsAndFrameworks\11.2.0\reference\discover-electronics\WEB-INF
.Note
If no rollup key property is configured, properties of the member records are returned with the aggregated record, rather than with the member records to which the properties belong.
A record property that will serve as the rollup key. The name of this property must be the rollup key name specified in
assembler-context.xml
(here,product.code
). The definition of the rollup key property must include the parameter"isRollupKey" : true
.
For information about how to configure relevance ranking for aggregated records, refer to the Oracle Commerce Guided Search MDEX Engine Developer's Guide.
You can optionally configure a derived property to add to an aggregated record. You configure the value of the derived property to be the minimum, maximum, sum, or average of the values of a specified property of the member records.
The value of a derived property is calculated at runtime. If you refine your search by clicking additional or different dimension values, the value of the derived property is recalculated to reflect the resulting changes in the set of member records.
The following diagram illustrates the changes that you must make to
assembler-context.xml
and the JSON document that configures properties to configure
an aggregated record with a derived property:
To add a derived property to the configuration of an aggregated record, follow these steps:
Configure a property whose values -- in one or more records -- will be the basis on which the value of the derived property is calculated.
Configure a property whose
derivedPropertySource
parameter specifies the record property whose value will be taken into account when the value of the derived property is calculated. This is the derived property.
For example, suppose that the member records for an aggregated record
representing "Frederick's Castaway Boat Shoe" have the following values for
their
product.price
property: 24.00, 89.95, and 120.00. At
runtime, the
product.min_price
property of the aggregated record
will be set to 24.00, the lowest of the three prices.
Note
Derived properties cannot be used for record sorting.
In
assembler-context.xml
, you can also configure:
To configure the number of records returned with the aggregated
record, specify ALL, ONE, or ZERO as the value of the
subRecordsPerAggregatedRecord
in the
resultsListDefaultConfig
bean:
<bean id="resultsListDefaultConfig" scope="prototype" class="com.endeca.infront.cartridge.ResultsListConfig"> ... <property name="subRecordsPerAggregateRecord" value="ONE"/> ... </bean>
For most purposes, you should set
subRecordsPerAggregatedRecord
to ZERO or ONE. Setting it
to ALL will cause all member records to be returned with the aggregated
records; if there are a large number of member records, the system's
performance may be slowed significantly as a result.
You configure which properties of an aggregated record and of its
member records will be available to your front end application by listing these
properties in the
resultsListDefaultConfig
bean. List properties of
aggregated records in the
fieldNames
element and properties of member records in
the
subRecordFieldNames
element:
<bean id="resultsListDefaultConfig" scope="prototype" class="com.endeca.infront.cartridge.ResultsListConfig"> <property name="fieldNames"> <list> <value>product.id</value> <value>product.code</value> <value>product.name</value> <value>product.brand.name</value> ... </list> </property> <property name="subRecordFieldNames"> <list> <value>product.price</value> </list> </property> </bean>
Note
All properties are returned with the aggregated record if you do
not specify properties in the
fieldNames
element or omit the element itself, or if
you do not specify a rollup key.