Page History

...

The following terms play a role within persistency management in Blueriq and will be discussed in this design guide:

...

Aggregates

Within Dynamic Case Management solutions, multiple cases can work with a common set of shared information. Organizations usually offer more than one product or service to their customers. All these products and services have their own cases, so multiple cases can be running concerning the same customer. To get a good overview of a customer there is a need for shared storage of information, which is shared among the several cases. Ta accomplish this, the concept aggregate is introduce in Blueriq.  See the example below.

Shown above are three different cases that are all part of a single business model of an a fictitious insurance company, one about . The first case concerns a medical insurance, one about the second a dental insurance and one about the third a home insurance. These cases use and share information. The medical and dental case both use the medical information and the person information about persons, whereas the home insurance makes use of the person information and house information about houses. These information objects are called aggregates in Blueriq and will typically exist of a couple of entities with their endogenous relations.

The reason that different aggregates can be created has to do with design, reuse as well as performance. It makes no sense to use information about a house when deciding about a dental insurance. On the other hand, it is not wanted that a medical insurance case and a dental insurance case each use their own medical information. Finally, unnecessary information used in a case will result in unnecessary actions that will have a negative impact on performance.

...

Lists

Aggregates - like instances, tasks and cases - can be viewed in a list. A standard container AQ_Aggregate_List is available which can be used to display aggregates in run time.

Create/Read/Update/Delete

Working with aggregates

In order for an end user to work with aggregates in cases, these aggregates must be displayed in a list. This list functionality is very similar to the list functionality that is already available for instances, tasks and cases. By creating different aggregate lists for different purposes, the end user will work with only the aggregates that are relevant for him. Furthermore, since only a specific set of data from these aggregates is retrieved from the database while displaying them - and not all aggregates completely all the time - this will boost performance.

In order for the business engineer to create meaningful aggregate lists, custom metadata attributes can be added to the aggregate definition. A custom metadata attribute is defined by an expression that uses relations and attributes that are directly or indirectly part of the aggregate definitionFor each CRUD-action a standard service is available.