Unlike some identity management solutions Netweaver Identity Management uses a SQL database instead of LDAP directory using a database storage engine. There are distinct advantages to this. For one you can subsume a hierarchy in SQL database but you can’t do set relations in LDAP. The layout of the database can be somewhat confusing so I thought I would pick the most used view and discuss its composition. Nearly every job and task are run against views and there are many in the backend database. Most the work is performed against a view called mxiv_sentries. Before we dig deeper into its composition, it pays to review some of the flaws of SQL which are maddening:
- NULL values are permitted and it seems that everyone implements it differently. This flaw cannot be bypassed. Try to avoid filling your database up with NULL values.
- Duplicate Rows are permitted, you will type SELECT DISTINCT many times.
- Duplicate Column Names are tolerated. Be careful naming temp tables and using AS, for example SELECT Col1 AS Name, Col2 AS Name.
There are others you can search them out on the web. Returning to the view mxiv_sentries. As previously stated this is the most commonly used view, it is denormalized and at first rather confusing to look at. You will find yourself doing many subselects to extract the information you need. The diagram below shows you which table columns are used to create the view.
The columns with which you will work with the most are MSKEY, AttrName, aValue, and SearchValue. MSKEY is primary key which is generated by the database. It changes across environments. AttrName is the name of the attributes that you either create or import; aValue stores the attribute values, for example, the MSKEYVALUE. SearchValue is aValue in all caps. The table below shows what we have learned from analysis since the internals of the database are not published. If you see an error or would like to add something send us a comment.
Click anywhere to cancel