You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.

What is it for?

Aggregates are used for storing a snapshot of the profile or a part of the profile, that can be read, updated and/or deleted across sessions. You might compare it to the way information in a NoSQL database is stored. Avoid using aggregates in the same way tables in an SQL database are used.

What is it?

A set of entities can be declared as an aggregate. This means that they belong together and should always be stored and loaded together. Only the user-set values of attributes and relations are stored.

This page explains how to define an aggregate, i.e., which entities and relations should be stored and loaded together in an aggregate.

In the aggregate definition, relations are automatically followed and all entities that are connected to the entity by means of relations are automatically part of the aggregate, as well as all relations between these entities. The relations can be excluded from the aggregate definition, which means also entities connected to that relation are excluded. Relations cannot exist between aggregates, only within them.

Only the To-relations are followed automatically, not the backward (reverse) relations.

Abstract entities cannot be added to an aggregate.

Shown below is the aggregate definition of an aggregate PersonAggregate. The definition only contains the entity Person, but in fact all Jobs that this Person has are part of the aggregate as well. Instances of the relation HasJobs are used and stored as a connector between the instance Person and the instances of Job.

What does it do?

Where an entity divides the main model into main ‘subjects’, an aggregate groups some of these main subjects together into a coherent set. These entities can be added using the +Add entity button. Remove unwanted relations (and connected entities) from the aggregate definition using the toggle. The list of included relations is updated after each toggle update.

Please note that any relations to instances that do not belong to the aggregate are cleared, and are not recreated when loading the aggregates.

Custom metadata

In the Custom metadata section, custom metadata can be specified for an aggregate using expressions.

Custom metadata can be used to identify aggregates or provide overview information. This metadata can be used as a condition in an Service call type: AQ_Aggregate_Search or be displayed in an Container type: AQ_Aggregate_List.

Custom metadata can not be used in the same way that attributes can be used. This custom metadata can be seen as identifying attributes for an aggregate, but are not necessarily unique. The Person aggregate could have the following custom metadata attributes: FullName, Age. Custom metadata for an aggregate can originate from different entities, or even be a complex expression, for example NumberOfJobs is calculated as SIZE(Person.HasJobs).

You may be tempted to add as much metadata to an aggregate as possible, as these can be shown in lists later on. We strongly advice against adding metadata only for 'just in case'. Each metadata attribute creates an entry in the database when an aggregate is stored. The more metadata fields are added, the quicker entries are made in the database which at some point may impair the performance. Therefore, we advise the following:

  • Only add metadata if this really describes meta information of the information stored in the aggregate.
  • Try to not add more than 10 metadata fields per aggregate
  • Plan and execute performance tests with large database fillings before bringing your application to production.

Please see Runtime performance reports for how we test the performance of our reference application.

Roles

In the properties panel, the authorization on aggregates can be configured. The roles you set are authorized to perform operations on aggregates of this type. When a role is authorized, a user with that role is able to create, read, update and delete aggregates of this type. It is not possible to make this authorization more specific, e.g. to only allow read access. If there are no roles configured on an aggregate, then everyone is authorized.

All AQ_Aggregate_* services take this authorization into account and take the Unauthorized exit if a user is not authorized.

More about aggregates and persistency management in the Persistency Management guide.

Creating, reading, updating, deleting, searching and counting (CRUD-SC)

Aggregates are managed using the following service calls:

Each aggregate has an ID (part of the default metadata) that uniquely identifies the aggregate. When creating (=storing) or searching for an aggregate, its ID is saved into a selected attribute. Read, update and delete operations then use this attribute to identify which aggregate to perform the operation on.

Showing aggregates

A list of aggregates (that is, a list of instances of an aggregate type) can be shown on a page by using the Container type: AQ_Aggregate_List. This container can show metadata (standard and custom), filter on metadata, and show buttons to act on one particular aggregate.

Statistics about aggregate instances can be shown using the Container type: AQ_Statistic_Aggregate , which has to be placed inside of a Container type: AQ_Statistic_Visualization. 

  • No labels

Didn't find the answer you were looking for? Try the advanced search!