Skip to main content
Version: 2.90.x.x Java 8 ELS

Properties - customizing the nevisIDM data model

nevisIDM comes with a powerful data model. But there are always business requirements and use cases which are very specific and may not be covered by the existing data model. For these cases, the data model contains the so-called "Properties". A property is similar to an attribute of an entity, e.g., the attribute "first name" of the entity "user". As shown in [this figure], various entities can be customized by means of properties. In this way, the nevisIDM data model can easily be customized and modified in line with very specific requirements.

One of the nicest features of nevisIDM and its properties is that everything is adapted automatically as soon as a new property has been defined. The new property will automatically be listed on the web GUI views where it is required and the web services will automatically accept retrievals for the property. So, the only thing that has to be done to extend the set of attributes of an entity is to initially define the property. All the rest is done by nevisIDM.

The most important features of properties are thus:

  • Properties represent additional customer-specific attributes for entities.
  • Properties are defined directly via SQL on the database except the properties with scope onProfileForApp and onProfileForAppGlobal. Properties of the last two scopes are defined in the nevisIDM web GUI.
  • Properties are either of type "enum" or of type "String".
  • Regular expressions and a limitation of the value length can be defined for increased security.
  • Properties may be defined as unique within a certain scope ("uniqueness scope").
  • Properties can have language-dependent names represented by DictEntry Values. As fallback we display the technical name of the Property.
  • The order in which the properties are displayed on the GUI can be influenced with "GUI Precedence".

All properties are stored into an application cache during the startup of nevisIDM. Property definition modifications are dynamically refreshed in the cache. If you have nevisIDM cluster, a distributed event handling mechanism ensures that the cache is refreshed for each nevisIDM instance.

The schematic data model with the available property scopes