Persistency Management guide [editor]

Table of contents

Persistency management

Persistency management is the term used in Blueriq to address everything that has to do with persisting (or saving, storing) information and later on retrieving, displaying, updating and deleting this information.

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

• Aggregate definition
• Entities, attributes and relations
• Lists of aggregates
• Standard meta data
• Create, read, update and delete

In future versions, the following functionality will be available and subsequently described here:

• Non-singleton aggregates
• Custom meta data
• Versioning
• Precise aggregate definition
• References between aggregates
  
  

Aggregates

Within Dynamic Case Management solutions, multiple cases can work with a common set of shared information. See the example below.

Shown are three different cases that are part of a single business model of an insurance company, one about a medical insurance, one about a dental insurance and one about a home insurance. These cases use and share information. The medical and dental case both use the medical information and the person information, whereas the home insurance makes use of the person information and house information. 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.

Aggregate definition

So, aggregates are used to combine information that belongs together. In Blueriq, information that belongs together is modeled in an entity. Aggregates simply combine entities.

An aggregate typically consists of a couple of entities with their endogenous relations. At the moment, only singleton entities can be added to an aggregate definition, but all non-singleton entities that are connected to the singelton are part of the aggregate as well. Also, at the moment it is not possible to create a precise aggregate definition, excluding for instance a few attributes and relations. Shown below is the design of the aggregate Person information.

As mentioned before, at the moment an aggregate definition can contain only singletons. The design of the aggregate Person information will therefore only consist of entities Person and CurrentEmployment. However, the entity Person has relations with the non-singleton attributes Job and Household, so whenever a person is stored, his or her jobs are also stored, as well as the person's household situation.

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

For each CRUD-action a standard service is available.