Data Lifecycle management: Public Keys

Published in

Mendix Community

6 min readNov 11, 2021

In the previous posts I have been discussing a drawing of a cat in Nazca Peru, as an example for the lifecycle of data in a project. Now we will take a look at the drawing and imagine how that same cat would be labeled by different public organizations.

For instance, the national government might have identified the cat as a public work-of-art N098 and the hill may be coded 14.70–75.10 representing its geographical location. The national travel agency labeled the complex of all drawings in Nazca as NAZ17 and the world heritage code for the complex is PERU172. In the Nazca Lines Handbook this particular drawing is labeled ‘C3’.

All these keys are used to identify the drawing in different systems, and used for interfacing data between those systems. Because these keys are also for external use, I call them ‘public keys’.

Now in most systems I know for every type-of-public-key a separate attribute is added to the entity representing the object and all business rules (uniqueness, format, search-characteristics) are programmed per attribute. Of course, if there are only few public keys relevant to the system this is OK.

But in many cases it makes sense to have a separate structure for public keys. Because such a structure allows more dynamics in using external codes, it offers us the possibility to have different characteristics per app instance (e.g. in Belgium different from the Netherlands), and is more efficient (solve it once, use many times).

Below you will find a draft structure for public keys. When to use it? My suggestion: if there are more than two entities that use public key(s) or there is at least one entity using more than 2 public keys.

Public key types

Using Public keys in a Mendix app requires a structure like this:

To understand this structure:

· The ‘Public Key Type’ defines a type of public key, its uniqueness, its format (e.g. as a general expression) and refers to the Mendix object type it is referring to;

· The ‘Public Key’ defines the value of the key;

· When using a public key, the key itself is linked to the entity related with the Mendix object type;

· In the example above ‘Geographical location’ is linked to Mendix object type ‘Hill’, it is unique at a specific moment and its format is ’99.99–99.99’. The public key of this type is ’14.70–75.10’ and linked to the specific object of entity Hill.

Some notes:

· Uniqueness can be defined as it’s ability to be linked to multiple objects at the same time, or whether it can be linked to multiple objects but not at the same time, or maybe it cannot be linked to multiple objects at all;

· In the search form for a specific entity, if the corresponding Mendix object type is used by one or more Public Key Types, the search on Public Key (on target date) should be added;

· Maintenance of Public Key Types should be assigned it’s own User Role;

· Note that if there are several instances of the app (e.g. the app is provided to different customers), the public key types and characteristics may differ per instance and maintenance should be per instance;

· Formats can differ depending on other entity properties. E.g. the fiscal number for addresses companies in the Netherlands may be ‘NL999999999B99’ while in Belgium it is ‘BE0999999999’.

· In interfaces it is, in most cases, clear what kind of key type is used for the keys. This should be parameterized in the interface specifications to avoid picking the wrong duplicates (in different public key types).

Why would the business care?

From a functional perspective, using a structure for public keys offers the possibility to :

· Create a timeline for every attribute and every association (which keys were used, which objects were used for a public key in time, etc.);

· Possibility to act on outside public keys that are replaced at a certain moment in time.

· Proper history on every object.

As stated in my previous posts, flexibility is increased by having validity on ALL entities that can be used by external parties.

Using generic validity features

It makes sense to, when starting a new app, create the public key structures up-front. This has the following advantages:

· It only needs to be developed and tested once. If it works, it can easily be added to another entity: it therefore increases the flexibility of the application;

· Functionality to maintain and access data only has to be developed and tested once, and can be copied easily for new entities: it reduces time-to-market;

· Most important: together with versioning and validity a complete lifecycle of the entity is created, therefore (functional) trouble shooting, error-correction, audit-ability and more is improved;

· Correction of a mistake can easily be done by replacing the public key by replacing the link of the public key with the entity object. In this way history is complete and trouble shooting is more easy: after all the erroneous public key was used for the object during some timeframe — it might be used in interfaces etc..

My implementation

Using basic Mendix features I did not find a generic solution, so I built a public key structure and use it in my applications.

Mendix implementation

I would like Mendix to consider adding the feature to the platform: in my opinion every entity and *every association can be flagged as having public keys. Although it is not a technical issue, it certainly is a part of the functional data foundation of every administrative application.