Introduction

As mentioned in the chapter about searching for aggregates in the Persistency Management guide, searching for aggregates may not always be designed in the same manner. Four strategies are discussed there.

This How to article focuses on the strategy of searching for aggregates with the AQ_Aggregate_Search service.

Example

A simple example is used about a music database with one aggregate type: Musician. What entities and endogenous relations this aggregate might have, is not important. It suffices to know that the standard meta data consists of

• Aggregate Id
• Aggregate version Id

The custom meta data consists of

• An uniquely identifying number (music database number),
• A single valued metadata field with the full name of the musician (including middle names)
• The band the musician plays in, if applicable.

Aggregate search configuration

Shown below is the screen for the AQ_Aggregate_Search service.

Parameters

In Service call type: AQ_Aggregate_Search all parameters are discussed. In this article, the focus is on the following parameters:

• Target entity
  Select an entity in which you want to store the aggregate ID and version. If this entity is a multiton, an instance is created for each found aggregate and the next two parameters will contain single values. If this entity is a singleton, no instances will be created and the next two parameters will be used to contain Id and version of the found aggregates.
• Target attribute for aggregate ID
  Select an attribute of the aforementioned entity on which you want to store the found aggregate Id.
• Target attribute for version ID
  Select an attribute of the aforementioned entity on which you want to store the found version Id.
• Only search for latest version
  Check when only latest versions of versioned aggregates are searched.

Use cases

Below four use cases are discussed, by explaining which parameters to use with which configuration. Also the outcome of the search service is predicted. With these use cases, a business engineer should be able to model all types of searches.

• The search criterion is Band = "Beatles"
• We expect multiple aggregates, each with only a single version
  • The target entity Control is singleton
  • The target attribute for aggregate Id Control.AggregateId is multivalued
  • Target attribute for version Id Control.VersionId is omitted
  • Only search for latest version is checked
• The search result will yield four aggregates
  • 1 - John Winston Ono Lennon
  • 2 - James Paul McCartney
  • 3 - Ringo Starr
  • 4 - George Harrison
• The singleton entity Control will have the following values
  
  • Control.AggregateId has value [1,2,3,4]
  • Control.VersionId has value unknown

• The search criterion is MusicDbNr= 14

• We expect one aggregate with multiple versions
  • The target entity Control is singleton
  • The target attribute for aggregate Id Control.AggregateId is single valued
  • Target attribute for version Id Control.VersionId is multivalued
  • Only search for latest version is unchecked
• The search result will yield one aggregate with two versions
  • 3 - 1 Richard Starkey
  • 3 - 2 Ringo Starr
• The singleton entity Control will have the following values
  • Control.AggregateId has value 3
  • Control.VersionId has value [1,2]

• The search criterion is Full name = "Dob Dylan"

• We expect one aggregate with one version
  
  • The target entity Control is singleton
  • The target attribute for aggregate Id Control.AggregateId is single valued
  • Target attribute for version Id Control.VersionId is omitted
  • Only search for latest version is checked
• The search result will yield one aggregate:
  • 5 - Bob Dylan
• The singleton entity Control will have the following values
  • Control.AggregateId has value 5
  • Control.VersionId has value unknown
• If for some unexpected reason there are two Bob Dylans, the service will result in a runtime error, since Control.AggregateId is single valued.
  To avoid this, it could be made multivalued, but this has downsides for understandability and maintenance.
• If we would also like to know what the Id of this latest version is (and start a flow from there), the single valued attribute Control.VersionId could be used as a parameter for that.

• The search criterion is Band = "Beatles"
• We expect multiple aggregates, each with possibly multiple versions
  • The target entity Control is multiton
  • The target attribute for aggregate Id Control.AggregateId is single valued
  • Target attribute for version Id Control.VersionId is single valued
  • Only search for latest version is unchecked
• The search result will yield six instances (instance Id's are normally guids, but simplified here)
  
  • Instance 1111
    
    • Control.AggregateId has value 1
    • Control.VersionId has value 1
  • Instance 2222
    • Control.AggregateId has value 1
    • Control.VersionId has value 2
  • Instance 3333
    
    • Control.AggregateId has value 2
    • Control.VersionId has value 1
  • Instance 4444
    • Control.AggregateId has value 3
    • Control.VersionId has value 1
  • Instance 5555
    • Control.AggregateId has value 3
    • Control.VersionId has value 2
  • Instance 6666
    • Control.AggregateId has value 4
    • Control.VersionId has value 1