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 static properties (all property scopes except onProfileForApp and onProfileForAppGlobal) are stored into an applicational cache during the startup of nevisIDM. As a consequence, if new properties of those scopes are inserted into the nevisIDM DB, a restart of nevisIDM is required.