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 data
• Create, read, update and deleteCustom meta data

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
• Authorization
  

...

Aggregates

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.

...

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 list functionality is very similar to the list functionality that is already available for instances, tasks and cases . 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. 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 performanceand 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 expression. This expression may however only use relations and attributes that are directly or indirectly part of the aggregate definition. In the example above, an aggregate list could contain custom metadata attributes like name, age, city of work or total number of persons in the household. The aggregate list cannot contain a custom metadata attribute blood type, since this is part of the medical information aggregate and not the person aggregate.

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 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 case of a relatively small amount of data, it is possible to store and read all information all the time and display all aggregates in a single list. However, this approach is not scalable and therefore not advised.

Aggregates can be created, read, updated and deleted. For these specific actions, services are available in Blueriq.