Page History

When an aggregate is updated, it is marked as changed for the search functionality, and is indexed at the next synchronization moment (How to configure full-text index synchronization). There exist two scenarios in which you want to start the indexing manually, without updating the stored aggregate itself.

1. In case you You are upgrading to version 9.7 or higher and want to benefit from the full text search the . The aggregates that you already have stored in database must be indexed.
2. In case that all All your aggregates already are indexed and a new version of the model is published to production wit new business logic, you want to re-index all aggregates so that changed derived values that are changed with the new logic can be found during the search.

This article describes a strategy that allows you to manually index aggregates in an automatic manner.

As it is important that also system set attributes are indexed, this cannot be a database operation, and a filled runtime profile is needed. For filling the runtime profile, a migration flow is needed that loads the needed information so that the rule engine can derive all values. Once that is done, a service is needed to indicate that the current profile should be indexed, and that it belongs to an existing aggregate. The AQ_Aggregate_Update service with the CreateNewVersion to FALSE is sufficient for this purpose in most scenarios. These scenarios are

• Versioning on aggregates is not used, and there always is only one version for each aggregate Id.
• Versioning is used, and you want to update the index for only the newest latest version.

The scenario in which this service does not suffice is that you want to (re-)index older versions of an aggregate. This can be needed as an specific old version of an aggregate can be referenced from another aggregate. (Re-indexing )Indexing the old aggregate version has to be conscious choice, and you might wish to keep the old index like it is for that older versions. An aggregate that was created in an old version and was indexed using the logic that was valid at that moment of time, so these may belong together. This can be a reason for only (re-)indexing the most recent version of aggregates.

...