Page History

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.

In many systems, persistency management is all about databases and SQL-statements. In Blueriq, it is not. We deliberately made the technical way in which data is stored and retrieved not the business engineer's concern, let alone the end user's concern. In stead, Blueriq provides an intuitive canvas where a business engineer can design what information to persist when, also a few services to create, read, update and delete information and a service to display information objects. What happens behind the scenes is, as mentioned before, not of interest to the business engineer.

...

• Aggregate definition
• Entities, attributes and relations
• Create, read, update and delete aggregates
• Lists of aggregates
• Standard meta datametadata
• Custom meta datametadata
• Authorization
• References

Aggregates

...

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

...

Aggregates are used to combine information that belongs together, and should be stored and loaded together. In Blueriq, information that belongs together is modeled in an entity, or as multiple entities with relations between them. An Aggregate is the selection of parts of your domain that can be stored and retrieved together in a single action, and consists of one or more entities. At the moment, only singleton entities can be added to an aggregate definition, but all non-singleton entities that are connected to the singelton singleton 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, in which the aggregate is blue, and the entities that are defined within the aggregate are pink.

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

When storing such an aggregate, metadata is stored as well. This includes standard metadata, such as when the aggregate has been created and who created it, but also custom metadata that the business engineer can define on the aggregate definition by using expressions. This custom metadata are identifying attributes for an aggregate. In the example above, the Person aggregate could have the following custom metadata attributes: FirstName, LastName, SSNSocialSecurityNumber, CurrentJob, HouseholdSize. As you see, custom metadata for an aggregate can originate from different entities, or even be a complex expressions, for example NumberOfJobs is calculated as COLLECT ALL Job FROM Person.HasJobs.

Only the (custom) metadata is available in lists, as this information is stored in an efficient manner. When a new aggregate entry is created or updated, the (custom) meta metadata is updated as well.

Working with aggregates

In order for an end user to work with aggregates in cases, it must be possible that these aggregates are displayed in a list. This could enable the knowledge worker to look for a known person in the system if this person contacts the call center. This list functionality is very similar to the list functionality that is already available for instances, tasks and cases and is implemented as a Blueriq container.

To let the business engineer create meaningful aggregate lists, custom metadata attributes can be added to the aggregate definition . A custom metadata attribute is an attribute that is not necessarily part of the domain and is therefore defined by an expressionand then used as column in the aggregate list.

By letting the business engineer create different aggregate lists for different purposes, the end user will work with only the aggregates that are relevant for him. Since only metadata from these aggregates is retrieved from the database while displaying them - and not all data completely - this will boost performance.

...

There currently is no authorization on aggregate level. This means that you are responsible for prohibiting the end user to load certain aggregates by chosing choosing adequate authorization on a page or at container level.

Migration

When your application changes over time, the migration of data becomes an important topic. Aggregates help you with this, but can not cannot solve all your problems. For complex scenarios it is advised to create your own database scripts for migration purposes. They generally do everything in a lazy manner, so that not the complete database is updating when the server starts.

...

Renaming an attribute is regarded as deleting the old attribute and adding a new one. Existing information is in the old attribute is lost.

...

For metadata the same principles hold as for domain attributes. A special case is the changing of a change in the expression of a custom metadata attribute. Here also the lazy principles applies. When the expression for a custom metadata field changes, the value in the database is updated the next time an update action is performed for the aggregate entry.

...