You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.
Creating and updating aggregates
When creating or updating an aggregate, a snapshot is made of the current profile that includes instances of all entities defined in the aggregate, and all those instances' relations that were included in the aggregate.
By default, all instances of singleton entities are included and no instances of multiton entities are included. The StoreInstances parameter is used to define which multiton instances are stored in the aggregate. The unique Id of the created aggregate will be saved in a selected attribute. This Id can then be used in other services to Read, Update or Delete the aggregate.
If the attribute selected for the AggregateId is not part of a singleton then the target instance parameter can be used to select the instance on which the aggregate Id must be stored. If the target instance has no value, then it is assumed that the selected attribute either belongs to a singleton entity, or that there is an active instance present. If not, an error is thrown. The target instance must be single valued.
This service will update an aggregate based on an aggregate type and Id. This service consults the database of stored aggregates. It will update the entry with the provided Id. If the Id is not present in the database, the IDError exit is taken. In case of versioned aggregates, a new version is created with a higher version Id. The old version can still be accessed when needed.
Parameters
Name | Direction | Description | Type | Occurrence | Required |
|---|---|---|---|---|---|
AggregateType | Input | Select the aggregate you want to update. This is a list of the aggregates definitions. | Aggregate | Single valued | Yes |
AggregateId | Input | The attribute that holds the ID of the aggregate you want to update. | Integer | Single valued | Yes |
CreateNewVersion | Input | Specifies whether the update creates a new version (true) or overwrites the existing version (false). | Boolean | Single valued | Yes |
VersionIDOutput | BiDirectional | The attribute on which you want to store the version Id of the update. | Attribute | Single valued | No |
TargetInsance | Input | The instance on which the Id of the version that is to be updated will be stored in the attribute mentioned in VersionIDOutput. | Expression resulting in an attribute | Single valued | No |
StoreInstances | Input | The starting point instance(s) for storing. | Expression(s) resulting in instance(s) | Multi valued | No |
User-set vs system-set
When updating an aggregate, only values that are user-set are stored, all system-set values are not stored. The data of the aggregate is stored in a xml blob.
Default metadata
Updating an aggregate stores also a set of metadata information in the database:
Field | Type | Description |
|---|---|---|
LastUpdatedByUsername | String | User name of the person/system that updated the aggregate |
LastUpdatedByID | String | Unique Id of the user. A user name can have duplicates, the user Id makes the user unique |
LastUpdated | Datetime | Update time stamp of the aggregate |
Latest | Boolean | Specifies whether the aggregate is the latest version |
Version | Integer | Version of the aggregate |
Events
This service uses default events for a commit and for an exception. The IDError exit should be mapped to a custom event and will be triggered when the given AggregateId cannot be found.
The Unauthorized exit is triggered when the user does not have one of the roles that is set on the aggregate definition.
Example
Below an example is given for an update service with versioning.
Service call definition
| |
Aggregate definition
| |
Visual overview of aggregate concepts
Aggregate
|
Overview
Content Tools