If you want to use incremental loading, there are two additional properties that need to be set on your IndexingOutputConfig component:

The IncrementalLoader component uses an implementation of the PropertiesChangedListener interface to monitor the repository for add, update, and delete events. It then analyzes these events to determine which ones necessitate updating XHTML documents, and creates a queue of the affected repository items. When a new incremental update is triggered, the IncrementalLoader processes the items in the queue, generating and loading a new XHTML document for each changed repository item.

Using Monitored Properties

By default, the IncrementalLoader determines which changes necessitate updates by monitoring the meta-properties and text-properties specified in the XML definition file. In some cases, however, the properties you want to monitor are not necessarily the ones that you want to output. This is especially the case if you are outputting derived properties, because these properties do not have values of their own.

For example, suppose your user item type has firstName and lastName properties, plus a fullName derived property whose value is formed by concatenating the values of firstName and lastName. You might want to output the fullName property, but to detect when the value of this property changes, you need to monitor (but not necessarily output) firstName and lastName.

You can do this by including a monitor element in your definition file to specify properties that should be monitored but not output. For example:

  <property name="fullName"/>
  <property name="firstName"/>
  <property name="lastName"/>

For information about derived properties, see the ATG Repository Guide.

Tuning Incremental Loading

The number of changed items that accumulate in the queue can vary greatly, depending on how frequently your data changes and how long you specify between incremental updates. Rather than processing all of the changes at once, the IndexingOutputConfig component groups changes in batches called generations. Each generation is processed as a separate ATG Search job.

IndexingOutputConfig has a maxIncrementalUpdatesPerGeneration property that specifies the maximum number of changes that can be assigned to a generation. By default, this value is 1000, but you can change this value if necessary. Larger generations require more ATG platform resources to process, but reduce the number of ATG Search jobs required (and hence the overhead associated with starting up and completing these jobs). Smaller generations require fewer ATG platform resources, but increase the number of ATG Search jobs.

loading table of contents...